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

Одинокий процесс управления изменениями

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

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

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

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

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

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

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

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

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

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

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

ITIL 4 Foundation, MPT, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от участников разработки

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


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

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

  • Рубрики

  •  
  • Самое свежее

  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT