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

Моделирование изменений, как инструмент преодоления разногласий

Лебедь_рак_и_щука_2_2Что делать, когда единые правила не работают? Когда разные группы участников одного процесса работают по своим правилам? Причём, не из прихоти, а в силу определённой специфики своей деятельности?

В качестве примера рассмотрим знаменитую историю про трёх товарищей, которые не смогли сдвинуть с места воз с поклажей. Ведь золотые слова написал Иван Андреевич! Но можно взглянуть на проблему и чуть с другой стороны. Все трое ведь банально РАЗНЫЕ! И по-другому не могут! Значит, надо их правильно организовать. Менеджера процесса на них нет, да с регламентом! Только вот ведь незадача: смотри пункт 1 – они все разные. Ну нельзя им всем просто сказать: "Тащи вперёд". Надо лебедю объяснить, чтобы вдоль берега летел, да на одной высоте. Щуке вменить роль подводного буксира, движущегося вдоль камыша. Раку – назад ползти, видимо. Причём, регламент-то напрашивается общий. Например: загружаем-впрягаемся-тянем-выгружаем. А дальше пошла специфика… Например, первым действием лебедя на этапе "Тянем" будет "взлететь на высоту не более Х", а у щуки – "нырнуть на глубину не более Y". То есть получается, что есть некий высокоуровневый процесс, состоящий из обязательных шагов. А внутри каждого этапа все действуют с учётом своих особенностей.

Департаменту ИТ ведь тоже надо общий воз вести, а на нём… не буду перечислять бренды производителей различных информационных систем, но вы понимаете. Какого только добра нет! И проприетарные, и самопальные, и ещё порталы с сайтами. Порядок согласования функционального задания разный, разработки разный, и публикуются изменения по некоторым сразу по готовности, а по некоторым – по релизной схеме. А ещё бывают комплексные изменения – это когда все вместе реально в одну телегу впрягаются и несколько систем переделывают, да ещё должны одновременно этот воз на продуктив выгрузить.

То есть, говоря формальным языком, нужно обеспечить, казалось бы, несовместимое:

  • внедрить единый процесс управления изменениями, охватывающий все информационные системы заказчика;
  • при этом учесть специфику выполнения изменений по отдельным ИТ-системам.

Выполнить такую задачу очень помогает подход с применением моделей изменений. Схематично всё выглядит примерно так:

Концепция_моделей_процесса

Как уже было сказано выше, нужно описать высокоуровневый процесс, состоящий из обязательных этапов. А в моделях изменений описать детализацию этапов. И много чего ещё полезного, что не удаётся внести в общий регламент и распространить на изменения всех информационных систем.

На самом деле подход достаточно универсальный и может применяться не только для управления изменениями. Но сейчас я хочу предложить вам, уважаемые читатели портала REALITSM, немного поговорить именно про модели изменений. И поговорить в следующем формате:

  1. вы зададите в комментариях вопросы, которые у вас возникли по указанной теме до, во время или после прочтения данной заметки;
  2. ваш покорный слуга постарается ответить на присланные вами вопросы во время вебинара, запланированного на весеннюю CleverTALK-сессию.

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

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

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

  • Александр

    Я сейчас работаю по такой схеме, основная проблема с которой я сталкиваюсь – синхронизация и скорость релизов по разным ИТ-решениям. Запросы на изменения идут комплексные, переносить в продуктив их надо одновременно, а вот релизы выстроить одновременно очень сложно. Бизнес заказчик у разных систем разный, в разные время дает окна под релизы и синхронизовать окна очень сложно (часто невозможно). Вообще в нынешних реалиях (читай Грефа) бизнес ожидает, что переносить будем день в день, а в релизы так не построишь. 

     

    Внимание – вопрос, что делать ?

  • Андрей

    Автоматизация – наше всё. На самом деле под эту задачу уже есть инструменты, которые позволяют описать не только верхнеуровневые процессы, но и конкретные алгоритмы. В качестве примера – CA Release Automation(тут последнее время стало модным на эту компаню ссылаться :)) (http://www.ca.com/us/devcenter/ca-release-automation.aspx?cid=NA-EAM-CBU-AAU-000136-00000734)

    Что касается упомянутого Грефа, то тут есть проблема. Правильная в общем цель выражена через неправильные показатели. Это как с тракторами в советское время. Был выдвинут лозунг , что для повышения производительности на селе нужны тракторы, следовательно нужно боьше тракторов. В результате по этому показателю мы опережали Америку раза в три, а жрать все равно нечего было. Так же и с количеством релизов. Это косвено указывает на призводительность Release Management, но в конечном счете приведет к релизам ради релизов. Более правилный показатель – скорость внедрения изменения. А уж сколько этих изменений будет не так уж и важно, главно, чтобы те изменения, что нужны, внедрялись бы с максимальной скоростью. А для этого неоходимы инструменты.

  • Максим

    Необходимость модели изменений описана в курсе RCV.

    Так что ваш подход соответсвует ITIL))


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM