Искусство управления изменениями в бизнес-менеджменте

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

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

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

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

· за счет использования высвобождаемого на других задачах ПО и оборудования;

· вместо другого запланированного в бюджете изменения;

· за счет экономии бюджета (по остаточному принципу);

· за счет резервов сверх бюджетных фондов (хотя обычно оказывается проще дождаться следующего года).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· одни и те же участники (service manager, менеджеры систем и эксперты по прикладному ПО, представители заказчика, финансовые службы);

· похожие потенциальные риски (недоступность системы, потеря данных) и сходные пути борьбы с ними (тестирование, резервное копирование, планирование отката);

· потенциальный переход в формат проектной деятельности;

· часто — одни и те же источники финансирования;

· неизбежный перерыв в предоставлении ИТ-услуг при реализации и необходимость его оптимально спланировать.

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

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

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

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

 Скачать реферат