Как обеспечить эффективное управление изменениями?

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

Сегодняшняя ситуация на мировом рынке заставляет многие компании меняться, чтобы сохранить имеющиеся и приобрести новые конкурентные преимущества. Что бы определить что такое управление изменениями обратимся к определению словаря 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-подразделении может стать пилотным проектом по внедрению аналогичного процесса в масштабе всей компании.