Как описать бизнес-процесс перед автоматизацией: BPMN без лишней бюрократии
Автоматизация плохо исправляет процесс, который участники понимают по-разному. Если менеджер считает заказ переданным после сообщения в чате, исполнитель — после появления задачи, а бухгалтер — после получения документа, система лишь закрепит противоречие. До разработки нужно увидеть фактическое движение работы: кто действует, какое событие запускает шаг, где принимается решение и что происходит при отклонении.
BPMN помогает собрать это описание в одну схему. Но польза появляется не от количества символов и не от формального соответствия каждому элементу стандарта. Для рабочего анализа обычно достаточно небольшого набора обозначений и дисциплины: отделять события от действий, показывать ответственность, не прятать развилки и проверять схему на реальных ситуациях.
Что BPMN даёт бизнесу до разработки
Business Process Model and Notation — стандарт графического описания процессов, который поддерживает события, действия, развилки, участников и обмен сообщениями. Его сильная сторона в том, что схема одновременно остаётся понятной бизнесу и достаточно точной для обсуждения будущей автоматизации.
Диаграмма отвечает на вопросы, которые трудно удержать в обычном тексте:
— с чего начинается конкретный экземпляр процесса;
— кто выполняет каждое действие;
— какое условие выбирает дальнейший маршрут;
— какие шаги выполняются параллельно;
— где процесс ждёт человека, документ, оплату или срок;
— как обрабатываются отказ, ошибка и возврат;
— каким событием процесс действительно завершается.
Схема не заменяет регламент, модель данных и техническое задание. Она связывает их. По ней можно определить нужные статусы, задачи, уведомления, права и интеграционные события, а затем перейти к автоматизации бизнес-процесса (https://synchroweb.ru/avtomatizaciya-biznesa/) без угадывания скрытых шагов.
Сначала ограничьте процесс одним результатом
Попытка нарисовать «работу всей компании» приводит к схеме, которую невозможно ни проверить, ни автоматизировать. Лучше выбрать процесс с конкретными началом и результатом: обработка нового обращения, согласование предложения, выполнение заказа, закупка позиции или закрытие обращения клиента.
Граница формулируется через два события. Начальное событие должно быть наблюдаемым: поступила заявка, получен комплект документов, подтверждена потребность. Конечное событие тоже описывает факт: обращение квалифицировано или закрыто, договор согласован, заказ передан на исполнение. Формулировка «работа выполнена» слишком широка, если участники по-разному понимают выполнение.
Перед моделированием полезно записать цель анализа. Например: найти места ручного переноса данных, определить правила назначения ответственного или подготовить требования к CRM. Цель помогает не перегружать диаграмму подробностями, которые не влияют на решение.
Соберите факты, а не только инструкции
Регламент показывает, как процесс должен идти. Для модели as-is нужно выяснить, как он идёт на самом деле. Источниками служат реальные документы, журналы CRM, переписка по рабочим вопросам, шаблоны файлов и интервью с людьми, выполняющими шаги. Важно не оценивать обходные действия до их фиксации: таблица или чат могут компенсировать отсутствующее состояние системы.
Для одного завершённого и одного проблемного экземпляра процесса полезно восстановить хронологию:
1. какое событие произошло;
2. кто об этом узнал и из какого канала;
3. какое действие выполнил;
4. какие данные использовал или создал;
5. кому передал результат;
6. сколько ожидал следующего решения;
7. что делал, если стандартный маршрут не сработал.
Так становятся заметны действия, отсутствующие в официальном описании: повторный ввод, сверка двух источников, ручное напоминание, поиск актуальной версии и возврат на уточнение. Именно они часто определяют требования к будущей системе.
Как собрать первую диаграмму as-is
Начинайте с чернового маршрута без стремления сразу использовать всю нотацию. Расположите начальное событие слева, конечное справа, между ними — действия в фактической последовательности. Каждое действие называйте глаголом и объектом: «проверить реквизиты», «согласовать скидку», «создать заказ». Названия вроде «CRM» или «отдел продаж» не объясняют, что происходит.
После основного маршрута добавьте участников, развилки и ожидания. Затем проверьте каждый переход вопросом: почему следующий шаг может начаться? Если ответом является сообщение, срок, документ или изменение состояния внешней системы, на схеме нужно событие либо явно указанное условие.
Не улучшайте процесс во время первой фиксации. Если сотрудник переносит значение вручную, покажите это. Если согласование фактически происходит в переписке, не заменяйте его будущей кнопкой. As-is нужен как точка сравнения, иначе нельзя понять, какое затруднение действительно устраняет целевая модель.
Пулы и дорожки показывают ответственность
В BPMN отдельный участник взаимодействия обычно показывается пулом, а роли внутри одного процесса — дорожками. Для прикладной схемы это помогает отделить действия компании от клиента, банка, подрядчика или другой организации. Внутри компании дорожки могут соответствовать ролям или подразделениям: менеджер, руководитель, бухгалтер, система.
Не стоит создавать дорожку для каждого сотрудника по имени. Модель должна сохранять смысл при кадровых изменениях. Также полезно отделять роль от программы: «менеджер» принимает решение, а CRM автоматически создаёт задачу. Если всё поместить в дорожку CRM, потеряется владелец бизнес-решения.
Последовательность действий внутри одного процесса соединяют потоком управления. Обмен между независимыми пулами показывают сообщениями. Это различие заставляет уточнить важный вопрос: контролирует ли компания следующий шаг или только отправляет запрос и ждёт внешнего ответа.
Событие, задача и состояние — не одно и то же
Событие сообщает, что что-то произошло: поступила заявка, истёк срок, получена оплата. Задача описывает работу: проверить заявку, подготовить документ, связаться с клиентом. Состояние характеризует объект в определённый момент: предложение согласовано, заказ отменён, счёт оплачен.
Если на диаграмме все прямоугольники названы статусами, непонятно, кто и что должен сделать. Если всё состоит из действий, но нет событий ожидания, система не знает, когда продолжать маршрут. Поэтому полезно проверять формулировки:
— задача имеет исполнителя и результат;
— событие имеет источник или условие наступления;
— статус изменяется только после подтверждаемого факта;
— автоматическое действие явно отличается от ручного.
Эта точность позже помогает спроектировать CRM: задачи становятся назначаемой работой, события — триггерами, а состояния — контролируемыми переходами сущности.
Развилка должна содержать правило выбора
Ромб без условия лишь сообщает, что процесс может пойти по-разному. Для автоматизации этого недостаточно. У каждой исходящей ветви нужно назвать проверяемое правило: данные полные или требуют уточнения, скидка в пределах полномочий или нужна эскалация, товар доступен или требуется закупка.
Эксклюзивная развилка выбирает один маршрут. Параллельная запускает несколько ветвей, которые могут выполняться одновременно. Смешивать их опасно: если после параллельного запуска процесс ждёт только одну ветвь, документ может перейти дальше до завершения обязательной проверки.
Условия не должны зависеть от догадки системы. «Важный клиент» нужно раскрыть через признак или решение конкретной роли. «Большая сумма» требует порога, источника валюты и правила для пограничного значения. Если правило пока нельзя формализовать, оставляют пользовательское решение, но фиксируют, кто его принимает и какие данные видит.
Исключения моделируют после основного маршрута
Сначала полезно согласовать нормальный путь, затем последовательно добавить типовые отклонения. Если рисовать все варианты одновременно, схема быстро превращается в сеть линий. Исключение включают в модель, когда оно повторяется, влияет на результат или требует контролируемой реакции.
Проверьте как минимум четыре группы:
— бизнес-отказ: клиент отказался, согласующий отклонил, лимит превышен;
— неполные данные: нет реквизитов, документа или обязательного подтверждения;
— время: ответ не поступил до срока, задача просрочена;
— техническая ошибка: внешний сервис недоступен, сообщение не принято, данные не прошли проверку.
BPMN позволяет показать события на границе действия, в том числе прерывающие основной шаг. Но для бизнес-обсуждения важнее не выбор сложного значка, а однозначная реакция: повторить автоматически, поставить задачу, вернуть на исправление, прекратить процесс или передать в ручной разбор.
Данные показывайте там, где они меняют маршрут
Диаграмма процесса не должна превращаться в схему базы данных. Нет смысла размещать на ней каждое поле карточки. Показывайте документ или набор данных, если он создаётся, проверяется, передаётся между участниками либо влияет на решение.
Например, для согласования предложения важны версия, сумма, условия, автор и решение согласующего. Полный справочник реквизитов можно вынести в словарь данных. Рядом с диаграммой удобно вести таблицу: объект, обязательные данные, источник, владелец и момент фиксации.
Если один и тот же показатель читается из нескольких систем, схема должна привести к отдельному решению об источнике истины. Иначе автоматизация ускорит обмен, но не устранит расхождение. Для будущей CRM или ERP-системы (https://synchroweb.ru/crm-erp/) процесс и модель данных проектируют совместно, не пытаясь заменить одно другим.
Как перейти от as-is к целевой модели to-be
Целевая схема строится не удалением всех ручных действий. Сначала для каждого шага определяют его назначение. Проверка может защищать от финансовой ошибки, а повторный ввод — не иметь самостоятельной ценности. Первый шаг следует сохранить и сделать контролируемым, второй — убрать за счёт интеграции.
Полезно рассматривать изменения в таком порядке:
1. устранить действия, не создающие результата и не снижающие риск;
2. назначить владельца там, где ответственность размыта;
3. зафиксировать единый источник каждого ключевого значения;
4. заменить передачу в чате системным событием и назначенной задачей;
5. автоматизировать однозначные проверки и уведомления;
6. оставить человеку решения, требующие контекста или полномочий;
7. добавить наблюдение за сроками, ошибками и незавершёнными экземплярами.
As-is и to-be нужно хранить раздельно. Иначе будущая логика незаметно смешивается с текущей, а участники не понимают, что уже работает, что изменится и какое действие исчезнет.
Что не нужно рисовать на рабочей BPMN-схеме
Чем подробнее диаграмма, тем она не обязательно полезнее. Интерфейсные действия вроде «открыть вкладку» или «нажать кнопку» обычно относятся к инструкции пользователя, а не к модели процесса. Точные названия полей и форматы данных лучше держать в словаре или API-контракте. Архитектуру серверов, очередей и баз данных показывают на технической схеме.
Также не стоит:
— разбивать понятное действие на микрошаги без самостоятельного результата;
— рисовать редкое отклонение, если оно не влияет на проектное решение;
— показывать организационную структуру вместо потока работы;
— соединять линиями объекты, между которыми нет события или передачи;
— использовать разные обозначения для одинаковых ситуаций;
— прятать неизвестное правило за словом «автоматически».
Если схема перестала помещаться на читаемой странице, процесс можно разделить на подпроцессы. Верхний уровень показывает маршрут и точки передачи, а отдельные диаграммы раскрывают сложные фрагменты.
Как проверить схему вместе с участниками
Проверка проходит не вопросом «всё ли правильно?», а разбором конкретного экземпляра. Возьмите реальный заказ и проведите его по схеме: какое событие запустило процесс, кто выполнил шаг, где появились данные, почему выбрана ветвь. Затем повторите с проблемным случаем.
Во время встречи один человек ведёт схему, а участники последовательно подтверждают факты. Спорные места лучше помечать как вопросы, а не исправлять на основании мнения самого старшего участника. После встречи изменения рассылают всем затронутым ролям: сотрудник может правильно описать собственную работу, но не знать, что происходит с документом после передачи в другой отдел.
Каждая роль должна проверить собственную дорожку и точки передачи другим участникам. Особенно полезны вопросы:
— может ли действие начаться без указанного входа;
— кто замечает, что ожидаемое событие не наступило;
— может ли одна задача иметь двух неясных ответственных;
— все ли ветви развилки имеют правило и завершение;
— где возникает новая версия документа;
— какое состояние увидит руководитель при ошибке;
— какое ручное действие схема пока не показывает.
После проверки модель связывают с требованиями: для автоматического шага определяют триггер и результат, для пользовательского — роль и интерфейс, для данных — источник, для исключения — реакцию. Так диаграмма становится рабочей основой проекта, а не иллюстрацией в презентации.
Завершённая схема должна позволять посчитать экземпляры процесса по однозначным событиям и состояниям. Если невозможно определить, когда процесс начался, где сейчас находится и почему остановился, модель ещё недостаточно точна для контроля после запуска.
Минимальный комплект перед автоматизацией
Для одного процесса обычно достаточно диаграмм as-is и to-be, словаря терминов, таблицы данных, перечня бизнес-правил и критериев результата. У каждого спорного решения должен быть владелец со стороны бизнеса. Версии схемы нужно различать, чтобы изменение целевого процесса не переписывало историю обсуждения.
Перед передачей в разработку проверьте:
— границы процесса заданы событиями, а не названиями отделов;
— у каждого действия есть одна понятная ответственная роль;
— ожидания и сроки обозначены явно;
— условия развилок можно проверить;
— основные исключения имеют определённую реакцию;
— данные показаны только там, где влияют на процесс;
— as-is не смешан с to-be;
— целевой процесс можно связать с задачами, статусами и интеграциями.
Если процесс для первой автоматизации ещё не выбран, сначала стоит сравнить кандидатов по пользе, готовности и риску. Этому посвящена статья «Какие бизнес-процессы автоматизировать в первую очередь» (https://synchroweb.ru/blog/kakie-processy-avtomatizirovat-pervymi/). BPMN приносит наибольшую пользу после такого выбора: помогает раскрыть устройство конкретной работы и договориться о её целевой логике.
Источники
— Object Management Group: спецификация BPMN 2.0.2 (https://www.omg.org/spec/BPMN/2.0.2/)
— Object Management Group: материалы и примеры BPMN 2.0 (https://www.omg.org/spec/BPMN/2.0/)
— ISO: ISO/IEC 19510:2013 — Business Process Model and Notation (https://www.iso.org/standard/62652.html)
— ISO: ISO/IEC/IEEE 29148:2018 — Requirements engineering (https://www.iso.org/standard/72089.html)