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

Процесс Управления инцидентами обеспечивает прозрачность в работе за счёт своевременной и эффективной передачи информации об инцидентах и их статусах. Для этого процесс должен быть построен так, чтобы пользователь получал нужную информацию в согласованные с заказчиком моменты времени и в согласованном формате через согласованные каналы. Это могут быть электронные письма, SMS, информация на портале самообслуживания (в личном кабинете), телефонные звонки или даже личные визиты в случае работы с VIP-пользователями. Процесс INC должен минимизировать количество повторных обращений пользователей по тем же инцидентам за счёт качественного информирования, что отражается в KPI: «Среднее число звонков на Service Desk и прочих контактов со стороны бизнес-пользователей по поводу уже зарегистрированных инцидентов».

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

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

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

Регламент управления изменениями и релизами в контексте разработки и внедрения прикладного программного обеспечения состоит из двух основных компонентов: 1) Документ, определяющий основные стадии создания новой автоматизированной системы или выполнения доработок («Положение о разработке прикладного ПО»), который описывает состав работ, ответственных лиц, входные и выходные документы для каждой стадии. 2) Документ, определяющий порядок приёмки новых систем в эксплуатацию («Положение о внедрении информационных систем»), который включает порядок и охват тестирования, подготовку тестовых сред, опытную эксплуатацию и другие аспекты внедрения. Этот регламент может дополняться политиками релизов по информационным системам, что позволяет согласовать с бизнесом календарь релизов и определить необходимость и порядок выделения ресурсов на проведение пользовательского тестирования (UAT). В совокупности эти документы обеспечивают структурированный процесс управления изменениями и релизами при разработке и внедрении программного обеспечения.

ITIL 4 расширяет подходы ITIL v3, добавляя фокус на управление опытом (experience) помимо полезности и гарантии. Если в ITIL v3 акцент делался на разделении функциональных и нефункциональных характеристик услуг, то в ITIL 4 основное внимание уделяется совместному созданию ценности для заинтересованных сторон, что включает анализ эмоционального и функционального взаимодействия с услугой. Это отражено в практике Drive stakeholder value (DSV), которая уделяет особое внимание CX и UX.

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

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

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