В своей первой в новом году колонке на itsmportal.com, голландский эксперт Ян ван Бон рассказал о недавней дискуссии на тему связи процессов управления релизами и изменениями. Он резюмировал свою позицию так:

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

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

По моему мнению, планирование, тестирование и приёмка изменений и релизов нужно проводить совместно, так как и те и другие окажутся в итоге в одной и той же продуктивной среде.

В ITIL последних редакций, традиционный процесс управления изменениями оказался разделен аж на 5 компонентов:

• Подтверждение и тестирование услуг
• Планирование и поддержка преобразования
• Управление релизами и развертыванием
• Оценка изменений
• И… управление изменениями

Вот на этой остановке я сойду. Это непохоже на «лучшие практики». Эта конструкция описывает только управление изменениями в очень крупных компаниях, где сложность процедур является вынужденной мерой.

Для подавляющего большинства остальных организаций это неприменимо. Тем не менее, они тоже управляют изменениями, и пытаются их группировать. В компании может даже существовать роль менеджера релизов, который будет обязан группировать изменения. Но процесс всё равно называется «управление изменениями».

Если процессы разделять, то произойдет потеря качества из-за избыточности архитектуры процессов.

Решение очень простое: при определении вашего процесса управления изменениями, уделите внимание виду деятельности «планирование группировки изменений», а процесс управление изменениями должен применяться ко всем изменениям.

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

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление изменениями и конфигурациями в ИТ

Повысить долю успешных изменений, снизить риски, знать всё про конфигурации