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

Мы-таки провели этот вебинар (давно уже собирались). Вопрос поднимался неоднократно, системного ответа не было. Теперь, как мне кажется, есть: 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. Роман Журавлёв

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

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

    ***

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

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

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

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

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

      0
      0
      1. Grigory Kornilov

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

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

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

    0
    0

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

НОЯ
27
Учебный курс:
Основы ITIL (очно)