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

Многоликий change manager

Роль менеджера изменений исторически вызывает некоторые расхождения в толковании охвата обязанностей. Довольно часто доводится задавать слушателям вопрос: «Вы сейчас кого имеете в виду, менеджера процесса в целом или координатора отдельных изменений?». Надо сказать, что в зависимости от контекста ответ бывает разным. После очередного случая решил пробежаться по рекомендациям ITIL, чтобы выделить те, которые касаются области ответственности менеджера изменений.

Что интересно, в книжке ITIL V3 2011 Service Transition (вы же ещё не забыли такую?) роль «менеджер изменений» в разделе «6.4.6 Роли управления изменениями» не описана. Там есть традиционные Владелец и Менеджер процесса, а также Инициатор, Практик, Авторизующий, Участник и Председатель комитета по изменениям (CAB). На роль ответственного за координацию работ по отдельным изменениям, в том числе относящимся к определённой области, из перечисленных лучше всего подходит Практик. А ещё в начале раздела «6. Роли», между делом так, написано: «Роли могут быть объединены различным образом в зависимости от организационного контекста. Например, некоторые организации выделяют роль менеджера изменений, которая объединяет роли владельца процесса управления изменениями, менеджера процесса, администратора изменений и председателя Консультативного совета по изменениям (CAB).» Короче, и швец, и жнец, и на дуде... ну вы знаете. 

Что ещё более интересно, выход ITIL4 не упростил картинку, как могло бы показаться при беглом взгляде на обязанности роли Менеджера изменений (Change manager) в описании практики «Поддержка изменений» (Change enablement). Да-да, теперь там такая роль есть. Теперь она относится к «специфическим» (practice-specific) ролям, фокусируясь при этом не только на отдельных изменениях, но и на «развитии практики». Кстати, получается, что эту роль теперь с таким же успехом можно назвать и Менеджером процесса — процесса, который описан в практике «Поддержка изменений», как управляющий жизненным циклом отдельных изменений. Что, как мне кажется, было бы логично, поскольку в рамках практики описан набор процессов, каждому из которых явно нужен какой-то управляющий. Координатор изменений описан, как дополнительная роль с теми же обязанностями, что и у Менеджера изменений, но в ограниченном контексте (например, по направлению, подразделению заказчика и так далее). Ну а в целом у практики есть Владелец практики (Practice owner).

Итого получается, что теперь, с выходом ITIL4, Менеджер изменений — это вполне «узаконенная» роль, охват обязанностей которой распространяется на следующие области:

  • первичная обработка запросов на изменения
  • назначение запросов на рабочие группы в соответствии с моделями изменений
  • получение и коммуникация решений об авторизации или отклонении
  • мониторинг и анализ выполнения работ
  • поддержание и публикация графика изменений
  • развитие моделей изменений и экспертизы в рамках практики

То есть Менеджер изменений — это, с одной стороны, координатор конкретных изменений, с другой — менеджер процесса, если помимо него ещё выделены Координаторы по направлениям. А ответ на вопрос «Вы кого имеете в виду?» так и останется разным в зависимости от контекста.

ITIL 4 Foundation, MPT, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от участников разработки

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

  • Леонид

    «То есть Менеджер изменений — это, с одной стороны, координатор конкретных изменений, с другой — менеджер процесса, если помимо него ещё выделены Координаторы по направлениям.» — Ну зачем путать мокрое с холодным.

    ITSM — это бизнес-процессы в сфере оказания ИТ услуг. Следовательно подчиняются общим правилам бизнес-процессов.

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

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


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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Открыта регистрация на вебинар «Какой SLM нам нужен?»
      22 апреля в 11:00 по московскому времени приглашаем вас на бесплатный вебинар «Какой SLM нам нужен?» Управление уровнем услуг — тема далеко не новая, но и …
    • Путешествие заказчика. Примеры. Часть 2
      Новый видеоролик продолжает серию, посвящённую концепции путешествия заказчика (customer journey), рассматриваемой на учебном курсе ITIL® 4 Specialist: Drive Stakeholder Value …
    • Поток создания ценности — поток создания чего?
      Прочитав замечательную статью моего коллеги «Все говорят: «Поток!». А ты построй поток» и возникшую после неё дискуссию, я подумала, что довольно часто сталкиваюсь с вопросом, а …
    • Service science в основе ITIL 4
      В редакцию портала поступил вопрос: Здравствуйте!  Роман Журавлёв в статье «Главное про ITIL 4» "...отнес к важным преимуществам то, что ITIL 4 опирается на такую …
    • Все говорят: «Поток!». А ты построй поток
      «А это была совсем не шляпа. Это был удав, который проглотил слона. Тогда я нарисовал удава изнутри, чтобы взрослым было понятнее.»Антуан де Сент-Экзюпери, Маленький принц Переход …
    • Роль лидера в продуктовой команде
      Довольно много людей полагают, что ключ к развитию потенциала и расширению возможностей продуктовых команд — это вежливо дать понять их руководству, чтобы они перестали …
    • Канбан-метод будет принят в качестве национального стандарта РФ
      Федеральное агентство по техническому регулированию и метрологии Росстандарт совместно с инициативной группой признанных российских экспертов по Канбан-методу объявило о начале …
    • Коммуникации в гибридной команде
      Благодаря неумолимой поступи нашей новой нормальности всё явственнее проявляются контуры будущей организации труда. Всё очевиднее становится понимание, что работа будет …
    • DevDays Moscow пройдут 8-10 июня
      С 8 по 10 июня в Москве пройдёт конференция DevDays Moscow, посвященная разработке программного обеспечения. В программе конференции Актуальные доклады (40+ спикеров) 7 …
    • Мотивация разработчика В2В продукта
      Команда создания и развития продукта состоит из разных людей: разработчиков, аналитиков, QA, владельца продукта и, иногда, из иных участников. Основной костяк этой группы …
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT