Управление изменениями и релизами: один или два процесса

Мы-таки провели этот вебинар (давно уже собирались). Вопрос поднимался неоднократно, системного ответа не было. Теперь, как мне кажется, есть: https://cleverics.ru/subject-field/webinars/46-core/webinars-and-video/380. Если есть вопросы – велкам, обсудим. Специально для этого и создал этот пост.

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Release Control and Validation

Учебный курс: преобразование и контроль ИТ-услуг, управление изменениями, релизами и конфигурациями, а также построение CMDB — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Роман Журавлёв

    Ну, вопрос очевиден. Как ты это делаешь? Я тоже хочу такой мозг.

    Как всегда, очень убедительно и системно. Спасибо.

    ***

    А еще у меня вопрос ко всем, не только к ДИ. Коллеги, кто-нибудь встречал в жизни организацию, где во внутреннем ДИТе работал бы «длинный» процесс управления изменениями? Во внутреннем — ибо у коммерческого сервис-провайдера он, надо понимать, обязан быть именно длинным...

    1. Дмитрий Исайченко Автор

      «у коммерческого сервис-провайдера он, надо понимать, обязан быть именно длинным»

      Как раз в этом я очень сомневаюсь. Внешний провайдер обычно отвечает или за разработку (тогда про него вообще REQ-DEV-REL), или за эксплуатацию, или за сопровождение и эксплуатацию. В последнем случае у него «средний» CHG — с доработками, но без бизнес-анализа, поскольку точкой входа в этом случае, как правило, являются функциональные требования (бизнес-анализ — на стороне заказчика). А значит услуга опять system-centric (SaaS).

      То есть наверно бывают и другие сценарии, но утверждение «обязан быть именно длинным» мне кажется слишком сильным.

      1. Grigory Kornilov

        Интересно, что делается при 'длинном варианте', если надо реализовывать SP на ПО вендора или прошить оборудование. Предположим, что работа потоковая\постоянная, в некоторых случаях требует downtime оборудования, иногда сервиса. Так как это часто процесс идет на инфраструктуре, то небольшое изменение может вызвать downtime не одного сервиса.

  2. Роман Журавлёв

    Да, верно, тут нужна поправка. Под «внешним провайдером» я имел ввиду тот самый аутсорсинг, который, как говорят, не растет на нашей почве, во многом — из-за моды на дочерние структуры с теми же функциями. А равно — самих этих дочек. То есть сервис-провайдера полного цикла, претендующего на то, чтобы полностью взять на себя заботы об информационных технологиях у/для заказчика.

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

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

Empty