Рекомендации по формулированию KPI в ITIL 4 представлены через факторы успеха практик (PSF). Для каждой практики определяются PSF, каждый из которых сопровождается подробным описанием и примерами метрик, которые можно использовать в качестве KPI. Например, для практики управления инцидентами PSF «раннее выявление инцидентов» имеет следующие примеры KPI: время между возникновением и обнаружением инцидента и доля инцидентов, выявленных с помощью мониторинга. Такая структура делает процесс формулирования KPI более простым и понятным, поскольку она предоставляет конкретные рекомендации и примеры измерений для каждого важного аспекта практики.

Небольшие улучшения отличаются от масштабных организационных изменений по нескольким ключевым признакам: 1) Масштаб воздействия - небольшие улучшения затрагивают отдельные процессы или небольшую группу сотрудников (например, добавление нового способа взаимодействия с Service Desk), тогда как масштабные изменения влияют на всю организацию или её существенную часть и часто серьёзно затрагивают внешних контрагентов. 2) Сложность реализации - небольшие улучшения, как правило, не очень сложно реализовать на практике, в то время как масштабные инициативы во многих случаях даются непросто. 3) Ресурсные требования - крупные изменения требуют задействования более половины ИТ-сотрудников и затрагивают сотрудников бизнес-подразделений, тогда как небольшие улучшения могут быть реализованы небольшой командой. 4) Уровень сопротивления - масштабные изменения сталкиваются с более сильным индивидуальным и системным сопротивлением, поскольку затрагивают больше людей и процессов. 5) Требования к руководству - небольшие улучшения могут быть успешно реализованы менеджерами, работающими по установленным процессам, тогда как масштабные преобразования требуют лидеров, способных работать в условиях неопределенности и риска.

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

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

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

Команда на уровне «Зрелость» представляет собой агента изменений на уровне всей компании. Она полностью контролирует свой рабочий процесс и несет ответственность за продукт на уровне P&L (прибыль и убытки), что означает управление финансовой стороной продукта. Инициативы направляются не только внутрь команды, но и наружу, команда стремится расширять зону влияния и инициирует изменения, затрагивающие множество служб и подразделений компании. Для такой команды лидер-слуга уже не нужен, как и лидер-наставник. Здесь требуется лидер-партнер с достаточными полномочиями для поддержки командных инициатив на высшем уровне, обладающий широкой осведомленностью о направлении развития компании и достаточным авторитетом для интеграции целей команды с целями компании. Это высшая ступень развития, где команда становится драйвером изменений в организации.

Главное отличие заключается в том, что управление проблемами — это не замедленный или альтернативный вариант управления инцидентами, а принципиально иной процесс. Основные различия включают: определение сроков (у проблем отсутствует единый срок устранения, но есть этапные контрольные точки), обработка известных ошибок (проблемы могут оставаться нерешёнными на длительное время), триггеры запуска процесса (реактивные для инцидентов против проактивных для проблем), ролевая структура (координаторы проблем для сложной диагностики) и специфические метрики эффективности. Также управление проблемами включает проактивные элементы, не сводимые к реактивной обработке инцидентов.

Раздел Outcomes (верхний левый квадрант) заполняется конкретными результатами, а не названиями процессов. В этом разделе следует указать, что именно будет сделано или получено в ходе проекта. Например, вместо формулировки «внедрение управления изменениями» необходимо написать конкретные достижения: «Сформирован каталог услуг, который включает в себя...», «Заключены SLA с такими-то контрагентами, определяющие такие-то условия», «Организован мониторинг параметров предоставления услуг». Чем конкретнее будут формулировки, тем проще будет впоследствии оценивать успех проекта и принимать решения по его развитию.

V-модель служит наглядным инструментом для отслеживания качества на всех этапах проекта. Она позволяет увидеть, как каждому этапу проектирования соответствует определенный вид тестирования, что обеспечивает системный подход к контролю качества. Модель помогает ответить на вопрос, какие проверки нужно провести для подтверждения выполнения требований на каждом уровне детализации. Графическое представление с четкими горизонтальными связями между этапами проектирования и тестирования помогает выявлять недостающие проверки и гарантирует, что ни один аспект системы не будет упущен из вида при оценке ее готовности к вводу в эксплуатацию

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