Всем привет! В предыдущих двух статьях нашего цикла – шесть основ бизнес-анализа мы с вами разобрали первые два базовых понятия Бизнес-анализа – Заинтересованные стороны (Stakeholders) и Потребность (Need).  Мы выяснили, что аналитик начинает любой проект с определения «кто в игре» для создания рабочей группы проекта и первым делом «ставит диагноз», т.е. определяет истинную потребность заказчика. Но когда потребность сформулирована и решение найдено начинается самая недооценённая часть работы бизнес-аналитика. Потому что даже идеально спроектированное решение может провалиться, если не управлять тем, что происходит между «сейчас» и «потом» — то есть самим изменением.

По данным McKinsey & Company, около 70% инициатив по организационным изменениям не достигают поставленных целей. Причина почти всегда одна и та же: техническая часть выполнена, а человеческая — проигнорирована. Новая система работает, процесс описан, инструкции написаны. Но люди продолжают работать по-старому.

Чтобы не наступить на эти грабли, разберём третье базовое понятие BABOK — Изменение (Change).

Почему третье базовое понятие именно «Изменение»?

Каждый проект — это изменение. Не важно, оптимизируете вы бизнес-процесс, меняете регуляторную модель или внедряете новое ПО. В любом случае вы переводите организацию из состояния «как есть» (As-Is) в состояние «как будет» (To-Be). И этот переход — не технический факт, а организационное событие.

Третье базовое понятие именно «Изменение», потому что:

1.    Заинтересованные стороны — это те, кто затронут изменением.

2.    Потребность — это то, ради чего затевается изменение.

3.    Изменение — это то, как мы от нынешнего состояния доберёмся до желаемого.

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

Что такое Изменение и где кроется подвох?

Согласно глоссарию BABOK v3.0:

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

Звучит академично, но за этим определением скрывается принципиальная мысль: изменение — это не событие, а процесс. Оно не происходит в момент нажатия кнопки «В релиз». Оно начинается задолго до него и заканчивается значительно позже.

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

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

Три измерения изменения: процессы, системы, люди

BABOK рассматривает изменение в трёх взаимосвязанных плоскостях. Ошибка большинства проектов — фокус только на одной из них.

1. Процессы: что меняется в том, как мы работаем?

Это самое очевидное измерение. Большинство проектов начинаются именно здесь: перепроектируется бизнес-процесс, убираются лишние шаги, добавляются новые контрольные точки.

Типичные ловушки на уровне процессов:

1.    «Нарисовали To-Be, забыли про As-Is»

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

2.    «Процесс на бумаге ≠ процесс в жизни»

Схема BPMN в Confluence и то, как люди работают на самом деле, — нередко два разных документа. Перед проектированием To-Be всегда верифицируйте реальный As-Is, а не официальный.

3.    «Забыли про исключения»

Любой процесс имеет нестандартные сценарии — исключения, которые составляют 20% случаев, но 80% головной боли при внедрении. Выявляйте их на этапе анализа, а не после релиза.

2. Системы: что меняется в технологиях и данных?

Это измерение привычно для ИТ-проектов, но и здесь скрываются нетривиальные риски.

Типичные ловушки на уровне систем:

1. «Данные мигрируем потом» Один из самых дорогостоящих мифов. Миграция данных — это не техническая задача «в конце», это часть изменения с собственными требованиями, рисками и временем. В BABOK она относится к Transition Requirement — переходным требованиям.

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

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

3. Люди: что меняется в поведении и мышлении?

Самое сложное и самое часто игнорируемое измерение. Системы не сопротивляются изменениям. Люди — сопротивляются.

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

Практический вывод: если вы не знаете, на какой стадии находятся ключевые заинтересованные стороны, вы управляете изменением вслепую.

Классическая ошибка: «система готова, люди нет»

Приведу кейс из практики, который хорошо иллюстрирует все три измерения изменения одновременно.

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

Что произошло дальше:

• HR продолжали вести заявки в Excel — «так привычнее и надёжнее».

• Руководители сотрудников не могли смотреть дашборды новой системы, потому что данные в неё не вносились.

• Через три месяца параллельно работали две системы — новая (официальная) и Excel (фактическая).

• Стоимость поддержки выросла, потому что нужно было обслуживать оба контура.

Почему так случилось?

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

2.    На уровне систем: миграция исторических данных была сделана частично. Пользователи не доверяли системе, потому что «там нет старых заявок».

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

Итог: Проект формально считался успешным — система запущена в срок и в бюджет. По факту — изменение не состоялось. Деньги потрачены, поведение не изменилось.

Почему сопротивление изменениям — это не проблема, а симптом?

Самая распространённая реакция на сопротивление сотрудников: «они просто не хотят меняться», «люди консервативны», «надо просто объяснить им важность». Это ошибочная рамка.

Сопротивление — это сигнал. Оно говорит о том, что:

• Люди не понимают причину изменения («нам не объяснили зачем»)

• Люди не доверяют процессу («нас не спросили»)

• Люди боятся потерять что-то важное — статус, компетентность, привычный ритм работы

• Изменение реально неудобно

Практическое правило: если больше 30% ключевых заинтересованных сторон активно сопротивляются, проект находится в зоне риска, даже если техническая часть идеальна.

Рабочие техники: как спроектировать изменение?

В BABOK v3.0 управление изменениями затрагивается в нескольких разделах: Strategy Analysis (глава 6), Solution Evaluation (глава 8) и в техниках Elicitation & Collaboration (глава 4). Ниже — четыре наиболее практичных инструмента:

1. Анализ воздействия изменений (Impact Analysis)

Прежде чем проектировать To-Be, ответьте на вопрос: что именно изменится и для кого?

Структура Impact Analysis:

1.    Объект изменения: какой процесс / система / роль / подразделение будет затронута?

2.    Масштаб изменения: насколько радикально меняется привычная работа (по шкале от «косметика» до «полный слом»)?

3.    Скорость изменения: сколько времени есть на адаптацию?

4.    Готовность к изменению: насколько люди информированы и мотивированы?

Этот анализ — основа для плана коммуникаций и плана обучения. Без него они пишутся «для галочки».

2. Модель ADKAR

ADKAR — один из наиболее распространённых фреймворков управления изменениями. Он хорошо стыкуется с подходом BABOK, поскольку описывает изменение через готовность конкретного человека, а не организации в целом:

 Практическое применение: пройдитесь по ADKAR c каждой ключевой группой заинтересованных сторон перед релизом. Где найдёте «дыры» — там и будут провалы после запуска.

3. Карта изменений (Change Impact Map)

Простой, но мощный инструмент — матрица, которая соединяет группы заинтересованных сторон с конкретными изменениями, которые их затронут:

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

4. Transition Plan (план перехода)

Transition Plan — это не план проекта. Это ответ на вопрос: как именно мы перейдём от As-Is к To-Be, чтобы не потерять непрерывность бизнеса?

Обязательные компоненты:

1.    Описание «точки невозврата» — когда именно старый процесс/система официально прекращают работу

2.    Период параллельной работы — сколько времени работают оба контура и как сверяются результаты

3.    План миграции данных — что мигрируем, кто проверяет, как верифицируем

4.    План обучения — кто, когда, в каком формате (не «провели вебинар», а проверяемый результат)

5.    Критерии готовности к переходу — что должно быть выполнено, чтобы сказать «мы готовы»

6.    Plan B — что делаем, если через 2 недели после релиза ситуация неприемлема

Опыт «БКС Мир инвестиций»: Change Readiness — до нажатия кнопки «В релиз»

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

Суть проста: за 2–3 недели до запуска бизнес-аналитик совместно с менеджером проекта проходит по чеклисту, который покрывает все три измерения изменения. Если по итогам оценки обнаруживаются красные зоны — релиз переносится или делается поэтапным. Это решение требует мужества, но в долгосрочной перспективе оно всегда дешевле, чем экстренное «тушение пожаров» после провального запуска.

Ключевые блоки оценки:

1.    Процессы: верифицирован ли To-Be с реальными пользователями? Все ли исключения закрыты?

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

3.    Люди: проведено ли обучение с проверкой результата, а не просто «ознакомлены»? Есть ли сотрудники-промоутеры изменения в каждом подразделении?

4.    Коммуникации: знают ли все заинтересованные стороны, что происходит, когда и почему?

5.    Откат: есть ли проверенный план отката, и команда знает, как им воспользоваться?

Мини-чеклист: «Готов ли я управлять изменением?»

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

2.    Я провёл Impact Analysis и знаю, где самые высокие риски сопротивления?

3.    Новый процесс (To-Be) верифицирован с реальными операционными пользователями, а не только с заказчиком?

4.    Существует Transition Plan с описанием периода параллельной работы, плана миграции данных и критериев готовности?

5.    Обучение запланировано с проверкой результата (не «провели», а «умеют»)?

6.    Есть ли в каждом затронутом подразделении «агент изменений» — человек, который поддерживает проект изнутри?

7.    Есть ли план коммуникаций: кто, когда, что и в каком формате узнаёт об изменении?

Итог

Изменение — третье звено в причинно-следственной цепочке BABOK: Нет правильных заинтересованных сторон → нет правильной потребности → изменение не спроектировано → решение не приживается → нет ценности.

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

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

Что дальше в цикле?

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