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

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

Чтобы система измерения процессов ИТ действительно помогала в управлении, следует придерживаться следующего подхода: 1. Начните с четкого определения назначения процесса (зачем он существует, какие цели решает). 2. Определите ключевые практики, которые необходимо выполнять для достижения этого назначения. 3. На основании ключевых практик сформулируйте метрики, которые будут отслеживать выполнение этих практик. 4. Установите целевые и граничные значения для каждой метрики, соответствующие вашим целям. 5. Сформируйте KPI, объединяющие эти метрики и показывающие степень достижения целей. 6. Убедитесь, что KPI взаимосвязаны между собой и создают целостную картину работы ИТ, а не представляют собой набор несвязанных показателей. 7. Включите в систему измерений не только технические данные, но и субъективные мнения пользователей (удовлетворенность), так как для ИТ важно качество предоставляемых услуг конечным пользователям. 8. Постоянно пересматривайте и корректируйте систему измерений, проверяя, действительно ли собранные данные помогают в принятии управленческих решений и достижении бизнес-целей.

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

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

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

Потребление услуг (service consumption) согласно ITIL 4 включает две основные деятельности: управление ресурсами потребителя, необходимыми для потребления услуги (например, знание иностранного языка при приобретении контента на этом языке); сервисные операции, выполняемые пользователями, включая использование ресурсов провайдера и запрос на выполнение сервисных операций (как умение пользоваться банкоматом для получения денег или обращение в службу поддержки при сбое услуги).

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

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

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