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

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

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

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

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

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

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

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

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

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

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

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

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. Александр

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

     

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

  2. Андрей

    Автоматизация — наше всё. На самом деле под эту задачу уже есть инструменты, которые позволяют описать не только верхнеуровневые процессы, но и конкретные алгоритмы. В качестве примера — CA Release Automation (тут последнее время стало модным на эту компаню ссылаться :)) (www.ca.com/us/devcenter/c... -000136-00000734)

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

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

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

Empty