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

Наиболее часто встречающиеся ошибки при расчёте Incident Rate — это неверный учёт пользователей (например, включение технических учётных записей или уволенных сотрудников), игнорирование сезонных колебаний при анализе данных за короткий период, а также включение в числитель инфраструктурных инцидентов или сервисных запросов. Чтобы избежать искажений, рекомендуется использовать годовые данные с разбивкой по месяцам и проверять качество данных в ITSM-системе.

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

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

Для связи ИТ-метрик с бизнес-целями следует заменить показатели, фокусирующиеся только на выходах, на метрики, влияющие на результаты. Вместо 'времени ответа на запрос' измерять 'рост NPS клиентов', вместо 'количества релизов' - 'ускорение вывода продукта на рынок'. Хороший пример - компания Ford, которая заменила KPI 'количество строк кода' на 'снижение времени сборки авто', повысив эффективность ИТ на 200%. Необходимо всегда проверять, как технические метрики влияют на конечные бизнес-результаты и перестроить систему отчетности и поощрений вокруг этих результатов.

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

Если процесс управления конфигурациями не создаёт реальной ценности, это может привести к нескольким негативным последствиям. Во-первых, сотрудники перестанут использовать CMDB, так как не увидят в этом необходимости. Во-вторых, инвестиции в сбор и обработку информации будут потрачены впустую. В-третьих, репутация ITIL и ITSM в организации ухудшится, что может повлиять на восприятие других процессов управления услугами. Люди начнут ассоциировать все процессы ITSM с излишней бюрократией без реальной пользы, что приведёт к сопротивлению любым изменениям и инициативам в области управления услугами.

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

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

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