Блогер ITSM Professor изложил свою точку зрения на разницу между процессами управления изменениями и релизами.
Часто возникает путаница между целями, полномочиями и ролями этих двух процессов. Но на самом деле их задачи очень и очень разные.
Изменения рулят! Процесс управления изменениями (УИ) – авторитарный процесс, который должен управлять любым явлением, потенциально влияющим на новые или изменённые услуги. УИ одновременно способствует инновациям и оберегает стабильность. Прежде всего это процесс управления рисками. А ещё это процесс планирования.
В то же время, процесс управления релизами (УР) процесс действия. По распоряжению от УИ, УР создаёт, тестирует и выпускает новую или изменённую услуг в продуктивную среду. Каждый релиз состоит из одного или нескольких изменений. Это более технический процесс, чем УИ.
Если выстроить эти процессы грамотно, можно избежать лишней бюрократии, создав набор моделей изменений и релизов, задающих степень жёсткости контроля, для разных уровней рисков. Чем более зрелыми являются эти процессы, тем больше будет стандартных изменений…
Однажды студенты спросили меня о связи между проектами, офисом управления проектами (PMO) и процессами УИ и УР. Помните – УИ и УР это всего лишь процессы, сами они ничего не делают, а должны выполняться людьми. Каждый проект будет запускать несколько изменений в инфраструктуре, приложениях и документации. Каждое изменение будет либо уникальным, либо исполняемым по существующей модели. Релизы, создаваемые проектом, могут обрабатываться по одному, последовательно или собираться вместе, если это рационально. PMO должен управлять проектом, и я полагаю, что он же и будет управлять и связанными с ним изменениями.
Напомним, что по этому поводу уже высказывался, например, Ян ван Бон, а мы провели вебинар на эту тему.
Как вам аргументация Профессора, коллеги?
Жаль что только сейчас увидел этут статью ((
На мой взгляд эта статья немного расходиться со статьей Ян ван Бона.
Ян в своей статье говорит о том, что анализ всех изменений и "объединенных" изменений, т.е. релизов, лучше проводить в рамках одного процесса, а тут как раз получается, что оценкой уровня воздействия релизов на продуктивную среду зангимается процесс управления релизами…
Или я чего-то не понял?
P.S. Понятно что все зависит от масштаба компании и спроектированных процессов, если все находится в одном процессе, то это как раз то, о чем писал Ян. А если процессов все-таки два? Оценивать риски внедрения релизов в релизах или отдавать эту информацию в изменения для оценки и планирования (занесения в общий график)?