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

Вам срочно или экстренно?

Срочно, безотлагательно, экстренно… Все эти синонимы с точки зрения англо-русских словарей могут быть использованы для перевода слова “emergency”, которое в ITIL используется для именования особой группы изменений. Изменения этой группы должны внедряться “как можно скорее”. Формулировка, на первый взгляд, несколько размытая и не дающая чётких указаний, в каких конкретно случаях изменение следует обрабатывать в соответствии с некой специальной процедурой. Но в ITIL эта формулировка сопровождается чётким ограничением охвата и соответствующими примерами. В частности, там сказано, что “процедура обработки emergency-изменений должна применяться только для изменений, направленных на устранение ошибок в ИТ-сервисах, которые серьёзно влияют на бизнес”. А в разделе, посвящённом типам запросов на изменение (change request), приведены два примера “emergency”-изменений:

  • изменение, необходимое для устранения массового инцидента;
  • патч, устраняющий “дыры” в безопасности.

При этом слово “emergency” и контекст ситуации не предполагают какой-либо градации по уровню. Нужно безотлагательно, а не “слегка безотлагательно” или “сверх-безотлагательно”. Безотлагательно – значит, всё бросили и занимаемся только этим.

А к слову “срочное” мозг заботливо подбирает ассоциации, связанные с его корнем. “Насколько срочное?” – вполне закономерный вопрос в нашем контексте. Отсюда возникает довольно распространённая в нашем отечестве практика вводить в карточке запроса на изменение поле “Срочность” с типовым набором значений. Примерно таких:

  • низкая;
  • средняя;
  • высокая.

Что интересно, если внимательно посмотреть на правила обоснования этих значений, становится понятно, что вкладываемый смысл коррелирует либо с влиянием изменения (его важностью для бизнеса), либо с требованиями к сроку реализации. То есть либо бизнес говорит “мне надо завтра”, что даёт нам сразу конкретные требования к сроку, либо “это крайне необходимо”, в результате чего мы, вполне вероятно, отодвигаем все прочие задачи. Так или иначе мы действительно определяем “срочность”, но по факту она выражается в более конкретных понятиях. Абстрактная, на мой взгляд, классификация “срочностей”, приведённая выше, не информативна. Её применение часто приводит к путанице и злоупотреблениям “сверх-срочностью”. Бизнес в большинстве случаев тяготеет к установке максимальной “срочности” по практически каждому запросу на изменение. Вернуть заказчика в конструктивное русло помогает именно конкретизация требований к сроку с одновременной оценкой влияния изменения на бизнес, что позволяет нам объективно установить приоритет изменения, то есть последовательность реализации относительно других изменений. И в ITIL не зря рекомендуется именно такой подход.

При этом для “emergency”-изменений, которые, как мы увидели выше, не используются для реализации запросов от бизнеса, лучше применять термин “экстренное”, так как он лучше отражает смысл написанного в ITIL. Важно помнить, что “срочность” в управлении изменениями не тождественна “экстренности”.

«VAP: Управление изменениями и конфигурациями в ИТ»
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

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

  • Andrey Dedukh

    Когда читал книжку по ITIL, как-то сразу было очевидно, что emergency-изменения служат для “тушения пожаров”, для нее создается спец. процедура утверждения и спец. группа, утверждающая эти изменения. Оно только для “тушения пожаров”. Мне кажется, что если бизнес пытается через эту процедуру провести плановые изменения для сокращения, то это ошибка внедренцев процесса управления изменениями.

  • Алексей

    Всё, что важно, не бывает срочно. Всё, что срочно — только суета. Хань Сян-цзы

    ИМХО, необходимо минимизировать различного рода “пожары”, за счет построения и улучшения процессов, планирования и информирования, тогда уже можно спокойно заниматься работой, а не беготнёй.


Добавить комментарий

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;