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

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

Рост доли переоткрытых инцидентов в системе управления может служить признаком снижения качества работы процесса управления инцидентами. Это указывает на то, что решения, принимаемые при первичном обработке инцидентов, не всегда являются окончательными или достаточными, что приводит к необходимости повторной обработки. Такая ситуация говорит о снижении показателя First Time Resolution (FTR) и может отражать недостатки в процессе проверки решений или в первоначальной диагностике проблем, требуя обратной связи и улучшений в работе службы поддержки.

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

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

Выбор событий верхнего уровня (топ-событий) должен основываться на целях конкретного анализа. В ИТ-контексте наиболее эффективным подходом является разбиение услуги на основные функциональные блоки, после чего для каждой функции определяется какое событие будет считаться отказом. Например, для ITSM-системы можно выделить такие функциональные блоки как доступ инженера к базе обращений, web-доступ пользователя к базе, обработка обращений, отправка уведомлений и другие. После этого определяется, что именно будет считаться «отказом» для каждой функции: недоступность интерфейса, невозможность выполнения операции и т.д. Такой подход позволяет точно определить критичность последствий отказа конкретного компонента для общей работы ИТ-услуги.

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

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

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

Поле «Срочность» с градацией (низкая, средняя, высокая) часто используется бизнесом для завышения приоритета запросов, так как максимальная отметка «высокая» кажется единственно правильным выбором при любом запросе. Это приводит к перекосу в управлении изменениями: важные emergency-изменения теряются среди множества ненужно приоритизированных изменений, а процесс принятия решений замедляется из-за необходимости перепроверки каждого случая. Кроме того, сама градация не учитывает контекст — например, «высокая срочность» может означать как реальную угрозу для бизнеса, так и личную заинтересованность сотрудника.