Портал №1 по управлению цифровыми
и информационными технологиями

Измерение процессов. Доля срочных изменений

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

Для начала разберемся, что такое срочные изменения. В 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 для ИТ»
Как обеспечить управление процессами, проектами, услугами, персоналом

Комментариев: 9

  • Vyacheslav Potov

    У нас метрика до 10%. В целом планку держим.
    Используется только для внедрения фиксов при инцидентах с высоким импактом.

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

  • Вячеслав, спасибо!

    И все? И больше никто не управляет изменениями?

    • Юрий Алдунин

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

      • Юрий, сколько? 🙂

        • Юрий Алдунин

          По ощущениям в 10% укладываемся, но точную цифру не дам. Не потому что жадный, а потому что, как сказал выше: они у нас пока идут по общему процессу и быстро вытащить точную цифру не получится.

          • … в 10% укладываемся …

            Тогда почему Вы пишете “Дмитрий, ну почему же не управляет?” Ведь мой текст выше звучит так: “… если доля экстренных изменений высока (например, 30 и более процентов) и не снижается, то как таковое управление изменениями выполняется лишь частично или не выполняется совсем.” Т.е. к тем, у кого в пределах 10% у меня – никаких претензий 🙂

            • Юрий Алдунин

              Я имел в виду, что наверняка не только у нас управление изменениями есть, но срочные отдельно не выделены и отдельная статистика по ним не ведётся.

  • Andrey Kapustin

    Интуитивно в пределах 15%.
    Точного учета по метрике не ведется.


Добавить комментарий для Дмитрий ИсайченкоОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM