Роль менеджера изменений исторически вызывает некоторые расхождения в толковании охвата обязанностей. Довольно часто доводится задавать слушателям вопрос: “Вы сейчас кого имеете в виду, менеджера процесса в целом или координатора отдельных изменений?”. Надо сказать, что в зависимости от контекста ответ бывает разным. После очередного случая решил пробежаться по рекомендациям ITIL, чтобы выделить те, которые касаются области ответственности менеджера изменений.
Что интересно, в книжке ITIL V3 2011 Service Transition (вы же ещё не забыли такую?) роль “менеджер изменений” в разделе “6.4.6 Роли управления изменениями” не описана. Там есть традиционные Владелец и Менеджер процесса, а также Инициатор, Практик, Авторизующий, Участник и Председатель комитета по изменениям (CAB). На роль ответственного за координацию работ по отдельным изменениям, в том числе относящимся к определённой области, из перечисленных лучше всего подходит Практик. А ещё в начале раздела “6. Роли”, между делом так, написано: “Роли могут быть объединены различным образом в зависимости от организационного контекста. Например, некоторые организации выделяют роль менеджера изменений, которая объединяет роли владельца процесса управления изменениями, менеджера процесса, администратора изменений и председателя Консультативного совета по изменениям (CAB).” Короче, и швец, и жнец, и на дуде… ну вы знаете.
Что ещё более интересно, выход ITIL4 не упростил картинку, как могло бы показаться при беглом взгляде на обязанности роли Менеджера изменений (Change manager) в описании практики “Поддержка изменений” (Change enablement). Да-да, теперь там такая роль есть. Теперь она относится к “специфическим” (practice-specific) ролям, фокусируясь при этом не только на отдельных изменениях, но и на “развитии практики”. Кстати, получается, что эту роль теперь с таким же успехом можно назвать и Менеджером процесса – процесса, который описан в практике “Поддержка изменений”, как управляющий жизненным циклом отдельных изменений. Что, как мне кажется, было бы логично, поскольку в рамках практики описан набор процессов, каждому из которых явно нужен какой-то управляющий. Координатор изменений описан, как дополнительная роль с теми же обязанностями, что и у Менеджера изменений, но в ограниченном контексте (например, по направлению, подразделению заказчика и так далее). Ну а в целом у практики есть Владелец практики (Practice owner).
Итого получается, что теперь, с выходом ITIL4, Менеджер изменений – это вполне “узаконенная” роль, охват обязанностей которой распространяется на следующие области:
- первичная обработка запросов на изменения
- назначение запросов на рабочие группы в соответствии с моделями изменений
- получение и коммуникация решений об авторизации или отклонении
- мониторинг и анализ выполнения работ
- поддержание и публикация графика изменений
- развитие моделей изменений и экспертизы в рамках практики
То есть Менеджер изменений – это, с одной стороны, координатор конкретных изменений, с другой – менеджер процесса, если помимо него ещё выделены Координаторы по направлениям. А ответ на вопрос “Вы кого имеете в виду?” так и останется разным в зависимости от контекста.
“То есть Менеджер изменений — это, с одной стороны, координатор конкретных изменений, с другой — менеджер процесса, если помимо него ещё выделены Координаторы по направлениям.” – Ну зачем путать мокрое с холодным.
ITSM – это бизнес-процессы в сфере оказания ИТ услуг. Следовательно подчиняются общим правилам бизнес-процессов.
В любом бизнес-процессе есть менеджер процесса и менеджер конкретного экземпляра процесса. Менеджер процесса отвечает за то, чтобы весь процесс достигал своей цели на всем протяжении своего жизненного цикла. Менеджер конкретного изменения отвечает только за свое конкретное изменение. И функционально подчиняется менеджеру процесса в рамках своего изменения.
Часто в описании процесса Управления изменениями, Менеджера изменения называют Ответственным за изменение, что бы не вносить путаницу в понимание границ обязанностей различных ролей в процессе.