Заявка поступает оператору. Он проверяет, достаточно ли данных для дальнейшей работы. Если всё заполнено, ответственный сотрудник подтверждает заявку. Если сведений не хватает, оператор возвращает её на уточнение.
Чтобы согласовать такой процесс, нужно ответить на три вопроса: в каком порядке выполняются действия, кто отвечает за каждое из них и при каком условии меняется маршрут. В текстовом регламенте эти связи легко оказываются разбросаны по нескольким абзацам. На диаграмме их можно проследить от начала до одного из двух результатов.
Для этого используется BPMN — нотация описания бизнес-процессов. Разберём основные символы BPMN 2.0 и прочитаем один учебный пример с двумя ролями и альтернативными исходами. После статьи вы сможете отличать последовательность действий внутри процесса от обмена сообщениями между его участниками. Знание BPMN-редактора не потребуется.
BPMN 2.0: что это за нотация
BPMN — стандартная нотация OMG для графического описания бизнес-процессов. Название расшифровывается как Business Process Model and Notation. Её используют, чтобы описывать действия, события, решения и участников с помощью символов, значение которых определено стандартом.
Символы важны не только внешне. Ромб с крестом внутри означает выбор одного из возможных путей, ромб с плюсом — запуск параллельных путей. Сплошная стрелка показывает порядок действий в процессе; пунктирная с открытым наконечником служит для обмена сообщениями между разными участниками. Поэтому одна неправильно выбранная линия может изменить смысл схемы.
Обозначение BPMN 2.0 относится ко второй версии нотации. В каталоге OMG её формальная версия — 2.0.2. Ниже используются правила из нормативной спецификации, без попытки охватить все её элементы.
BPMN применяют при обсуждении процесса между аналитиком, разработчиком, тестировщиком и владельцем процесса. При этом графическое описание не означает, что процесс уже можно выполнить программно: для исполнения понадобятся данные, условия и поддерживаемые конкретным движком типы задач.
События и задачи
В BPMN событие фиксирует факт, влияющий на ход процесса, а задача обозначает работу, которую нужно выполнить. Для нашего примера достаточно трёх типов элементов:
| Элемент | Роль в процессе | Пример на схеме |
|---|---|---|
| Стартовое событие | Указывает, где начинается маршрут | «Заявка получена» |
| Задача | Обозначает действие | «Проверить заявку» |
| Конечное событие | Показывает завершение маршрута | «Подтверждено» или «Нужны данные» |
Стартовое событие обозначают кругом с тонкой границей, конечное — кругом с толстой. По одной толщине линии можно отличить начало пути от его завершения. В учебном процессе два конечных события: на разных ветвях остаётся разный результат, и это следует показать явно.
Задачу изображают прямоугольником со скруглёнными углами. «Проверить заявку», «Подтвердить заявку» и «Вернуть на уточнение» называют конкретную работу. Если заменить их общей формулировкой «Обработка», из схемы исчезнет понимание, какое действие совершается на каждом шаге.
В BPMN существуют также промежуточные события, подпроцессы и различные виды задач. Они нужны, например, для описания ожиданий и более сложного поведения. В данном случае достаточно основных символов: дальнейшие правила выбора можно показать одним шлюзом.
Шлюзы BPMN: выбор и параллельность
Шлюз задаёт правило разветвления или соединения потоков. Его изображают ромбом; символ внутри позволяет различать типы шлюзов.
Исключающий шлюз (XOR) направляет поток по одной из альтернативных ветвей. В нашем процессе после задачи «Проверить заявку» вопрос «Данных достаточно?» определяет следующее действие: подтверждение заявки либо возврат на уточнение. Оба пути для одной проверки одновременно не выбираются.
У исходящих потоков можно задать условия. В учебной модели у стрелки «Да» есть условие достаточности данных. Путь «Нет» отмечен косой чертой: это поток по умолчанию. Поток по умолчанию выбирается, если ни одно условие на других исходящих стрелках не выполнилось. Следовательно, надпись «Нет» здесь поясняет результат для читателя, но сама по себе не является вторым вычисляемым условием. Важно различать крест внутри ромба (тип XOR) и косую черту на выходящем потоке (маркер ветви по умолчанию). Эти правила описаны в спецификации BPMN 2.0.2.
Параллельный шлюз (AND) создаёт потоки по всем исходящим ветвям без проверки условий. Например, после приёма заявки могут одновременно начаться проверка документов и проверка контактных данных. Если обе работы должны завершиться до следующего шага, понадобится также синхронизация параллельных ветвей. В нашем примере AND не используется, потому что подтверждение и возврат взаимоисключают друг друга.
Если диаграмма предназначена для автоматического исполнения, условий в виде слов «Да» и «Нет» недостаточно: нужно задать выражение, которое умеет вычислять выбранный движок.
Потоки, пулы и дорожки
Поток последовательности (Sequence Flow) показывает переход от одного элемента процесса к следующему. На диаграмме это сплошная линия со сплошным наконечником. Поток последовательности может пересекать дорожки, но не границы пула.
Пул (Pool) представляет участника взаимодействия и задаёт границу его процесса. Дорожки (Lanes) разделяют работу внутри пула по ролям или зонам ответственности. Передачу заявки от оператора ответственному можно изобразить стрелкой через границу дорожек: работа продолжается в одном процессе, хотя исполнитель меняется.
Поток сообщений (Message Flow) изображают пунктирной линией с пустым кружком в начале и открытым наконечником. Поток сообщений соединяет разные пулы. Если описывать обмен заявкой с внешней организацией, её следует показать отдельным участником; между двумя дорожками одного пула поток сообщений не проводят.
Правила потоков и участников приведены в разделах 7–9 стандарта OMG. При чтении диаграммы различайте эти связи: поток последовательности отвечает за порядок работы, поток сообщений — за передачу информации между самостоятельными участниками.
На учебной схеме один пул «Обработка заявки» и две дорожки — «Оператор» и «Ответственный». Поэтому все шесть стрелок в модели являются потоками последовательности, а передача работы другой роли не требует отдельного сообщения.
Пример BPMN-диаграммы: обработка заявки
Рассмотрим учебный процесс без привязки к конкретной компании. Оператор получает заявку и проверяет обязательные сведения. Если данные полны, ответственный подтверждает заявку. Если сведений не хватает, оператор возвращает её на уточнение. В этой упрощённой модели возврат завершает текущий экземпляр процесса: повторная подача считается новым запуском.
В нашем примере семь узлов и шесть потоков последовательности. Узлы — одно стартовое событие, три задачи, один XOR-шлюз и два конечных события. Пул и дорожки обозначают организационную структуру, поэтому не входят в число узлов.
- «Да». После проверки поток пересекает границу дорожки «Ответственный», приводит к задаче «Подтвердить заявку» и завершается событием «Подтверждено».
- «Нет». Путь по умолчанию остаётся в дорожке оператора, ведёт к «Вернуть на уточнение» и заканчивается событием «Нужны данные».
От старта до каждого конца маршрут проходит через проверку, шлюз и одну из двух задач. В модели нет ожидания ответа заявителя, повторного цикла, таймеров и внешнего пула. Эти детали потребовали бы отдельных элементов и правил.
Как читать BPMN-диаграмму
Начните со стартового события и двигайтесь по сплошным стрелкам. У каждой задачи определите действие, по дорожке — ответственного. Дойдя до шлюза, найдите символ внутри ромба, условия выходящих стрелок и возможный путь по умолчанию.
| Результат проверки | Следующее действие | Конечное событие |
|---|---|---|
| Данных достаточно | Ответственный подтверждает заявку | «Подтверждено» |
| Данных недостаточно | Оператор возвращает заявку на уточнение | «Нужны данные» |
Проверьте себя: почему стрелка к задаче «Подтвердить заявку» пересекает границу дорожки? Потому что исполнителем становится другая роль того же процесса. Отдельный поток сообщений здесь не нужен.
Может ли один экземпляр процесса одновременно достичь обоих конечных событий? В этой модели нет: XOR выбирает один исходящий маршрут. Если бизнес-правило предполагает параллельную работу, схему нужно изменить, а не просто добавить ещё одну стрелку.
Диаграмма понятна, если при каждом допустимом исходе проверки вы можете дойти от начала до конкретного завершения и объяснить, кто выполнил действие.
Ошибки при построении BPMN-диаграммы
Поток сообщений между дорожками одного пула. Дорожки относятся к одному процессу. Для передачи работы между ними нужен поток последовательности. Обмен с внешним участником моделируют между разными пулами.
Параллельный шлюз вместо исключающего. Если поставить AND после проверки данных, обе ветви будут запущены. Это противоречит правилу «либо подтвердить, либо вернуть». Для такого решения нужен XOR.
Условие на каждой стрелке только на словах. Подписи «Да» и «Нет» помогают читать диаграмму, но не описывают логику исполнения. В нашем примере ветвь «Нет» — поток по умолчанию: она выбирается, когда условие для «Да» ложно. В модели для движка условие должно быть вычислимым.
Задачи с названиями без действия. По слову «Обработка» непонятно, что делает исполнитель. «Проверить заявку» и «Подтвердить заявку» позволяют восстановить последовательность конкретных работ.
Возврат, нарисованный как мгновенный цикл. Если после возврата требуются исправления от заявителя, повторная проверка зависит от нового действия или события. В учебной модели ожидание не показано: текущий путь заканчивается событием «Нужны данные».
После построения схемы пройдите каждый маршрут от стартового до конечного события. Если для какого-то перехода нельзя назвать условие или ответственную роль, диаграмма ещё требует уточнения.
Что можно выяснить по BPMN-диаграмме
По диаграмме можно восстановить порядок работы, ответственных, правило выбора и результаты процесса. В нашем примере это проверка заявки оператором, два возможных продолжения и отдельное завершение каждой ветви. Такой разбор помогает заметить пропущенное условие или непонятную передачу работы ещё на этапе согласования процесса.
BPMN XML хранит элементы процесса и их связи, а BPMN DI — координаты фигур и линий на диаграмме. Благодаря этому модель и её графическое расположение можно сохранить вместе; например, BPMN-файл можно открыть в поддерживающем нотацию редакторе bpmn-js. Корректное отображение и возможность исполнения — разные свойства: не каждый редактор или движок поддерживает все элементы и выражения.
Граница примера: здесь не описаны отдельный заявитель, ожидание ответа, повторная проверка и обработка ошибок. Мы также не проверяем работу реальной системы по этой схеме. Для автоматизации потребуются данные процесса, вычислимые условия шлюзов, исполняемые типы задач и правила обработки исключений.
При чтении собственной диаграммы ответьте на три вопроса: где начинается процесс, по какому условию выбирается каждый путь и чем он заканчивается. Если ответы однозначны и за каждой задачей закреплена роль, базовая схема уже пригодна для обсуждения с командой.