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

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

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

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

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

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

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

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

Цели процесса в ITIL должны соответствовать принципу SMART: - Конкретность и измеримость: формулировка включает метрику (например, "увеличить долю своевременно решённых инцидентов до 95%"). - Привязка к срокам: цель ставится на конкретный период (месяц, квартал). - Глаголы совершенного вида (дождусь, достигну, обеспечу). Цели не фиксируются в регламенте процесса, так как они часто пересматриваются, а учитываются в планах управления или картах показателей. Ответственность за определение и актуализацию целей лежит на владельце процесса. Цели должны быть чётко связаны с бизнес-требованиями и обоснованием проекта.

Итоговый рейтинг руководителя рассчитывается на основе процессных метрик, которые отражают эффективность работы его подчиненных в различных процессах. Все метрики должны быть приведены к сопоставимому виду (шкала от 0 до 1) и иметь одинаковое направление оценки (чем ближе к 1, тем лучше). Формула расчета итогового рейтинга может быть различной в зависимости от предпочтений организации: это может быть простое арифметическое среднее всех метрик, геометрическое среднее, взвешенное среднее (если некоторые метрики важнее других) или среднее по доле от целевых значений. Например, если используются метрики К1 (доля заданий, выполненных в срок), К2 (доля инцидентов, принятых в работу своевременно), К3 (доля инцидентов, решенных в срок и с первой попытки) и К4 (коэффициент обновления по проблемам), то итоговый рейтинг R может быть рассчитан как (К1 + К2 + К3 + К4)/4 (арифметическое среднее) или как произведение метрик в степени веса каждой метрики (взвешенное среднее).