BPMN: как читать и рисовать схемы процессов без аналитика

Что именно показывает BPMN

Почему согласование заказа остановилось, хотя каждый сотрудник выполнил свою часть? BPMN — это язык схем бизнес-процессов: он показывает действия, участников, условия перехода и события, от которых зависит дальнейшая работа. По такой схеме можно проследить путь отдельной заявки от поступления до результата и увидеть место, где требуется решение или передача данных. Название расшифровывается как Business Process Model and Notation. Схему можно составить для обсуждения с коллегами и постановки задачи на автоматизацию. Сам рисунок ещё не запускает работу в CRM или другой программе. Чтобы получить пользу от первого разбора, владельцу бизнеса достаточно выбрать ограниченный участок работы и договориться с исполнителями о его правилах.

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

Если сразу изображать весь путь клиента от рекламы до повторной продажи, спорные места затеряются среди десятков действий, а обсуждение уйдёт в вопросы, которые команда пока не собирается менять.

Основа нотации описана в стандарте OMG BPMN 2.0.2. В рабочей схеме важно соблюдать смысл связей и развилок: одинаково выглядящие стрелки нельзя произвольно использовать и для очередности действий, и для общения с внешним участником. Цвета могут облегчать чтение, однако правило перехода сохраняет понятный смысл и без цветового выделения.

Граница процесса важнее количества фигур

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

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

Первый обоснованный выбор — небольшой завершённый процесс вместо общей схемы компании. Так проще проследить каждую ветку на реальном обезличенном обращении, определить ответственного за результат и заметить, какое действие пока существует лишь в устной договорённости. Расширять модель имеет смысл, когда её текущие границы уже понятны участникам.

Пять обозначений для первого чтения

В справочнике символов Camunda задачи показаны прямоугольниками со скруглёнными углами, события — кругами, а шлюзы для ветвления — ромбами с маркерами, которые помогают отличить выбор пути от параллельного запуска действий. Дорожки помогают распределять действия внутри участника процесса. Для первого чтения этого набора достаточно, если рядом с каждой фигурой написан понятный смысл и схема не использует дополнительные значки без объяснения.

• Начальное событие: запрос зарегистрирован. Команда указывает запись, которая подтверждает поступление запроса.
• Задача: уточнить исходные данные. Названы исполнитель и результат, который он оставляет.
• Исключающий шлюз: данных достаточно? На каждой ветке записано условие перехода.
• Параллельный шлюз: запустить независимые операции. Объяснено, нужны ли обе проверки для продолжения.
• Конечное событие: предложение отправлено. Понятно, где сохранены версия и дата отправки.

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

У события другая роль: «Стоимость рассчитана» сообщает о наступившем факте. Если эти подписи перепутать, читателю будет трудно понять, где сотрудник должен работать, а где процесс уже ждёт следующего шага.

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

Стрелки связывают действия и участников по разным правилам

В BPMN сплошная стрелка Sequence Flow задаёт очередность внутри процесса: она может пересекать границу дорожек, но не границу пула. Пунктирный Message Flow показывает обмен сообщениями между отдельными пулами. Эти правила заданы в разделах стандарта о потоках; подменять сообщение обычной стрелкой продолжения нельзя, даже если на экране так получается короче.

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

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

В учебном примере достаточно показать заказчика без подробной внутренней схемы: от него поступает запрос, ему уходит вопрос о комплектации, затем предложение. Дорисовывать за клиента процедуру согласования бюджета не стоит, если компания её не знает. Гораздо полезнее отметить, что именно отправлено и какой ответ позволит продолжить подготовку расчёта. Название роли подходит для дорожки, когда исполнители могут меняться: «Менеджер продаж», «Специалист по расчёту», «Руководитель». Имя конкретного сотрудника быстро устареет, а название отдела бывает слишком широким для назначения задачи. Отдельно назначьте владельца всего процесса: он разберёт ситуации, в которых локальная задача выполнена, но общий результат так и не достигнут.

Развилка выбирает вариант или запускает несколько работ

Исключающий шлюз отправляет процесс по одной исходящей ветке, а параллельный — по всем исходящим веткам без проверки условий. Так описано в документации ELMA365 о шлюзах. Для условия «Данных достаточно?» нужен выбор: при положительном ответе расчёт продолжается, при отрицательном менеджер уточняет сведения. Одновременный запуск обеих веток здесь создаст противоречивые поручения.

Подпишите условия.

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

Параллельная работа уместна, когда подготовка расчёта действительно не зависит от уточнения доступности товара, а отправлять предложение разрешено лишь после обеих операций. Второй обоснованный выбор — применять параллельную развилку только при такой независимости. Если цена зависит от выбранной замены отсутствующей позиции, одновременность на рисунке скроет зависимость и может привести к отправке неверной суммы.

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

Ожидания и исключения делают схему пригодной к работе

Долгое ожидание лучше назвать прямо. Документация Camunda о событиях различает начальные, промежуточные и конечные события; промежуточное событие ожидания может приостановить дальнейшее движение до сообщения или наступления времени. Таймер на границе задачи позволяет отдельно описать реакцию на задержку, причём прерывающий таймер прекращает соответствующую работу, а непрерывающий допускает её продолжение.

Для предложения это означает разные управленческие решения: напомнить специалисту о просрочке, передать расчёт другому исполнителю или прекратить подготовку после отказа заказчика. Эти реакции нельзя считать взаимозаменяемыми. Если требуется только напоминание, схема не должна случайно отменять основную работу; если запрос закрыт, оставшиеся поручения отменяют, чтобы клиент не получал прежние обещания, сохраняя историю уже выполненных действий.

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

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

Как проверить модель до настройки автоматизации

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

Ошибки ищут и в подписях.

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

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

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

Что передать исполнителю вместе со схемой

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

• Название и версия: подготовка предложения, дата согласования, владелец процесса.
• Вход: запрос с контактом, перечнем позиций и обязательными параметрами.
• Выход: отправленная согласованная версия либо закрытый запрос с причиной.
• Роли: менеджер, специалист по расчёту, согласующий; правило замещения.
• Условия: полнота данных, необходимость согласования, реакция на отказ и просрочку.
• Настройка: поля, права, уведомления, календарь сроков, связь с карточкой обращения.
• Приёмка: тестовые запросы, ожидаемые ветки, записи о завершении и отмене задач.

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