Всем известно, что срочные изменения – это зло, с которым необходимо бороться, но невозможно победить до конца. В связи с этим возникает интересный вопрос: если до конца не победить, то сколько процентов срочных изменений является приемлемым уровнем?

Для начала разберемся, что такое срочные изменения. В ITIL v2 срочным считалось любое изменение, которое необходимо выполнить так быстро, что часть стандартных активностей процесса управления изменениями для них приходится либо пропускать, либо выполнять в сокращенном варианте, либо выполнять «задним числом». Например, пропускаем тестирование в тестовой среде (тестируем на продуктиве), согласуем по сокращенному варианту, оформляем в системе автоматизации задним числом. При этом на причину срочности ITIL v2 ограничений не накладывал – это может быть связано и с реализацией новой срочной потребности, и с устранением ошибки в продуктивной среде. Авторы ITIL v3, похоже, решили навести порядок. Введя вместо срочного изменения (urgent change) понятие экстренного изменения (emergency change), они далее делают следующие утверждения:

• Экстренное изменение – это изменение, которое должно быть внедрено как можно быстрее, например, для разрешения значительного инцидента или установки обновления безопасности (Глоссарий ITIL 2011, официальный русскоязычный перевод)
• Emergency change is reserved for changes intended to repair an error in an IT service that is negatively impacting the business to a high degree. Changes intended to introduce immediately required business improvements are handled as normal changes, assessed as having the highest urgency. (ITIL Service Transition, подчеркивание мое)

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

Почему я на это обращаю внимание? На то есть две причины:

• потому что в зависимости от трактовки метрика «% экстренных изменений от общего количества изменений за период» в разной степени характеризует качество процесса управления изменениями;
• потому что прямое сравнение значений данной метрики между разными компаниями может быть затруднено в силу того, что они по-разному определяют границы экстренных изменений.

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

Что же показывают цифры? Вот, что говорит Pink Elephant:

• более половины компаний имеют долю экстренных изменений в пределах 10%;
• почти в 20% компаний (!) значение данной метрики превышает 15%.

А сколько у Вас? Сравнимся?

P.S. Кстати, та же аналитика от Pink Elephant показывает наличие статистически значимой отрицательной корреляции между долей экстренных изменений и долей изменений, выполненных корректно с первой попытки. Иными словами есть статистическое подтверждение банальной истины: увеличение доли срочных работ отрицательно сказывается на качестве их исполнения.

Но давайте сделаем ещё один вывод. Для этого вспомним, что процесс управления изменениями по определению нацелен на снижение рисков, связанных с некорректной реализацией изменений. А значит есть статистическое обоснование того, что сокращение доли экстренных изменений является неотъемлемой составляющей данного процесса. Поэтому если доля экстренных изменений высока (например, 30 и более процентов) и не снижается, то как таковое управление изменениями выполняется лишь частично или не выполняется совсем.

P.P.S. В силу сказанного выше доля экстренных изменений является одним из KPI процесса управления изменениями.

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Построение системы KPI для ИТ

Как обеспечить управление процессами, проектами, услугами, персоналом