Модель Cynefin связана с управлением изменениями в ИТ тем, что помогает определить подходящую стратегию управления в зависимости от уровня сложности системы. В области 'Просто' (Simple) применяются стандартные процессы и процедуры, в области 'Запутанно' (Complicated) требуется экспертный анализ и планирование, тогда как в области 'Сложно' (Complex) требуется экспериментальный подход с множеством малых экспериментов и итераций. В контексте управления изменениями понимание, в какой области находится организация, помогает выбрать между традиционным CAB и более гибкими методами, избегая как чрезмерной бюрократии, так и недостаточного контроля.

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

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

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

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

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

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

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

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

В референтной модели COBIT5 содержится 37 процессов. Эта модель является достаточно подробной и охватывает различные аспекты управления информационными технологиями и процессами.