В тексте приведены два примера имитации активности: массовое закрытие проблем с кодом 'Решение нецелесообразно', при котором KPI остается близким к единице, несмотря на отсутствие реальной пользы, и регистрация дублей проблем, которые сразу закрываются как дубликаты. Эти действия создают видимость высокой активности, но не добавляют ценности процессу управления проблемами.

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

Вероятностный характер поступления инцидентов, описанный как стохастические отклонения, существенно влияет на среднее время их решения. Инциденты обычно распределяются неравномерно в течение дня с пиками нагрузки (распределение в форме 'верблюда'), что создает эффект очереди. Даже при постоянной производительности персонала, если инциденты приходят неравномерно, среднее время их решения может быть значительно выше, чем при равномерном распределении. Например, 24 инцидента, решаемые с производительностью 20 минут каждый, теоретически должны обрабатываться за 20 минут на инцидент при равномерном поступлении, но при массовом поступлении утром среднее время возрастает до 4 часов 10 минут. Это связано с тем, что последующие инциденты вынуждены ждать, пока предыдущие будут обработаны, что приводит к экспоненциальному росту среднего времени при увеличении количества одновременно поступающих инцидентов.

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

С помощью CLD можно косвенно оценить факторы, которые сложно измерить напрямую, анализируя их причинно-следственные связи с другими элементами системы. Например, прямое измерение Cost per change / release может быть сложным, так как требует точного учета всех ресурсов. Однако CLD показывает, что эффективность использования ресурсов связана с уровнем стандартизации и автоматизации изменений, а также с успешностью первоначальной реализации (First-Time Implementation Rate). Измеряя эти косвенные показатели, можно оценить эффективность использования ресурсов, даже не измеряя напрямую стоимость изменений.

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

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

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

Подход с разделением ALM для разработки и ITSM для эксплуатации соответствует уровню зрелости «Controlled» в модели KPMG maturity phases model of the IT organisation. На этом этапе операционные процессы, такие как управление инцидентами, изменениями и релизами, контролируются и стандартизированы, но отсутствует сквозная ответственность за ИТ-услуги как целостные элементы, влияющие на бизнес-процессы. Такой уровень зрелости может быть достаточным для организаций, где нет высокой потребности в изменении ИТ-инфраструктуры ради поддержки бизнеса.

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