Всем привет! В предыдущих двух статьях нашего цикла — шесть основ бизнес‑анализа мы с вами разобрали первые два базовых понятия Бизнес‑анализа — Заинтересованные стороны (Stakeholders) и Потребность (Need). Мы выяснили, что аналитик начинает любой проект с определения «кто в игре» для создания рабочей группы проекта и первым делом «ставит диагноз», то есть определяет истинную потребность заказчика. Но когда потребность сформулирована и решение найдено начинается самая недооценённая часть работы бизнес‑аналитика. Потому что даже идеально спроектированное решение может провалиться, если не управлять тем, что происходит между «сейчас» и «потом» — то есть самим изменением.
По данным McKinsey & Company, около 70% инициатив по организационным изменениям не достигают поставленных целей. Причина почти всегда одна и та же: техническая часть выполнена, а человеческая — проигнорирована. Новая система работает, процесс описан, инструкции написаны. Но люди продолжают работать по‑старому.
Чтобы не наступить на эти грабли, разберём третье базовое понятие BABOK — Изменение (Change).
Почему третье базовое понятие именно «Изменение»?
Каждый проект — это изменение. Не важно, оптимизируете вы бизнес‑процесс, меняете регуляторную модель или внедряете новое ПО. В любом случае вы переводите организацию из состояния «как есть» (As‑Is) в состояние «как будет» (To‑Be). И этот переход — не технический факт, а организационное событие.
Третье базовое понятие именно «Изменение», потому что:
Заинтересованные стороны — это те, кто затронут изменением.
Потребность — это то, ради чего затевается изменение.
Изменение — это то, как мы от нынешнего состояния доберёмся до желаемого.
Без понимания масштаба и природы изменения любое требование — это просто текст в документе, не привязанный к реальности организации.
Что такое Изменение и где кроется подвох?
Согласно глоссарию BABOK v3.0:
«Изменение — это акт трансформации в ответ на потребность. Изменения происходят тогда, когда текущее состояние недостаточно для достижения желаемого результата».
Звучит академично, но за этим определением скрывается принципиальная мысль: изменение — это не событие, а процесс. Оно не происходит в момент нажатия кнопки «В релиз». Оно начинается задолго до него и заканчивается значительно позже.
Ключевой подвох, который стоит проектам миллионы: бизнес‑аналитики и менеджеры проектов часто путают внедрение решения и управление изменением. Это разные вещи:
Внедрение решения | Управление изменением |
Установили систему | Люди начали ею пользоваться |
Написали инструкцию | Сотрудники понимают, зачем и как |
Провели демо‑сессию | Снято сопротивление, есть поддержка |
Процесс задокументирован | Процесс реально изменился в работе |
Ключевая мысль: Изменение происходит не в системах и документах. Изменение происходит в головах, привычках и ежедневных действиях людей.
Три измерения изменения: процессы, системы, люди
BABOK рассматривает изменение в трёх взаимосвязанных плоскостях. Ошибка большинства проектов — фокус только на одной из них.
1. Процессы: что меняется в том, как мы работаем?
Это самое очевидное измерение. Большинство проектов начинаются именно здесь: перепроектируется бизнес‑процесс, убираются лишние шаги, добавляются новые контрольные точки.
Типичные ловушки на уровне процессов:
«Нарисовали To‑Be, забыли про As‑Is»
Новый процесс проектируется в вакууме, без понимания, почему старый работал именно так. В результате «оптимизация» ломает обходные пути, которые сотрудники годами выстраивали для реальных рабочих ситуаций.
«Процесс на бумаге ≠ процесс в жизни»
Схема BPMN в Confluence и то, как люди работают на самом деле, — нередко два разных документа. Перед проектированием To‑Be всегда верифицируйте реальный As‑Is, а не официальный.
«Забыли про исключения»
Любой процесс имеет нестандартные сценарии — исключения, которые составляют 20% случаев, но 80% головной боли при внедрении. Выявляйте их на этапе анализа, а не после релиза.
2. Системы: что меняется в технологиях и данных?
Это измерение привычно для ИТ‑проектов, но и здесь скрываются нетривиальные риски.
Типичные ловушки на уровне систем:
«Данные мигрируем потом» Один из самых дорогостоящих мифов. Миграция данных — это не техническая задача «в конце», это часть изменения с собственными требованиями, рисками и временем. В BABOK она относится к Transition Requirement — переходным требованиям.
«Интеграции проверим на проде» Взаимодействие новой системы со смежными сервисами — это точка максимального риска. Особенно в финансовых и регуляторных системах, где цена ошибки измеряется не часами даунтайма, а штрафами и репутационным ущербом.
«Старую систему выключим сразу» Параллельная работа двух систем в переходный период почти всегда необходима. Она даёт возможность сравнить результаты, обнаружить расхождения и откатиться без катастрофических последствий, если что‑то пошло не так.
3. Люди: что меняется в поведении и мышлении?
Самое сложное и самое часто игнорируемое измерение. Системы не сопротивляются изменениям. Люди — сопротивляются.
Психолог Элизабет Кюблер‑Росс описала всем известную «Кривую изменений» — модель, изначально разработанную для понимания горя, но идеально применимую к организационным изменениям. Люди проходят предсказуемые стадии:
Стадия | Что происходит с человеком | Что делает аналитик |
Отрицание | «Зачем менять то, что работает?» | Объясняет причину изменения и последствия бездействия |
Гнев | «Нас не спросили, нам это навязали!» | Создаёт площадки для обратной связи, вовлекает на ранних этапах |
Торг | «А можно оставить хотя бы вот это по‑старому?» | Отделяет критичные требования от желаний, гибко ведёт переговоры |
Депрессия | «Я всё равно не разберусь в этой системе» | Обеспечивает обучение, поддержку, quick wins |
Принятие | «Ну, в общем‑то не так страшно» | Закрепляет новое поведение, собирает обратную связь |
Практический вывод: если вы не знаете, на какой стадии находятся ключевые заинтересованные стороны, вы управляете изменением вслепую.
Классическая ошибка: «система готова, люди нет»
Приведу кейс из практики, который хорошо иллюстрирует все три измерения изменения одновременно.
Контекст: В одной гос. компании внедрялась новая система управления заявками сотрудников на отпуск. Проект шёл по плану: требования собраны, разработка завершена, тестирование пройдено, инструкция для пользователей написана на 47 страниц. Дата релиза наступила точно по графику.
Что произошло дальше:
HR продолжали вести заявки в Excel — «так привычнее и надёжнее».
Руководители сотрудников не могли смотреть дашборды новой системы, потому что данные в неё не вносились.
Через три месяца параллельно работали две системы — новая (официальная) и Excel (фактическая).
Стоимость поддержки выросла, потому что нужно было обслуживать оба контура.
Почему так случилось?
На уровне процессов: новый процесс не был верифицирован с реальными пользователями. В системе не было реализовано несколько ключевых исключений, с которыми пользователи сталкивались ежедневно.
На уровне систем: миграция исторических данных была сделана частично. Пользователи не доверяли системе, потому что «там нет старых заявок».
На уровне людей: ни одна встреча с реальными пользователями не была проведена до релиза. Их впервые познакомили с системой на финальной демонстрации, за 2 дня до запуска.
Итог: Проект формально считался успешным — система запущена в срок и в бюджет. По факту — изменение не состоялось. Деньги потрачены, поведение не изменилось.
Почему сопротивление изменениям — это не проблема, а симптом?
Самая распространённая реакция на сопротивление сотрудников: «они просто не хотят меняться», «люди консервативны», «надо просто объяснить им важность». Это ошибочная рамка.
Сопротивление — это сигнал. Оно говорит о том, что:
Люди не понимают причину изменения («нам не объяснили зачем»)
Люди не доверяют процессу («нас не спросили»)
Люди боятся потерять что‑то важное — статус, компетентность, привычный ритм работы
Изменение реально неудобно
Практическое правило: если больше 30% ключевых заинтересованных сторон активно сопротивляются, проект находится в зоне риска, даже если техническая часть идеальна.
Рабочие техники: как спроектировать изменение?
В BABOK v3.0 управление изменениями затрагивается в нескольких разделах: Strategy Analysis (глава 6), Solution Evaluation (глава 8) и в техниках Elicitation & Collaboration (глава 4). Ниже — четыре наиболее практичных инструмента:
1. Анализ воздействия изменений (Impact Analysis)
Прежде чем проектировать To‑Be, ответьте на вопрос: что именно изменится и для кого?
Структура Impact Analysis:
Объект изменения: какой процесс / система / роль / подразделение будет затронута?
Масштаб изменения: насколько радикально меняется привычная работа (по шкале от «косметика» до «полный слом»)?
Скорость изменения: сколько времени есть на адаптацию?
Готовность к изменению: насколько люди информированы и мотивированы?
Этот анализ — основа для плана коммуникаций и плана обучения. Без него они пишутся «для галочки».
2. Модель ADKAR
ADKAR — один из наиболее распространённых фреймворков управления изменениями. Он хорошо стыкуется с подходом BABOK, поскольку описывает изменение через готовность конкретного человека, а не организации в целом:
Элемент | Что означает | Вопрос для проверки |
A — Awareness | Осознание необходимости изменения | «Знаете ли вы, почему мы это меняем?» |
D — Desire | Желание поддержать изменение | «Хотите ли вы, чтобы это изменение состоялось?» |
K — Knowledge | Знание, как работать по‑новому | «Знаете ли вы, как действовать в новой системе/процессе?» |
A — Ability | Способность выполнять новые действия | «Можете ли вы делать это на практике?» |
R — Reinforcement | Закрепление нового поведения | «Есть ли стимулы работать по‑новому постоянно?» |
Практическое применение: пройдитесь по ADKAR c каждой ключевой группой заинтересованных сторон перед релизом. Где найдёте «дыры» — там и будут провалы после запуска.
3. Карта изменений (Change Impact Map)
Простой, но мощный инструмент — матрица, которая соединяет группы заинтересованных сторон с конкретными изменениями, которые их затронут:
Группа Заинтересованных сторон | Что меняется в их работе | Уровень влияния | Готовность |
Операционные сотрудники | Новый интерфейс, другой порядок действий | Высокий | Низкая |
Руководители отделов | Новые дашборды вместо Excel‑отчётов | Средний | Средняя |
ИТ поддержка | Новая система на поддержку, новые SLA | Средний | Высокая |
Клиенты | Изменение UX, новые шаги в процессе | Высокий | Неизвестна |
Такая карта позволяет приоритизировать усилия по управлению изменением: не распылять коммуникации на всех, а сфокусироваться на группах с высоким влиянием и низкой готовностью.
4. Transition Plan (план перехода)
Transition Plan — это не план проекта. Это ответ на вопрос: как именно мы перейдём от As‑Is к To‑Be, чтобы не потерять непрерывность бизнеса?
Обязательные компоненты:
Описание «точки невозврата» — когда именно старый процесс/система официально прекращают работу
Период параллельной работы — сколько времени работают оба контура и как сверяются результаты
План миграции данных — что мигрируем, кто проверяет, как верифицируем
План обучения — кто, когда, в каком формате (не «провели вебинар», а проверяемый результат)
Критерии готовности к переходу — что должно быть выполнено, чтобы сказать «мы готовы»
Plan B — что делаем, если через 2 недели после релиза ситуация неприемлема
Опыт «БКС Мир инвестиций»: Change Readiness — до нажатия кнопки «В релиз»
На одном из крупных ИТ проектов, мы с командой выработали практику, которую назвали Change Readiness Assessment — оценка готовности к изменению. Это обязательная процедура перед каждым значимым релизом.
Суть проста: за 2–3 недели до запуска бизнес‑аналитик совместно с менеджером проекта проходит по чеклисту, который покрывает все три измерения изменения. Если по итогам оценки обнаруживаются красные зоны — релиз переносится или делается поэтапным. Это решение требует мужества, но в долгосрочной перспективе оно всегда дешевле, чем экстренное «тушение пожаров» после провального запуска.
Ключевые блоки оценки:
Процессы: верифицирован ли To‑Be с реальными пользователями? Все ли исключения закрыты?
Системы: завершена ли миграция данных? Проверены ли интеграции в среде, максимально приближенной к боевой?
Люди: проведено ли обучение с проверкой результата, а не просто «ознакомлены»? Есть ли сотрудники‑промоутеры изменения в каждом подразделении?
Коммуникации: знают ли все заинтересованные стороны, что происходит, когда и почему?
Откат: есть ли проверенный план отката, и команда знает, как им воспользоваться?
Мини‑чеклист: «Готов ли я управлять изменением?»
Я понимаю, что именно изменится в работе каждой ключевой группы заинтересованных стороны?
Я провёл Impact Analysis и знаю, где самые высокие риски сопротивления?
Новый процесс (To‑Be) верифицирован с реальными операционными пользователями, а не только с заказчиком?
Существует Transition Plan с описанием периода параллельной работы, плана миграции данных и критериев готовности?
Обучение запланировано с проверкой результата (не «провели», а «умеют»)?
Есть ли в каждом затронутом подразделении «агент изменений» — человек, который поддерживает проект изнутри?
Есть ли план коммуникаций: кто, когда, что и в каком формате узнаёт об изменении?
Итог
Изменение — третье звено в причинно‑следственной цепочке BABOK: Нет правильных заинтересованных сторон → нет правильной потребности → изменение не спроектировано → решение не приживается → нет ценности.
Бизнес‑аналитик, который понимает изменение только как «сдать требования в разработку», — это аналитик, который отвечает за половину работы. Настоящая ценность бизнес‑анализа создаётся не тогда, когда система запускается, а тогда, когда люди начинают работать по‑новому.
И здесь нет волшебной таблетки. Есть только системная работа: понять масштаб изменения, вовлечь людей до того, как они стали противниками, спроектировать переход — не только технический, но и человеческий. Именно это отличает аналитика, который «сдал документ», от аналитика, который «изменил организацию».
Что дальше в цикле?
Следующая статья будет про Решение (Solution): как выбрать правильный вариант реализации среди множества альтернатив? Какие критерии использовать? И почему «лучшее техническое решение» почти никогда не является «лучшим бизнес‑решением». Подпишитесь на наш блог, чтобы не пропустить.
