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

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

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

«VAP: Управление изменениями и конфигурациями в ИТ»
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

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

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

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

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

    • Я встречал. Но все имена – приватно.

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

      • Grigory Kornilov

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

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

  • Grigory Kornilov

    Коллеги, предлагаю сортировать вединары по дате desc

  • У нас уже не в первый раз сходятся мысли, Дима )


Добавить комментарий для Дмитрий ИсайченкоОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM