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

Всегда ли нужен CAB в управлении изменениями?

1328658953_0Таким вопросом задаётся в своём блоге Стюарт Рэнс и делится своими соображениями по этому поводу. Он замечает, что в организациях люди непременно стремятся отнести каждое изменение к одному из следующих типов (обратите внимание, что определения близки к тексту ITIL, но не до конца ему соответствуют):

  • Стандартные изменение – связанные с низким риском, понятные, полностью задокументированные, предавторизованные, которые могут проводиться без необходимости дополнительного согласования). Часто выполняются как запросы на обслуживание, но также могут включать операционные изменения.
  • Нормальные изменения – являются предметом рассмотрения на Комитете по изменениями (CAB), который обычно собирается один раз в неделю для рассмотрения запросов на изменения, полученных в течение нескольких дней до заседания.
  • Экстренные изменения – изменения, которые должны быть проведены как можно скорее для решения инцидента, устранения критической уязвимости или в случае другой необходимости провести изменение до того, как его сможет авторизовать CAB. Экстренные изменения рассматривает Комитет по экстренным изменениям (eCAB), который собирается по необходимости – возможно, дистанционно.

Таким образом, если CAB только прошёл, а следующий по плану только через неделю, вы автоматически получаете как минимум недельную задержку для всех нормальных изменений, регистрируемых в это время. Приемлемо ли это? Во времена мейнфреймов, возможно, но не сегодня. Мы должны искать способы работать быстрее и эффективно.

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

ITIL вводит роль “change authority”, которую могут исполнять различные сотрудники и структуры организации в зависимости от ожидаемого бизнес-риска, финансовой составляющей и охвата изменения. Например:

Тип изменения

Change Authority

Инфраструктурные изменения, внедряемые как “Infrastructure as code”

Стандартные изменения

Другие инфраструктурные изменения, которые будут проводиться в рамках согласованного сервисного окна, и которые не затрагивают критических компонентов инфраструктуры, а также с этими компонентами не связано ни одно неудачное изменение за последние 12 месяцев

Инициатор изменения

Изменения кода приложений с низким риском в рамках согласованных проектов развития приложений

Парное программирование

Изменения кода приложений с низким риском

Менеджер по разработке

Инфраструктурные изменения с средним риском

Менеджер по эксплуатации ИТ

Запуск новых проектов по развитию приложения

Проектный офис

Изменения с высоким риском

Комитет по изменениям (CAB)

Суть в том, что вы можете реализовывать изменения быстрее и эффективнее, если правильно делегируете роль “change authority”, а в дальнейшем сделаете их ответственными за успешность авторизованных изменений.

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

А как назначаются ответственные за авторизацию изменений в вашей организации?

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

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

  • Альберт

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

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

  • Дмитрий

    Фактически при наличии полноценного change management процесса и CAB не все нормальные изменения проходят через него, из-за его бюрократизации. Это проводит  к тому, что где-то на нижнем уровне принимаются не согласованные измения, которые не всегда просто обнаружить, если не было  последствий для бизнеса. Анализ таких изменений может помочь выделить потенциальных change authority и делигировать им полномочия, учитывая риски , финансы и скоп измения. Но все это требует еще более тщательного контроля со стороны Change Manager, что не всегда возможно.

  • Вообще не воспринимаю CAB как authority body. В ITIL CAB – это прежде всего advisory body, и я думаю это абсолютно правильно. А функции authority естественно раздаются соответствующим функциональным менеджерам: за технику – техническим, за деньги – финансовым и так далее.

    Кроме того, если воспринимать CAB именно как advisory body, сокращается поток изменений, которые через него необходимо пропускать. Это дополнительно повышает пропускную способность процесса.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;