В последнее время проектная жизнь настойчиво сталкивает с процессом управления изменениями и подготовкой к его имплементации. Точно не ошибусь, если скажу, что если взять произвольную организацию в наши дни, то приложения (бизнес-критичные) в ней будут развиваться итерационным способом. Поддержка и развитие аппаратной вычислительной инфраструктуры, скорее всего, все ещё будет осуществляться проектно-водопадным способом, в силу очевидной дискретности преобразований/закупок.

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

Аналогичные мысли о месте процесса в цепочке создания ценности посещали и меня, когда я участвовал в бизнес-симуляции “Проект Феникс”. Одной из действующих ролей там выступал как раз процесс управления изменения, и он ощущался весьма чуждым элементом: затратной деятельностью без  особой видимой выгоды для дела или для организации.

Казалось бы, так давайте откажемся от него?

Нет, увы. Этот процесс нам все таки будет нужен.

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

– У нас есть команда поддержки жизненного цикла приложения, она и обеспечит минимизацию риска и своевременность доставки. Они делают это лучше всех остальных и справляются с этим сами, именно поэтому мы их и наняли, ведь так? Ага, а значит процесс управления изменениями не нужен!

– Действительно, процесс управления изменения не нужен команде для формализации преобразований внутри области ответственности команды, но он нужен вне её.

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

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

Значит процесс управления изменениями нам все таки нужен. Но какой он должен быть?

Нам не подойдет формальный, не адаптированный процесс. Мы просто не сможем получить от него достаточную пользу, т.к. изменения, интересующие нас, сложны и системны. Нам нужен интегрированный в производственный конвейер процесс, обладающий существенным уровнем зрелости, не меньше. Поясню:

1. Процесс должен работать быстро, мы не должны замедлять скорость преобразований.
2. Процесс должен быть качественным на каждом его шаге. Мы помним, что перед нами стоят сложные кросс-системные проблемы, требующие компетенций для анализа, планирования и реализации, а также для координации всей этой кухни. Если что-то из этого будет сделано “спустя рукава”, то мы не уменьшим наши риски и только потратим время впустую.
3. Процесс должен быть строго очерчен “сверху и, особенно, снизу”, мы не должны тратить ресурсы на то, что не требует этого.
4. Процесс должен быть естественным образом встроен в коммуникации и конвейер команд, осуществляющих преобразования. Команды разные, работают с разной скоростью, используют разные инструменты и наша задача заставить их работать вместе: смотреть не только “внутрь” на свой продукт, но и “во вне”, на продукты коллег, которые зависимы от них.
5. Процесс должен быть обеспечен информацией и инструментами для оценки влияния системных преобразований. Каждый элемент инфраструктуры имеет владельца, со стороны ИТ и/или бизнеса: приложения и их модули, интерфейсы, учетные записи, оборудование, данные, наконец. Целое облако взаимосвязанных заинтересованных лиц. Ещё есть подрядчики, которые участвуют в наших цепочках оказания  услуг. Для определения реальных стейкхолдеров, связанных с преобразованием, нам будет нужна конфигурационная информация об архитектуре услуг, приложений, аппаратной инфраструктуры, взаимосвязях, интерфейсах. Без неё оценка влияния системного изменения обречена на провал.

Вот так, коллеги.