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

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

По сути, организация мыслится производной, вторичной по отношению к стратегии (хотя «во многих компаниях наблюдается принципиально иная, обратная зависимость, то есть все происходит наоборот». — Майкл Портер о новых стратегиях совершенствования управления, из интервью журналу Organizational Dynamics). Такой же неотъемлемой частью процесса разработки стратегии является понимание внешней среды бизнеса и следование ей. При этом господствующая идея — организация должна изменяться! Майкл Портер, например, считает, что такое положение дел сложилось благодаря литературе. Описывая «новую экономику», авторы заявляют, что никакое преимущество нельзя сохранить. «…У компаний нет выбора, кроме как оставаться подвижными, гибкими и уметь быстро приспосабливаться». В основе такого подхода к стратегии — настойчиво продвигаемая идея, почти страшилка: компании могут выжить, лишь подстраиваясь под состояние внешней среды. Безумность современного мира, его непрозрачность и смутность, полная дерегулированность и изменчивость не поддаются рациональному осмыслению.

Вы должны изменяться, изменяться и изменяться… Вам это ничего не напоминает?! Словом, как гласит народная мудрость, не дай вам Бог жить во времена перемен. Может быть, такое понимание и реакция на дерегулированность современного мира, его деинституализацию и крушение традиционных норм вызвано тем, что, по словам Питера Друкера, мы живем в один из исторических периодов, когда люди перестают ориентироваться в окружающем мире и когда опыта прошлого недостаточно для вразумительного объяснения будущего. Не отсюда ли крайности? От полного отказа от сколько-нибудь перспективного планирования до перманентного изменения стратегий по любому кажущемуся существенным сигналу извне, вплоть до «Поворот все вдруг!».

А так ли уникальна эта наша нынешняя ситуация?

Давайте, заглянув в историю, спросим себя: «А был ли мир стабилен, прозрачен, дружелюбен и безопасен по отношению к Тейлору, Форду или Демингу?». Вряд ли. Ибо откуда же тогда выработанные ими (и иже с ними), ставшие канонами, требования менеджмента об устойчивых «правилах игры», предсказуемости, прозрачности, однозначности, как не из сумрака их непроницаемых миров?! Заметим, что даже в рамках классического менеджмента при умеренно критичном подходе к его постулатам оказывается, что они как раз и порождают так называемый феномен когнитивного сопротивления (Алан Купер) и когнитивных границ (Майкл Портер). Это явление едва начало осознаваться, и судя по всему следует ждать «нового веяния с Запада» — «теории/матрицы когнитивного диссонанса» (термин наш. — Прим. авт.) в качестве новейшего инструмента продвинутого менеджера. Хотя практика и показывает, что сегодня благодаря именно этим классическим представлениям компании живут и достаточно успешны в современном изменяющемся мире, заметим — абсолютно непредсказуемом.

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

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

А если поискать, следуя логике парадокса?

При всей кажущейся всеобщности и абсолютности идею об изменчивости мира разделяет лишь часть бизнес-сообщества. «Это, конечно, верно, но лишь частично» — по лояльной оценке того же М. Портера (из интервью Майкла Потера журналу Organizational Dynamics). Для одних из них продвижение этой идеи есть бизнес, заметим, достаточно прибыльный. Для других подготовка и проведение собственно организационных изменений — тоже бизнес и тоже прибыльный. Третьи праведно изменяют и изменяются.

А если «Стоп машина! Осмотреться!», остановиться и подумать, не следуя слепо идеям, «принесенным ветром»? Может, пришло время нового прочтения, расширения, дополнения, ревизии того, что уже наработано менеджментом. Точнее говоря, осмысления, ибо нужна аналитика на уровне смыслов бизнеса.

Непрозрачность и смутность мира, ускорение смены технологий не есть достаточное основание говорить об отсутствии правил и непрогнозируемости бизнеса. Для любого живущего «здесь и сейчас» мир есть, был и будет «этим безумным, безумным миром». Но безумность мира снимается по мере расширения горизонтов понимания и осознания. Если же мы не успеваем за ритмом мира, то его безумность возрастает. И бизнес-среда здесь не исключение.

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

Стратегия бизнеса немыслима без и вне организации

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

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

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

Логично предположить, что состояние «поля для игры в бизнес» уникально для каждой компании. Эта комбинация рыночных и организационных возможностей и ограничений в конечном итоге и предопределяет стратегический выбор, то есть направленность приоритетов, действий и ресурсов, критерии успеха и способы «делания» дела в данной компании. В идеале стратегический выбор должен поддерживать динамическое равновесие между внутренним и внешним миром организации.

И сегодня, как во все времена, бизнес — это делание дела и денег. И уже в самом определении бизнеса мы видим три его базовых, неизменных элемента:

задача, что ожидается в качестве результата;

функция, что должно быть сделано для его получения;

организация — средства и способы.

Как бы глубоко в даль веков мы не заглядывали, деньги зарабатываются на решении самой что ни на есть тривиально вечной задачи — обеспечении страждущих, то есть клиента, хлебом и зрелищами. В этом смысле печь пироги и тачать сапоги предстоит не только нам, но и многим грядущим поколениям. Конечно, способы и технологии меняются и будут меняться впредь. Так, позавчера под окнами махал метлой дворник. Вчера громыхал снегоуборочный комбайн. Сегодня мостовые и тротуары оборудуются системами «теплый пол». Завтра в небе будут парить большие снегососы. Мы не можем предсказать, что будет послезавтра. Бог его знает, куда культурно-технологическая кривая выведет. Но! Задача — деньги и функция — обеспечение чистоты — останутся. Значит, это будет чье-то дело, и кто-то будет на этом зарабатывать. Отсюда, как и всегда, потребуются и остальные атрибуты бизнеса, пусть и в иной упаковке, с иным названием и иными способами управления людьми, процессами, ресурсами, технологиями. А главное — целостность их взаимодействия между собой, то есть организация.

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

В этом отношении организация — всего лишь компромисс между желаемым и возможным. Если хотите — целостность, функционирующий организм, а вовсе не набор квадратиков и стрелочек, худо-бедно описывающих ее структуру, необходимый для получения результата не только с технологическими параметрами, но и нравственными люфтами и допусками. Не этим ли объясняется тот факт, что часть современных компаний представляют собой уродцев с гипертрофированно раздутыми отдельными частями, необходимыми для получения результата с точки зрения отца-основателя? Другие же не менее, если не более, жизненно важные «органы» атрофированы, а иногда и кастрированы по его же воле или недомыслию (читай — необразованности, невоспитанности и господства попсовой культуры управления).

Хотя и «нет в мире совершенства», как писал Антуан де Сент Экзюпери, может, к этому стоит стремиться?! Учитывать и открывающиеся рыночные возможности, и ресурсные ограничения. Развивать организацию в направлении большей безопасности и притягательности для человека. Не впадать в крайности.

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

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

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

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

в аппаратном обеспечении;

в коммуникационном оборудовании и ПО;

в системном ПО;

в прикладном ПО, находящемся в эксплуатации;

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

Далее по тексту изменения, связанные с объектами группы (1) — (3), мы будем называть инфраструктурными, а изменения, связанные с объектами группы (4) — (5), будем называть модернизацией прикладных систем.

Как выглядит идеальная схема организации управления изменениями в достаточно крупной компании? Все изменения на основании различных признаков разделяются на два потока. Первый из них, куда относятся стандартные, типовые, повторяемые изменения, управляется набором соот­ветствующих регламентов (правил, инструкций). Второй из них, куда относятся бизнес-критичные, сложные, затратные по ресурсам, срочные и т.п., управляется коллегиальным органом, именуемым 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 (ИТ-директора).

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

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

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

определить список сотрудников, которых надо будет оповестить, и выполнить необходимые оповещения;

сформировать группу сотрудников (включая внешних подрядчиков), которая будет выполнять само изменение;

сформировать дежурную аварийную группу, которая подключится к работам в случае необходимости произвести откат (если такая группа предусмотрена планом отката);

после завершения работ провести анализ результатов изменения.

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