Вопрос практикам и специалистам по управлению изменениями задает Владимир:
Немного философский вопрос, но очень интерисует ответ на него. Возможно ли построение Change Management без CMDB, например только на картах ИТ-услуги?
Коллеги, может у кого-то есть подобный опыт?
ITIL Intermediate: Release Control and Validation
У нас Change mgmt несколько лет вполне себе успешно жил без CMDB (в ближайшем будущем начнёт с ней, надеюсь).
Да, сложнее с оценкой влияния, но это же не единственное для чего процесс строится. Планирование, формирование планов проведения/отката, согласование простоя и времени выполнения, необходимых ресурсов, даже оценка рисков (но с этим хуже) могут успешно выполняться и без CMDB.
На самом деле, всё очень зависит от цели, с которой планируется запуск CHG.
А для оценки можете озвучить количество изменений за период (неделя, месяц, год)?
И, до кучи, как осуществлялось управление проектами? Не пересекалось ли с управлением изменениями?
Изменений от 100 и более в месяц.
Управление проектами использует управление изменениями:
Если в рамках проекта нужно провести изменение в боевой инфраструктуре (например, новый релиз) — оформляется RFC. Изменения на тестовой инфраструктуре не покрываются процессом CHG.
М-м-м. Разаработка софта? или какая специфика ИТ? Приблизительное количество "ресурсов" в "инфраструктуре"?
Компания ИТшного профиля с развитой инфраструктурой.
Что понимается под "ресурсом": люди или железо?
Значит — поддержка. ОК. Развитая инфраструктура предполагает управление конфигурациями (и/или сервисными активами), не так ли? Как это пересекается с управлением изменениями? Нет ли путаницы?
Не понял вопроса. Управление изменениями и управление конфигурациями не пересекаются: они дополняют друг друга.
Просто я подвожу Вас к мысли, что те цели, которые Вы описали вначале, прекрасно укладываются в процесс "Управление сервисными активами и конфигурациями". И одним из _почти обязательных_ результатов этого процесса есть CMDB. При этом не было упомянуто ничего, что могло бы однозначно указывать на процесс "Управление изменениями".
Абсолютно согласен с Юрием:
1. CHG без CFG возможен (и, конечно, наоборот).
2. Все зависит от того, какие задачи Вы решаете процессом управления изменениями.
Например, у многих организаций есть процесс управления изменениями в прикладном ПО (который обычно так даже не называется, а называется, скажем, регламент разработки и доработки прикладных систем или что-то вроде этого). И этот процесс решает задачи организации взаимодействия заказчиков (бизнес-подразделений) и разработчиков (ИТ-подразделения). При этом вполне себе обходится без CMDB. И даже больше — это часто процесс "разработческий", а CMDB себе строят "эксплуататоры". То есть этот процесс не только живет без CMDB, он даже живет рядом с CMDB, не замечая ее 🙂
В теории область охвата CMDB и CHG совпадают. В реальной жизни — довольно часто различаются.
Что мы посчитаем за CFG\CMDB ... это обязательно единый подход, описанный и согласованный на уровне IT департамента или практика учета (пусть и своя для различных подразделений в IT Департаменте), участвующая своими результатами в CHG?
Как вы думаете, может не быть процесса CFG\CMDB в организации с несколькими локальными офисами по всему миру, с парком в десяток тысяч единиц оборудования, с фаршем стандартных корпоративных бизнес систем и дополнительно несколькими world-wide критичными бизнес приложениями?
Вряд ли, конечно — что-то в каком-то виде обязательно будет. Но область охвата такого учета (таких практик учета — их может быть несколько в разных отделах / группах департамента ИТ) может существенно не совпадать с областью охвата управления изменениями (которых тоже может быть несколько в разных отделах / группах). Мы такое наблюдали в реальной жизнине раз и не два.
Не попиманю, если честно. Как можно понимать, что меняется, если нет учета, что есть. На коленке, по памяти, но процесс-то есть.