Стюарт Рэнс, один из авторов текущей версии библиотеки ITIL, в своей заметке When Should ITSM Change Management Start рассуждает о процессе управления изменениями:
«У большинства организаций есть процесс управления изменениями. Обычно он включает такие шаги, которые гарантируют, что изменение не вызовет негативных последствий. Для инициирования процесса управления изменениями регистрируется RFC, и тогда это изменение рассматривается на предмет того что: необходимое тестирование проведено, вопросы безопасности и риски рассмотрены, все регламенты и стандарты взяты в расчет, etc. Процесс управления изменениями также составляет график изменений, чтобы предотвратить конфликты – например, когда для двух разных изменений требуются одни и те же ресурсы.
Одно большое отличие между организациями автор видит в том, в какой момент жизненного цикла изменения создается RFC.

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

Однако, согласно ITIL организации должны создать RFC прежде чем кто-то начинает проектирование или сборку изменения, чтобы позволить процессу рассмотреть затраты, риски и выгоды до авторизации деятельности по проектированию.

Итак, какой вариант верный? Что нужно делать?

Автор считает оба подхода неверными. Создавать RFC после того, как произведена сборка изменения слишком поздно. А создавать RFC прежде, чем начнутся какие-то работы (то есть на этапе принятия решений финансирования) – не сработает, потому что в большинстве организаций есть другие процессы, принимающие решения по инвестированию, и в это они не вовлекают процесс управления изменениями.

Кто принимает решения по инвестированию?

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

Другими словами, это просто непрактично призывать большинство организаций создавать RFC до момента принятия решения по инвестированию в ИТ изменения, и такого просто никогда не случится.

Но это не должно быть или или 

В большинстве организаций управление IT изменениями не привлекается до полного завершения сборки тестирования. Это приводит к очень неэффективному процессу, где все останавливается, пока процесс управление изменениями оценивает проделанную работу и решает, готово ли изменение к развертыванию. Управление изменениями тогда рассматривается как препятствие этому самому изменению. Но если процесс управления изменениями не был привлечен прежде, чем были приняты инвестиционные решения, и RFC создан после дизайна, то сборка и тестирование неэффективен и приводит к замедлению работы. Что мы можем сделать? Фокус в том, чтобы перестать думать об этом как о проблеме, а вместо этого создать RFC так рано, как это возможно.

Выгоды от раннего запуска процесса управления изменениями

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

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

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

Даже если этот процесс не привлекается к принятию решений по инвестициям, и даже если вы еще не знаете, когда будете готовы развернуть изменение, вы можете создать RFC и наполнить информацией, которая у вас уже есть на тот момент.Когда вы это делаете, вы даете команде процесса время на:
– подумать о графике и конфликте ресурсов, не доводя до задержек в развертывании
– идентифицировать и скорректировать состав авторизующего органа
– позволить авторизующему органу проводить оценку до момента развертывания
– позволить авторизующему органу предоставить необходимые входы для людей, которые занимаются сборкой и тестированием
В идеале, независимо от того как вы инициируете изменения, как принимаются решения относительно ресурсов и финансов, необходимо спроектировать полную цепочку шагов, которая позволит создать ценность заказчику.

Далее максимально автоматизируйте цепочку создания ценности. Это может включать своевременное представление RFC без необходимости заполнения формы, потому что информация уже доступна в информационной системе. Большинство оценок могут быть проведены в системе, а любые ручные проверки могут быть завершены до развертывания. Как результат, – все изменения проходят оценку на предмет соответствия целям организации по вопросам безопасности, рисков и соответствия требованиям регуляторов, при этом процесс не задерживает развертывания».