Универсальный процесс

Сегодня мы поговорим об управлении изменениями (Change Management). Управление изменениями по праву считается ключевым процессом, если не в ИТ вообще, то в части поддержки сервисов — точно. Даже если просто регулировать перерывы в предоставлении услуг, когда проводятся различные работы в ИТ-инфраструктуре, этот элементарный порядок уже дает реальный и ощутимый эффект. И самая простая фильтрация предлагаемых к реализации новшеств на соответствие корпоративной технической политике, будучи реализована, за два-три года позволит существенно улучшить стандартизацию ИТ-решений и соответственно снизить расходы. А уж более зрелая организация процесса… Но давайте по порядку.

Определения и теория

Изменение — процесс перехода из одного определенного состояния в другое.

Комитет по изменениям (change advisory board, CAB) — группа специалистов, которые привлекаются для согласования, предоставления экспертных рекомендаций и оценки результатов изменений.

Перспективный план изменений (forward schedule of change, FSC) — документ, содержащий сведения обо всех утвержденных изменениях и предлагаемые даты их внедрения. Документ для персон‑специалистов, участвующих в изменениях.

К области деятельности процесса управления изменениями относятся следующие изменения:

а) в аппаратном обеспечении;
б) в коммуникационном оборудовании и ПО;
в) в системном ПО;
г) в прикладном ПО, находящемся в эксплуатации;
д) во всей документации и процедурах, связанных с работой, сопровождением и поддержкой информационных систем, находящихся в эксплуатации.

Далее по тексту изменения, связанные с объектами группы «а» — «в», мы будем называть инфраструктурными, а изменения, связанные с объектами группы «г» — «д», будем называть модернизацией прикладных систем.

Как выглядит идеальная схема организации управления изменениями в достаточно крупной компании? Все изменения на основании различных признаков разделяются на два потока. Первый из них, к которому относятся стандартные, типовые, повторяемые и прочие подобные изменения, управляется набором соответствующих регламентов (правил, инструкций и т. п.). Второй из них, куда относятся изменения бизнес-критичные, сложные, затратные по ресурсам или срочные, управляется коллегиальным органом, именуемым CAB.

В состав CAB, по классической модели, должны входить:

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

Некоторые эксперты рекомендуют еще дополнительно включить в состав CAB следующих членов:

• представителей служб информационной безопасности;
• представителей финансовых служб;
• менеджеров проектов;
• представителей служб материально-технического снабжения.

Важный момент: состав CAB может значительно изменяться и варьироваться в зависимости от списка рассматриваемых изменений.

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

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

Интеграция с управлением финансами

Как правило, 60—80% изменений требуют финансовых затрат. Это относится и к инфраструктурным изменениям (расходы на приобретение ПО и оборудования, работы и услуги), и к модернизации прикладных систем (работы и услуги).

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

Практически всегда средства в ИТ-бюджет выделяются адресно, на решение определенной задачи или реализацию открытого проекта или его этапа. Ситуации, когда некоторая сумма денег выделяется без адресной привязки, обычно связаны с различного рода операционными темами (например, оплата услуг связи обычно планируется по исполнению предыдущего года). Но и в этом случае при подготовке и защите бюджета обычно требуется дать обоснованную оценку сокращения/увеличения объемов.

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

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

Интеграция с проектной деятельностью

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

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

Управленческая практика

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

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

Реальные возможности CAB

Исходя из вышесказанного, реальная свобода действий CAB сильно ограничена.

Можно попытаться в состав CAB включить менеджеров компании с высокими уровнями полномочий, что само по себе является сложной задачей. Но из такого орудия по воробьям стрелять не будешь, и такой орган скорее подходит для управления корпоративными ИТ-проектами.

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

Кстати говоря, сама задача кооптирования в состав CAB представителей заказчиков и групп пользователей представляется весьма нетривиальной. По причинам, изложенным выше, заказчики (даже если они понимают, что они — заказчики) не получают от участия в CAB возможностей серьезно влиять на ситуацию. А вот дополнительные обязанности и ответственность у них при участи в CAB появляются.

В стандартной ситуации CAB (если он есть) состоит из сотрудников ИТ и работает исключительно внутри корпоративной ИТ‑службы. В этом случае CAB может только повысить эффективность подготовки изменений и более грамотно осуществлять календарное планирование изменений.

Изменения в прикладном ПО

Еще один существенный аспект: классический ITIL, вообще говоря, однозначно не включает в управление изменениями доработку и/или разработку прикладного ПО. А ведь для большинства заказчиков оперативное и своевременное исправление ошибок, изменение функциональности вследствие изменений в бизнес-процессах, расширение функциональности прикладного ПО имеют значительно большую ценность, чем устойчивый доступ к бизнес-приложению и качественное обслуживание. И никуда не денешься — процедуры обработки запросов на доработку/разработку прикладного ПО приходится выстраивать.

Причем сходство между «классическим» процессом управления изменений ITIL и подготовкой и внесением изменений в прикладное ПО очень большое:

• одни и те же участники (Service Manager, менеджеры систем и эксперты по прикладному ПО, представители заказчика, финансовые службы);
• похожие потенциальные риски (недоступность системы, потеря данных) и сходные пути борьбы с ними (тестирование, резервное копирование, планирование отката);
• потенциальный переход в формат проектной деятельности;
• часто — одни и те же источники финансирования;
• неизбежный перерыв в предоставлении ИТ-услуг при реализации и необходимость его оптимально спланировать.

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

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

Предлагаемая модель

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

• планирование и подготовка изменения;
• реализация изменения;

На этапе планирование и подготовки изменения, связанные с ИТ-инфраструктурой, производятся в формате CAB. При этом, поскольку они не затрагивают бизнес-приложений, вполне достаточно наличия CAB, состоящего только из сотрудников ИТ‑служб. Чтобы создать такой орган, обычно вполне достаточно полномочий CIO (ИТ-директора).

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

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

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

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

Пишите автору по адресу asennator@gmail.com

И все таки обратитесь к ITIL

Антон Лыков,
Solution Architect, ITSM HP Software & Solutions Professional Services

Процесс управления изменениями — действительно один из самых дискуссионных в той модели, которую предлагает библиотека ITIL. Автор рассказывает в статье о своем опыте реализации данного процесса. С практической точки зрения мысли очень дельные. Тем не менее я посоветую всем прочитать «первоисточник» (ITIL) до того, как вы реализуете данный (да и вообще любой) процесс у себя. И еще один раз — после того как «набьете шишек», разворачивая процесс в своем ИТ-подразделении.

И я как представитель «ортодоксального» ITSM не могу не обратить внимание на следующие вопросы, о которых говорит ITIL, но которые остались за скобками в данной статье. Нужна ли в ИТ-организации роль менеджера изменений? Какие обязанности и полномочия должны быть у этого человека? Можно ли доверить одному ему принятие решений по всем изменениям в инфраструктуре и приложениях?

Change Advisory Board (CAB) — орган, принимающий решения, или совещательный орган?

Какими на практике могут быть критерии, позволяющие отделить изменения от проектных работ? Делаются ли изменения в рамках существующих соглашений об уровне услуг (SLA), или выполнение изменений всегда приводит или может привести к корректировке SLA?

На самом деле, конечно, приходится искать компромиссы между теорией и ее применимостью, учитывая уровень зрелости компании в целом и ИТ-подразделения в частности. Главное, на мой взгляд, при внедрении любого процесса — понимать, от каких рекомендаций ITIL вы отзываетесь или «корректируете» их с учетом своей специфики, и чем это может вам обернуться.

И еще одна важная вещь, о которой не упоминает автор статьи, — необходимость не только управлять изменениями в инфраструктуре или в ПО, но и понимать, что эти изменения очень часто нужно сопровождать с точки зрения изменения поведения людей (или организации в целом). Очень важно доносить до людей суть проводимых изменений. Именно это способствует тому самому IT and business alignment, о котором так много говорит ITIL.