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

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

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

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

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

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

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

Change Authority

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Release Control and Validation

Учебный курс: преобразование и контроль ИТ-услуг, управление изменениями, релизами и конфигурациями, а также построение CMDB — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Альберт

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

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

  2. Дмитрий

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

  3. Дмитрий Исайченко

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

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

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

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

Empty