Управление изменениями в бизнес плане

Привет, Хабр! Этот пост родился в ходе подготовки лекции по курсу Project Management от Acronis, который мы читали в МФТИ — “Создание продукта и управление его развитием”. Полностью весь курс можно посмотреть на нашем Youtube-канале, а сегодня мне хотелось бы поделиться подходами к контролю изменений и внедрению изменений в компаниях разного масштаба. Мы поговорим о психологических особенностях сопротивления изменениям и человеческой реакции на нововведения. Материал будет полезен руководителям, менеджерам проектов, а также тем, кто внедряет изменения, и тем кто испытывает изменения на себе и размышляет, что с этим делать.

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

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

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

Представьте, что NASA проектирует космический модуль. Но внезапно один из инженеров предлагает заменить одну деталь на другую, более безопасную. Какими бы благими не были намерения, этого нельзя сделать сразу, ведь на этапе строительства уже готова конструкторская документация, сверстан бюджет. Если начать глубокие изменения, возможно придется сдвигать дату отправки космонавтов, что может повлиять на многие смежные проекты. Но допустимо ли это? И как контролировать вносимые изменения?

Одним из подходов может быть предложенный специалистами PMI (Project Management Institute). Книги института содержат практики и знания, накопленные большим количеством профессионалов, и если вам нужно контролировать изменения, их можно использовать как прямое руководство.

PMBOK (так называется свод знаний PMI) предлагает готовый набор лучших практик по внесению и контролю изменений в организации. Одной из них является создание совета по изменениям (Change Control Board), который представляет собой группу лиц с достаточными для принятия решений полномочиями.

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

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

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

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

Практика показывает, что лучший подход в таком случае может быть охарактеризован фразой «it depends»: по каждому конкретному случаю давать руководству принимать решения, предварительно проведя оценку последствий изменения с привлечением экспертов. Ведь подавляющее большинство изменений возможно, просто каждое потребует определенных “жертв”: например, новые функции можно добавить, если что-то выкинуть из релиза, сдвинуть даты сдачи или нанять аутсорсеров (соглашаясь на рост затрат).

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

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

Внедрение изменений

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

Я уверен, что если раздать всем сотрудникам компании небольшую анкету с одним единственным вопросом “Хотели бы вы, чтобы ваша компания работала более эффективно”, то подавляющее большинство ответило бы “Да”. Но при этом изменения в работе компании всегда связаны с определенными трудностями: инстинктивно большинство сотрудников противятся изменениям, ведь изменения это когда «кто-то другой просит нас делать что-то новое».

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

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

Одну из моделей для понимания мотивов человека описал психолог Курт Левин, работавший в MIT в 40-х годах. Его модель «Поле силы изменений» предполагает, что на каждую личность (или организацию) действуют совокупность противоборствующих сил: побуждающие и ограничивающие. Именно от баланса этих сил и зависит текущее состояние.

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

Изменения — как смерть

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

1. Шок — Именно это испытывают люди, когда слышат фразу “У нас реструктуризация, и сейчас вас объединят с другим департаментом”. В зависимости от конкретного человека шок будет протекать по-разному, но практически все будут переживать из-за нарушения статуса-кво, испытывая разные негативные эмоции — от волнения до испуга
2. Отрицание — Люди задаются вопросом: “А зачем это? Они ничего не продумали! Это плохая идея!” Что характерно, в этом периоде люди мало и плохо работают, потому что их энергия направлена на то, чтобы избежать изменений, на поиск контр-аргументов
3. Разочарование — Люди тратят свое время на попытки убедить себя и окружающих в том, что нужно все вернуть как было, что стало хуже. И, что характерно, продолжают неэффективно работать
4. Депрессия — Этот период можно считать переломным, потому что человек понимает неизбежность изменений, но еще не понимает, как вести себя в новой ситуации
5. Эксперимент — Происходит попытка отказа от старых моделей поведения, но новых все еще нет. В этот момент важно ускорить процесс, стимулировать сотрудников искать подходы к решению новых задач, приспосабливаться к новым реалиям. На этом этапе также существует риск застрять в «Долине слез». Этот термин описывает ситуацию, когда после неудачных попыток примерить новые правила, мы скатываемся к предыдущему этапу к депрессии. И этот цикл повторяется, пока не будет найден новый подход и методы работы
6. Решение — Новые модели поведения найдены, происходит их наработка, формирование лучших практик. На этом этапе люди все меньше ошибаются, создаются новые паттерны, компания приближается к обновленному статусу Кво
7. Интеграция — Если мы говорим о внедрении изменений в компании, то после всего этого требуется встраивание изменений в корпоративную культуру

Все эти стадии условно можно разделить на три более крупные категории:

• Размораживание – Разочарование в текущих установках
• Движение – Поиск новых подходов
• Заморозка – Фиксация работающих практик

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

Управление изменениями — основные принципы

Сегодняшняя ситуация на мировом рынке заставляет многие компании меняться, чтобы сохранить имеющиеся и приобрести новые конкурентные преимущества. Что бы определить что такое управление изменениями обратимся к определению словаря Webster’s Ninth New Collegiate Dictionary, «изменить» значит «придать чему-либо другое положение, задать другое направление или курс, совершить сдвиг от одной позиции к другой, модифицировать, трансформировать, заменить, перевести в другое качество». Термин «управлять» означает «умело контролировать или направлять, осуществлять организаторские, административные и контролирующие функции». 

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

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

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

Управление изменениями в области ИТ

Для специалистов в области информационных технологий частые изменения в этой сфере — большая «головная боль», поскольку донастраивать системы под изменяющиеся бизнес-процессы приходится достаточно часто и в срочном порядке. Если запланированные изменения осуществляются медленно, то это мешает бизнесу и вызывает снижение его конкурентоспособности, что в конечном итоге приводит к недовольству бизнес-подразделений информационными технологиями. Одним из источников информации о том, каким образом нужно внедрять в IT-компании процесс управления изменениями, является TIL (Information Technology Infrastructure Library — «библиотека IT-инфраструктуры»), где все описание приведено на детальном уровне. Компании, поставившей перед собой цель внедрить этот процесс или усовершенствовать уже существующий, следует ознакомиться в ITIL с основными принципами процесса и выбрать из них те, которые подходят к ее собственным задачам. Для многих крупных компаний процесс управления изменениями, изложенный в ITIL, может показаться слишком простым, тогда как маленьким фирмам попросту не хватит ресурсов для внедрения точной копии системы управления изменениями, данной в ITIL. В таком случае следует внедрить основные принципы и выбрать один сценарий процесса, а затем постоянно работать над его улучшением.

Управления изменениями — схема процесса

Общая схема проведения изменений начинается с регистрации запроса на изменения — Request for Change (RFC), причем здесь запрос попадает в сферу управления процессом управления изменениями, то есть фактически становится его экземпляром. На данном этапе изменению присваивается идентификационный номер, и в дальнейшем осуществляется классификация запроса, то есть фактически определяется сценарий, по которому данный запрос будет обрабатываться. Многие компании считают необходимым следовать одному сценарию процесса для всех изменений.

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

Приоритеты изменений могут быть следующими:

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

Число и описание приоритетов в каждой компании могут быть различными, но на выбор приоритета всегда должны влиять категории изменений с точки зрения масштабности, которые могут быть, в частности, следующими:

• Крупные изменения (например, реструктуризация головного офиса или внедрение ERP системы).
• Средние изменения (например, внедрение процесса бюджетирования или системы управления документами).
• Мелкие изменения (внедрение процесса обучения).
• Незначительные изменения (актуализация регламентов на основании передачи прав и обязанностей, переезд подразделения).

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

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

• Финансовое одобрение: анализ затрат/выгод бюджета.
• Техническое одобрение: оценка необходимости, возможности проведения изменения и степени его воздействия.
• Бизнес-одобрение: одобрение пользователями требуемой функциональности приложения и степени воздействия изменения.

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

В небольших компаниях достаточно одного комитета, в более крупных возможно несколько. Наличие комитетов позволяет рассмотреть запросы и планы изменений представителям разных служб, что, таким образом, снижает вероятность риска неудачного или невостребованного изменения. Кроме того, комитеты обеспечивают взаимодействие между IT и бизнесом для определения их согласованной точки зрения на изменение. Для выполнения этих задач в комитет следует включать людей, знакомых с бизнес-процессами предприятия и его информационными системами. После утверждения запроса на изменение или графика будущих изменений (FSC — Forward Schedule of Change) — документа, описывающего порядок изменений и задействованные ресурсы, на специально формируемом комитете проектные группы могут начинать внедрять утвержденные изменения в деятельность компании.

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

При этом основными задачами владельца процесса управления изменениями являются:

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

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

Управление изменениями — документирование

Изначально управление изменениями должно работать по следующей схеме: «размораживание — изменение — замораживание», причем с четким документированием каждого изменения. Вот почему одним из основных вопросов при управлении изменениями является документирование существующей и целевой ситуации при изменении, а также формирование плана перехода между ними. Поскольку изменения внедряются в бизнеспроцессы, то важным моментом является описание бизнес-процессов с помощью специализированных средств, таких, например, как система ARIS. Подобные средства являются в своем роде базой данных о текущей ситуации в компании. Любое изменение в ее деятельности должно отражаться в этой базе для обеспечения возможности управления изменениями. Многие компании уже сейчас используют средство описания для формализации изменений в бизнес-процессах и обеспечивают автоматизированное получение сформированных моделей бизнес-процессов.

Управление изменениями  — Использование референтных моделей

Правильность построения процесса управления изменениями может быть обеспечена, как уже сказано, использованием библиотеки ITIL, но детальное описание процесса с указанием бизнес-ролей и информации по нему библиотека не содержит. В своей работе по разработке детальных моделей процесса мы используем референтную модель компании IDS Scheer — ARIS ITIL Reference Model, которая помимо моделей процесса содержит основные данные, использующиеся при управлении изменениями. Описание процесса в графической форме позволяет находить общий язык между IT-специалистами и бизнес-экспертами, а использование референтных моделей предполагает взятие за основу эталонного представления процесса и формирование варианта, наиболее подходящего для конкретной компании.

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

Управление изменениями — анализ эффективности

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

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

• число проведенных изменений за период в различной разбивке и в динамике;
• классификация причин изменений;
• число успешных изменений;
• число неудачных изменений с разбивкой по причинам;
• число запросов на изменения (RfC): отклоненных и тренд;
• число рассмотренных и внедренных изменений;
• длина очереди актуальных изменений и ее тренд.

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

• Привело ли изменение к достижению намеченной цели?
• Удовлетворены ли пользователи результатом?
• Возникали ли какие-либо побочные эффекты?
• Были ли превышены расчеты по затратам и ресурсам?

Такой анализ статистики процесса  — управление изменениями нацелен на выявление любых ошибок, которые по той или иной причине были пропущены и привели к неудаче введенных изменений. Однако при внедрении процесса управления изменениями могут возникать следующие проблемы: Неоправданная бюрократизация процесса, что может затягивать процедуру согласования изменений. Управление изменениями внедряется без создания базы о существующих бизнес-процессах. Не проработаны или невозможны процедуры возврата к предыдущему состоянию. Процесс легко обойти (некоторые сотрудники делают это из желания ускорить отдельные мероприятия). Процесс подвержен ошибкам, поэтому рекомендуется прибегать к возможным автоматизированным решениям. Использование процессного подхода, ITIL и, например, референтных моделей ARIS IDS Reference Model позволяет в большинстве случаев избежать вышеобозначенных проблем и разработать эффективный процесс управления изменениями.

Заключение

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