Принцип "Фокусируйтесь на ценности" (Focus on value) присутствует в обоих изданиях как ключевой. Однако в ITIL 4 расширено его содержание по сравнению с ITIL Practitioner Guidance 2016 года. В ITIL 4 четко указано, что понимание ценности включает в себя удовлетворение интересов как заказчиков (customer experience, CX), так и пользователей (user experience, UX). Это означает, что принцип "Проектируйте, ориентируясь на потребительский опыт использования" (Design for Experience), который существовал отдельно в ITIL Practitioner Guidance, фактически полностью интегрирован в более широкий принцип "Фокусируйтесь на ценности" в ITIL 4.

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

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

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

Распространённые ошибки: 1) Использование простого среднего без учёта критичности услуг, 2) Нормировка показателей в разных диапазонах (например, одни KPI до 100%, другие до 10), что искажает агрегацию, 3) Отсутствие динамики — отчёты по одному месяцу не показывают тренды, 4) Слишком сложные визуализации, непонятные руководителям (например, тепловые карты с десятками услуг). Правильный подход — фокус на двух-трёх ключевых показателях с интуитивной визуализацией, такой как гистограмма среднего и линия минимума.

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

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

Физический смысл данной метрики - коэффициент обновления. Метрика равна 1, если по итогам отчетного периода все оставшиеся открытые проблемы являются новыми (их не было в предыдущем периоде). Это означает, что старые проблемы были решены, а новые зарегистрированы, то есть процесс управления проблемами эффективно работает. Значение метрики 1 указывает на идеальную работу процесса, когда за период были полностью решены все старые проблемы и зарегистрированы только новые.

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

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