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

Профессорская точка зрения: управление изменениями и релизами

Блогер ITSM Professor изложил свою точку зрения на разницу между процессами управления изменениями и релизами.

spotthedifference

Часто возникает путаница между целями, полномочиями и ролями этих двух процессов. Но на самом деле их задачи очень и очень разные.

Изменения рулят! Процесс управления изменениями (УИ) – авторитарный процесс, который должен управлять любым явлением, потенциально влияющим на новые или изменённые услуги. УИ одновременно способствует инновациям и оберегает стабильность. Прежде всего это процесс управления рисками. А ещё это процесс планирования.

В то же время, процесс управления релизами (УР) процесс действия. По распоряжению от УИ, УР создаёт, тестирует и выпускает новую или изменённую услуг в продуктивную среду. Каждый релиз состоит из одного или нескольких изменений. Это более технический процесс, чем УИ.

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

Однажды студенты спросили меня о связи между проектами, офисом управления проектами (PMO) и процессами УИ и УР. Помните – УИ и УР это всего лишь процессы, сами они ничего не делают, а должны выполняться людьми. Каждый проект будет запускать несколько изменений в инфраструктуре, приложениях и документации. Каждое изменение будет либо уникальным, либо исполняемым по существующей модели. Релизы, создаваемые проектом, могут обрабатываться по одному, последовательно или собираться вместе, если это рационально. PMO должен управлять проектом, и я полагаю, что он же и будет управлять и связанными с ним изменениями.

Напомним, что по этому поводу уже высказывался, например, Ян ван  Бон, а мы провели вебинар на эту тему.

Как вам аргументация Профессора, коллеги? 

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

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

  • Андрей

    Жаль что только сейчас увидел этут статью ((

    На мой взгляд эта статья немного расходиться со статьей Ян ван Бона.

    Ян в своей статье говорит о том, что анализ всех изменений и "объединенных" изменений, т.е. релизов, лучше проводить в рамках одного процесса, а тут как раз получается, что оценкой уровня воздействия релизов на продуктивную среду зангимается процесс управления релизами…

    Или я чего-то не понял?

    P.S. Понятно что все зависит от масштаба компании и спроектированных процессов, если все находится в одном процессе, то это как раз то, о чем писал Ян. А если процессов все-таки два? Оценивать риски внедрения релизов в релизах или отдавать эту информацию в изменения для оценки и планирования (занесения в общий график)?


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;