BPMN + ADKAR: как мы внедрили новый процесс без сопротивления

Руководитель или бизнес-аналитик в e-commerce сталкиваются с типичной, но острой проблемой - процессы описаны фрагментарно или не описаны совсем, выполняются по-разному, а любые изменения «проваливаются» через 2–3 недели. Основная проблема - отсутствие единого стандарта в компании. Масштабироваться в таких условиях опасно и ненадежно.

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

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

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

Целью было не просто нарисовать BPMN-схему, а запустить устойчивый, живой процесс, где:
- все работают по единому внутреннему стандарту (BPMN + регламент),
- роли и ответственность понятны,
- метрики показывают прогресс (например, % автоматически привязанных платежей),
- обучение проходит быстро, потому что материал адаптирован под реальные задачи сотрудников,
- результат сохраняется без постоянного контроля со стороны аналитика.

Стандартного подхода «описал - согласовал - утвердил - загрузил в базу знаний» нам было недостаточно. Решением стало пошаговое объединение BPMN и ADKAR как единой методологии внедрения. Такой подход позволил не просто описать, а обеспечить успешное внедрение бизнес-процессов компании - с минимальным сопротивлением и максимальной вовлеченностью.

Внедрение бизнес процессов: почему важно сочетать структуру и людей

BPMN задает структуру и логику процесса: какие границы процесса, кто что делает, когда, при каких условиях. Мы начинали с описания процесса «as is» - для этого провели серию интервью с целью выяснить, как процесс работает сейчас.

Однако даже идеально спроектированный процесс не даст результата, если люди не готовы в нем работать. Именно здесь на помощь приходит ADKAR - инструмент управления изменениями, ориентированный на человеческий фактор. В отличие от BPMN, который отвечает на вопрос «как должен работать процесс», ADKAR отвечает на вопрос «как сделать так, чтобы сотрудники захотели и смогли работать по-новому». Это модель, которая разбивает путь внедрения изменений на пять последовательных этапов:
• A - Awareness (осознание): сотрудник должен понять, почему происходят изменения;
• D - Desire (желание): у него должно появиться желание участвовать в процессе;
• K - Knowledge (знание): он должен знать, как действовать в новых условиях;
• A - Ability (способность): необходимо уметь применять знания на практике;
• R - Reinforcement (подкрепление): изменения должны быть закреплены и поддержаны.

Каждый шаг в модели логически вытекает из предыдущего, и именно в такой последовательности модель демонстрирует максимальную эффективность.

В нашем случае задача стояла не в создании процесса «Оплата счета клиентом» с нуля, а в устранении бесконтрольных зон. Ранее платежи нередко зачислялись просто по звонку менеджера, без подтверждения в системе. Требовалось исключить ручную привязку в 1С:УТ и одновременно обеспечить корректную интеграцию CRM на базе Битрикс24 с 1С. Ключевым условием стала автоматическая отправка события из 1С:УТ в CRM в момент изменения статуса заказа клиента.

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

Рассмотрим, как пройти пять этапов ADKAR параллельно с созданием схем процесса в нотации BPMN как цикл совместной работы.

1. Этап. Awareness (Осознание)

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

Что для этого нужно сделать?
Провести диагностику процесса вместе со всеми заинтересованными лицами. Эту задачу мы уже решили на этапе сбора информации, когда с помощью серии интервью описали процесс «as is».

В рамках процесса мы провели измерение следующих показателей:

• количество заказов, находящихся в статусе «Ожидает оплаты» более 24 часов;
• количество ручных корректировок по оплатам за месяц и за день;
• количество обращений к менеджерам офиса, связанных с ситуациями «оплатил, но не отгрузили» или «отправили письмо с просьбой об оплате, а счет уже оплачен».

Все результаты были зафиксированы в цифрах.

2. Этап. Desire (Желание)

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

Пример для рассматриваемого процесса разнесения оплат в 1С:УТ:

Бухгалтер сталкивался с тем, что:

• Загружал платежи из банка.
• Вручную искал заказ в 1С по ФИО клиента.
• Вручную привязывал оплату к заказу.

Из-за этого возникали ошибки. Например:

• Клиент платил от физического лица по счету, выставленному на ООО.
• Бухгалтер не мог сразу привязать платеж — каждый раз приходилось писать менеджеру.
• Бухгалтер ждал, пока менеджер исправит заказ в 1С.
• Только после этого платеж прикреплялся к заказу.

3. Этап. Knowledge (Знания)

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

Обучение разделили на этапы:

1. Создали быстрые подсказки в базе знаний.

Записали короткие видеоинструкции к каждому действию (task) на схеме BPMN.

Например, для задачи «Подтвердить оплату» записали ролик: как правильно проставить статус «Оплата подтверждена».

2. Провели короткие сессии у рабочего места (по 5–10 минут).

Формат сессий:

• Разбирали одну реальную задачу вместе с сотрудником.
• Сначала сотрудник делал операцию по-старому, затем по-новому.
• Разбирали отличия, отвечали на вопросы, фиксировали трудности.

3. Встроили знания прямо в интерфейс 1С:УТ.

Добавили подсказки-баннеры в ключевые формы.

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

4. Давали знания не как информацию, а как обновление рабочего инструмента.

Сотрудник не «учил теорию», а осваивал новый способ работы в процессе своих обычных задач.

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

Пример: как прошла сессия с бухгалтером.

До сессии:

• Бухгалтер получал платеж от физического лица по счету, который был выставлен на ООО.
• Не мог привязать оплату и писал менеджеру, ждал, пока тот исправит заказ в 1С.
• Процесс зависал на неопределённое время.

Ход сессии (5–10 минут у рабочего места):

1. Попросили бухгалтера обработать текущий платеж по-старому
   (чтобы зафиксировать привычные действия и точки боли).
2. Показали новый сценарий:
   • Объяснили, что теперь система автоматически создает клиента, если плательщик не совпадает с тем, на кого выставлен счет.
   • Показали в интерфейсе 1С:УТ, где появляется новый клиент и как его проверить.
   • Вместе привязали платеж к заказу уже без участия менеджера.

4. Этап. Ability (Способность)

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

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

Когда мы предложили это руководству, первая реакция была предсказуемой: «Вы хотите отвлечь лучших сотрудников от их прямых задач? Кто за них будет работать?». Мы не стали спорить, а просто перевели разговор в практическую плоскость. Руководству был задан простой вопрос: «Что для вас дороже - потеря 20 часов работы двух сотрудников на подсказках в первую неделю или потеря порядка 200 часов всей команды из-за ошибок, переделок и простоев в первый месяц?».

После этого объяснили три вещи:

1. Разрыв от знаю до делаю. Даже после хорошего обучения люди в стрессе (а запуск нового процесса - это стресс) забывают до 50% нового материала. Наставник снижает этот разрыв до 10–15%.
2. Скорость входа. Без наставника сотрудник сам методом проб и ошибок выходит на целевой ритм за 2–3 недели. С наставником - за 2–3 дня.
3. Правильные привычки с первого раза. Если сотрудник ошибется в первые дни и это сработает (пусть и не по правилам), он запомнит ошибку как норму. Наставник отследит это сразу.

Что касается самих наставников, то их мотивация строилась не на энтузиазме, а на понятных условиях:

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

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

Кроме того, мы ввели «период безопасных ошибок». Первые три дня новые действия в 1С:УТ проходили в режиме двойной фиксации: сотрудник выполнял операцию, а наставник проверял ее в реальном времени, не включая формальную систему контроля. Это снижало страх ошибки и позволяло отработать руку без риска для бизнеса. Важно, что поддержка была временной и постепенно сворачивалась: через 5 дней — только по запросу, через 10 - только раз в день сверка по контрольным точкам.

Результатом стало не просто выполнение задачи, а появление устойчивого навыка: сотрудники начинали чувствовать логику процесса, замечать отклонения сами и даже предлагать улучшения.

5. Reinforcement (Закрепление)

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

Чтобы этого не произошло, мы не просто «отчитались об окончании проекта», а запустили систему закрепления, интегрированную в повседневную работу. Мы встроили элемент рефлексии в регулярные планерки отдела. Раз в неделю команда отвечала на два вопроса: «Что уже хорошо? Где ещё спотыкаемся?». Это давало обратную связь в реальном времени и показывало, что изменения - не «проект сверху», а живой инструмент команды.

Во-вторых, мы сняли неопределенность, сделав процесс оплаты прозрачным. Платежи из Клиент-Банка автоматически попадают в 1С:УТ (ручной ввод исключен). Бухгалтер видит только те платежи, которые требуют его действий - привязку к заказу, учет частичной оплаты или возврата.

Мы внедрили два простых, но действенных элемента:
- в 1С:УТ в форме списка необработанных платежных поручений появилась колонка «Ожидает обработки». Она оставалась пустой, пока бухгалтер не проставит статус «Оплата подтверждена». После этого автоматически проставлялся определенный маркер и отображалась дата и время отправки в Битрикс24. Это позволяло бухгалтеру видеть: «Я не просто закрыл задачу - я запустил следующий этап».
- в Битрикс24 в воронке сделок у заказов менялась стадия на «Оплата подтверждена. Готов к отгрузке», когда бухгалтер привязывал оплаты в 1С:УТ, и ответственный менеджер получал уведомление в мессенджере Битрикс24.

В-третьих, мы связали успех процесса с ощутимыми результатами и озвучили их. Через две недели после запуска собрали команду и показали:
- количество звонков клиентов с вопросом «Я оплатил, а заказ не отгрузили» сократилось на 62%;
- среднее время обработки платежа у бухгалтера упало с 8 до 2,5 минут;
- количество ручных корректировок в отчетности за месяц сократилось с 34 до 4.

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

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

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

Масштабирование: от одного процесса к системе управления

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

Следующим шагом стало внедрение оптимизации бизнес процессов в смежных зонах: возвраты, частичные отгрузки, работа с предоплатами. Для каждого мы использовали тот же цикл: BPMN + ADKAR. Разница была лишь в глубине детализации и составе команды процесса.

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

Более того, этот же подход у нас сработал и в других процессах - в логистике, закупках, продажах. Мы везде повторяли один и тот же порядок: сначала собирали боли команды, потом описывали процесс.

Рисунок 2. Процесс «Оплата счета клиентом» - целевое состояние (to be).
Обновлённая модель автоматизирует работу с заказами, четко распределяет роли и синхронизирует CRM с 1С. Все действия фиксируются, статусы обновляются сами, а коммуникация становится прозрачной.

Заключение

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

Наш опыт показывает: сочетание BPMN (как языка структуры) и ADKAR (как карты человеческого пути) позволяет не просто описать процесс, а запустить живую, самоподдерживающуюся практику. Это особенно важно при внедрении бизнес процессов компании, где каждая ручная операция несет риск ошибки, а каждая ошибка - прямой убыток.

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