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

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

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

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

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

Автор упоминает, что некоторые ИТ-специалисты воспринимают себя как "гуру и чуть ли не божества", чтобы подчеркнуть проблему излишней самоуверенности и ограниченности знаний у некоторых представителей ИТ-сферы. Он отмечает, что часто эти специалисты считают себя экспертами во всех вопросах только потому, что могут составлять простые программные конструкции из английских слов (for, while, if, loop), при этом их знание второго языка и технических аспектов обычно ограничено. Это создает барьеры в коммуникации с бизнесом и усугубляет проблему разобщенности между ИТ и бизнес-подразделениями.

Sj в формуле First Time Resolution (FTR) определяется как количество объектов (инцидентов), которые были возвращены на доработку конкретно в j-тую группу. Этот показатель отражает неудачные попытки решения обращений, требующие повторной обработки. Важно учитывать, что возвраты должны отслеживаться именно на уровне отдельной группы, а не всего инцидента, чтобы гарантировать точность расчёта метрики для каждой отдельной рабочей группы.

Nj не может включать все обработанные обращения, потому что в расчёт должна включаться только завершённая работа — обращения, по которым процедура проверки решения полностью завершена. Это могут быть закрытые без рекламаций инциденты или те, которые были возвращены на доработку (Sj). Если включить в Nj все обработанные обращения, в том числе те, где процесс проверки не завершён, это исказит метрику FTR, так как не отразит реальное качество работы группы.

Обобщённые показатели (среднее и минимальное значение) можно использовать для расчёта бонусов по формуле, учитывающей два аспекта: достижение целевого уровня среднего показателя (например, 85%) и отсутствие критических провалов (минимальное значение выше 70%). Например, премия выплачивается на 100%, если среднее ≥85% и минимум ≥70%, на 50% — если среднее ≥85%, но минимум <70%, и не выплачивается при среднем <85%. Это стимулирует не только общее улучшение показателей, но и устранение узких мест.

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