Внедрение ITSM может оказать влияние на оргструктуру компании. Например, роль координатора изменений трансформируется в роль менеджера услуг, а комитеты, такие как комитет по управлению проблемами, фактически становятся сервисными комитетами. Эти изменения отражают переход от процессно-ориентированной модели к сервисно-ориентированной структуре управления.

В 2002 году Google, под вдохновением отцов-основателей Ларри Пейджа и Сергея Брина, провела эксперимент по радикальному сокращению количества менеджеров, превратив компанию в плоскую структуру без иерархии. Эксперимент длился всего несколько месяцев, так как выяснилось, что сотрудники не могут эффективно работать без руководителей. Отсутствие менеджеров привело к неопределённости в распределении обязанностей, конфликтам и снижению производительности. После этого компания пересмотрела свою стратегию и постепенно вернулась к управлению с элементами иерархии, но с акцентом на минимизацию бюрократии и оптимизацию управленческой структуры.

Модели инцидентов – это заранее определённые категории или типы инцидентов, для которых установлено, на какой линии поддержки они должны решаться. При использовании моделей инцидентов, для каждого типа инцидента фиксируется, может ли он быть разрешён на первой линии. При формировании отчётности по метрикам FLR и FCR, этот атрибут используется для фильтрации обращений, так что в расчёте участвуют только те обращения, которые теоретически могли быть решены на первой линии. Это позволяет исключить из расчёта те обращения, которые первой линией разрешены быть не могут, и сделать показатели более точными и объективными для оценки её работы.

Основные практические рекомендации по проведению опросов с точки зрения статистической значимости результатов: 1) Для опросов с пятибалльной шкалой достаточно собрать 40-50 ответов, чтобы получить статистически значимые результаты с ошибкой 0.25-0.5 балла при 95% доверительной вероятности. 2) Превышение этой выборки дает незначительный прирост точности по сравнению с затратами на сбор дополнительных ответов. 3) Если известно, что респонденты делятся на группы с разными паттернами ответов (например, различные филиалы или категории пользователей), необходимо собрать по 40-50 ответов для каждой группы. 4) При использовании более детализированных шкал оценок (например, десятибалльной) требуется увеличить размер выборки для сохранения той же точности.

Каждый процесс домена EDM в COBIT 5 включает три практики, которые следуют единой структуре: оценка, направление и мониторинг. Например, в процессе EDM01 эти практики названы: EDM01.01 «Оценка системы руководства», EDM01.02 «Определение направления развития для системы руководства», EDM01.03 «Мониторинг системы руководства». Такая же трехшаговая структура характерна и для всех остальных процессов домена EDM. При этом объект оценки, направления и мониторинга меняется в зависимости от конкретного процесса.

Проект аутсорсинга может быть нецелесообразен, если руководство компании не готово рассматривать аутсорсер как независимый коммерческий бизнес, подверженный конкуренции. В таком случае аутсорсер не сможет развиваться, останется инертным и потеряет мотивацию к оптимизации затрат и повышению качества. Это приведет к увеличению расходов и ухудшению соотношения качество/стоимость, делая проект пустой тратой сил, времени и денег.

Во-первых, необходимо четко определить и прописать роли и зоны ответственности для каждого члена команды. Это поможет избежать пересечений и дублирования задач. Во-вторых, важно ставить перед менее опытными участниками задачи, которые они могут выполнить самостоятельно, постепенно повышая сложность. В-третьих, лидер должен учиться давать обратную связь, а не решать задачи за других. Также полезно создать культурные нормы команды, где самостоятельность и развитие каждого участника поощряются. При этом важно поддерживать баланс: иногда краткосрочная помощь нужна, но она не должна мешать долгосрочному росту команды.

Переход крупной ИТ-организации полностью на гибкие методы маловероятен и часто нецелесообразен по нескольким причинам. Во-первых, масштабная ИТ-инфраструктура с сотнями систем содержит множество legacy-систем и процессов, которые не могут быть быстро изменены без риска нарушения критически важных бизнес-процессов. Во-вторых, различные части организации имеют разные потребности: некоторые системы требуют стабильности и предсказуемости, тогда как другие могут развиваться быстро и гибко. В-третьих, не все сотрудники готовы или могут работать в гибкой среде, особенно если организация долгие годы использовала традиционные методы. Поэтому вместо полного перехода к гибким методам рациональнее применять бимодальный подход, где часть систем и команд работает по традиционным методам, а часть - по гибким, с акцентом на координацию и взаимодействие между этими режимами.

Принцип 'Вовлекать и работать совместно' важен, потому что в сервисных отношениях участвует множество людей, которые могут как облегчать, так и усложнять друг другу жизнь в зависимости от способа взаимодействия. Особенно актуальна проблема вовлечения заказчиков в обсуждения услуг, когда руководители бизнес-подразделений считают свою задачу выполненной после формулировки требований и стремятся устраниться. Решение этой проблемы лежит прежде всего в развитии коммуникативных навыков и построении эффективных взаимоотношений.

Непосредственный руководитель должен знать и одобрять доступ сотрудника к информационным системам, поскольку сотрудник выполняет определенные функциональные обязанности. Отклонения от этих обязанностей должны вызывать вопросы. Руководитель принимает решение о выдаче доступа, основываясь на знании профиля нагрузки и задач своего подчиненного, проверяя, соответствует ли запрашиваемый доступ выполняемым сотрудником функциям. Это позволяет контролировать, чтобы сотрудник запрашивал доступ исключительно для выполнения своих трудовых обязанностей.