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

Думаю, что ни для кого из наших читателей не является тайной, что известные источники рекомендуют проектировать и внедрять эти процессы совместно, т.к. синергия и совместное влияние этих процессов друг на друга действительно очень велики.

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

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

• Внедрение, становление (кстати, хорошее слово) и взросление процесса требует значительного времени для преодоления отторжения и принятия, для достижения желаемого охвата.
• Людям, исполняющим свои задачи в процессах низкой зрелости, особенно на начальных этапах, сложно сформулировать вменяемые требования к смежным процессам, т.к. они еще борются со своим процессом, пытаясь получать от него ожидаемую пользу. 

Давайте взглянем, с какими трудностями мы встречаемся в ходе развития этих процессов преобразования услуг.

Начнем с процессов управления изменениями и управления релизами.

На ранних этапах можно говорить об этих процессах как об одном объединенном процессе, включающев в себя фазу "build".

Назначение и основная польза от этих процессов состоит в том, чтобы иметь все возможности в части "change the business", не увеличивая для этом размер затрат и усилий на "run the business". В стремлении освоить умение управлять рисками при проведении изменений, на самом начальном этапе возникает соблазн пойти по пути "от простого сложному". И в этот на самом деле нет ничего плохого. Посмотрим как это получается в жизни. Поскольку природа формацизации процесса носит бюрократический характер, то охват запускаемых процессов ограничивается. Например, мы забываем об услугах, как о конструкциях высшего порядка и начинаем говорить только об инфраструктуре, инфраструктурных изменениях. Более того, мы говорим не обо всей инфраструктуре, а только о той, которую мы назвали критической, ограничивая себя только инфраструктурой обеспечивающей продуктивную среду.

Этот подход с одной стороны позволяет формально запустить процесс, обеспечивая его формальное соблюдение. С другой стороны, поскольку бюрократические и внешне бесполезные для исполнителей процесса процедуры не любит никто, то сопротивление процессу на этом этапе действительно велико и оно является долгосрочным. Задекларированное "всеобщее обещанная польза и благоденствие" разбиваются о реальность и вызывают разочарование.

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

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

• Появляется нужда в появлении актуального каталога услуг, со всей информацией и владельцах, заказчиках, потребителях, бюджетах.
• Возникает острая потребность в конфигурационной информации, причем не просто в информации об отдельных объектах инфраструктуры, а о связях между ними, о связях с услугами. Потребность в сервисно-ресурсной модели.
• Как только мы переходим от конфигурационных единиц к услугам, процесс управления релизами перестает умещаться в процесс управления изменениями. Возникают потребности в рациональной организации полноценного внедрения пакетов изменений, включая тестирование, обучение, первичную поддержку, если ранее они были просто разрозненными активностями вроде "перебрасывания дистрибутива через забор". Управление релизами начинает заниматься реализацией организационных изменений, изменений услуг.

На этом этапе приостановимся с этими процессами и вернемся чуть-чуть назад.

Взглянем на процесс управления конфигурациями.

Трудно спорить, что процесс управления конфигурациями немыслим без запущенного учета в виде управления ИТ-активами. В противном случае, задача идентификации, верификации и контроля жизненного цикла актива существенно затрудняется. Это же обстоятельство осложняет осмысленное использование первичной CMDB, т.к. она столь явно ассоциируется с базой активов, что приходится прилагать существенные усилия для разделения этих терминов.

CMDB – это авторизованное состояние конфигурационных единиц, а не то, что сейчас видит мониторинг.

Охват КЕ, лежащих в первичной CMDB, зачастую определяется возможностями мониторинговых средств и избыточен. База даных конфигурации замусорена данными, которые не важны для поддержки и оказания услуг. Как часто бывает, на старте в CMDB начисто отсутсвуют услуги, связи с ними и связи между конфигурационными единицами.

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

Если к моменту, когда мы таким образом создали "свою первую CMDB" потребность в данных лежащих в ней не возникает, то задекларированный процесс постепенно деградирует обратно до бухгалтерского учета активов. Это естественный ход вещей.

Ложка дорога к обеду. На данные CMDB должен быть ощутимый спрос со стороны различных заинтересованных сторон. Формальное наказание и (важно!) порицание от коллег за неактуальные данные должны быть такими же, какие могут быть вызваны злонамеренным нарушением SLA. Данные CMDB должны быть исключительно полезны и востребованы, исключайте из CMDB то, чем никто не пользуется. При этом можно спокойно продолжать вести учет активов не включенных в CMDB, все также не называя учет управлением конфигурациями.

О выводах.

Глядя на всю эту картину, можно сформулировать несколько тезисов, которые помогут запустить или улучшить процессы "святой" троицы:

1. Начните с каталога услуг. Услуги – это наш флагман, наша цель. Все наши усилия должны быть направлены на улучшение наших услуг, а не быть вещами в себе.
2. Ведите учет активов. Он будет нам необходим на всех этапах нашего пути.
3. Двигайтесь от простого к сложному. Гибкий подход в реальной жизни доказывает свою эффективность. Не проектируйте на старте космические корабли триединых в своей интеграции зрелых процессов. Пусть это будут три утлых суденышка, но мы хотя бы будем знать, что они плывут.
4. Создайте долгосрочный план развития этих процессов с учетом выших реалий. Сбор и подготовка данных о нужных активах, создание и поддержка связей между КЕ требует участия людей, их значительного вовлечения. Учитывайте при планировании свои возможности. 
5. Распланируейте этапы развития процессов так, чтобы они в нужные моменты поддерживали друг друга. Сервисно-ресурсные модели должны появиться в CMDB только тогда, когда на них будет спрос со стороны управления изменениями. Тратя время и деньги на их описание раньше обозначенного времени мы будем работать в стол. Lean, черт побери!
6. Контролируйте проходящие изменения как программу проектов, отслеживая отклонения и своевременно внося коррективы. ITSM инициативы нельзя просто запустить, ими надо жить. 

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление изменениями и конфигурациями в ИТ

Повысить долю успешных изменений, снизить риски, знать всё про конфигурации