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

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

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

Существуют следующие альтернативные подходы к принятию решений о приоритетах ИТ-изменений: перенос ответственности на бизнес-руководителей через создание специальных комитетов (например, проектный комитет для крупных инициатив); назначение операционного директора или директора по развитию ответственным за принятие решений по небольшим задачам; выделение ресурсных квот для подразделений на среднесрочной основе. Также рассматривается вариант, когда ответственный за принятие решений по приоритизации является непосредственным руководителем ИТ-директора, что делает распределение ответственности более естественным.

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

При внедрении системы учета трудозатрат рекомендуется следовать нескольким ключевым принципам. Во-первых, определить оптимальный уровень детализации учета, создав каталог работ, который включает основные направления деятельности организации (для группы из 8-12 человек достаточно 10-20 позиций для рутинной работы и 20-25 с учетом проектов). Во-вторых, обеспечить своевременную фиксацию трудозатрат - лучше сразу после завершения работы, а максимальный допустимый срок - конец рабочего дня, чтобы минимизировать ошибки в учете (недельный учет может давать искажения до 10%). В-третьих, внедрить правильный подход к планированию, используя принцип 'just-in-time' с загрузкой 90-110%, чтобы избежать накопления снежного кома незавершенных задач. В-четвертых, убедиться, что затраты времени на сам учет минимальны - для специалиста около 10 минут в день (2% рабочего времени), для руководителя - до 5% на контроль. Наконец, обеспечить мотивацию сотрудников к точному учету и контролю со стороны руководства, так как без этого даже самая продуманная система может не дать ожидаемых результатов.

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

Типичные ошибки: завышение данных из-за непонимания 'кванта времени', использование искусственных нормативов (например, минимум 15 минут), игнорирование параллельных задач, распределение времени по шаблону '100%', а также восприятие учёта как инструмента контроля, а не анализа. Это приводит к искажению данных и потере доверия. Важно избегать жёстких правил, обучать сотрудников методам оценки и фокусироваться на использовании статистики для улучшения процессов.

В ITIL V3 2011 роль менеджера изменений не была отдельно описана - вместо нее существовали роли владельца процесса, менеджера процесса, инициатора, практика, авторизующего и участника CAB. В ITIL4 роль менеджера изменений (Change manager) стала официальной в рамках практики 'Поддержка изменений' (Change enablement) как специфическая роль, включающая управление жизненным циклом отдельных изменений и развитие самой практики. В ITIL4 также появилась дополнительная роль координатора изменений (Change coordinator) для работы в ограниченном контексте, в то время как владелец практики отвечает за общее управление практикой.

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