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

Диаграмма BPMN строится из четырех широких категорий:

Справочная диаграмма нотации BPMN, иллюстрирующая объекты потока, соединяющие объекты, дорожки и артефакты с примерами и описаниями.

Объекты потока:События, действия и ворота
Объекты соединения:Последовательные потоки, потоки сообщений и ассоциации
Бассейны:Бассейны и полосы
Артефакты:Объекты данных, группы и текстовые аннотации

Это руководство фокусируется на наиболее важной категории:Объекты потока BPMN. Объекты потока описывают, что происходит в процессе, какая работа выполняется и как процесс переходит с одного пути на другой.

1. Что такое объекты потока BPMN?

Объекты потока являются центральными элементами диаграммы процесса BPMN. Они соединяются последовательными потоками и представляют поведение процесса.

Существует три типа:

Объект потока	Базовая форма	Основная цель
Событие	Круг	Что-то, что происходит
Деятельность	Округлённый прямоугольник	Работа, которая выполняется
Шлюз	Ромб	Решение, разделение, слияние или точка синхронизации

Простой процесс может выглядеть концептуально следующим образом:

Начальное событие → Деятельность → Шлюз → Деятельность → Конечное событие

Например:

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

Заказ получен → Проверка наличия товара → Товар доступен?
                                      ├── Да → Отправка заказа
                                      └── Нет → Уведомление клиента

Формы просты, но символы внутри них придают дополнительное значение.

2. События: то, что происходит

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

События отображаются в виде кругов. Граница указывает, где происходит событие в процессе:

Тип события	Внешний вид границы	Значение
Событие начала	Тонкая одинарная линия	Показывает, как начинается процесс
Промежуточное событие	Двойная линия	Происходит между началом и концом
Событие окончания	Толстая одинарная линия	Показывает, как заканчивается путь процесса

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

2.1 События начала

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

Оно изображается в виде круга с тонкой границей.

Распространенные примеры включают:

Клиент отправляет заказ
Сотрудник отправляет заявку на отпуск
Таймер достигает запланированной даты
Приходит сообщение
Система обнаруживает условие
Создаётся новый случай

Событие начала без триггера

Простой круг начала означает, что процесс начинается без специально моделированного триггера.

○

Пример:

○ → Проверка заявки

Используйте событие начала без триггера, когда точный триггер либо неизвестен, либо несущественен, либо намеренно оставлен общим.

Событие начала по сообщению

Символ сообщения внутри события начала указывает на то, что процесс начинается при получении сообщения.

Пример:

◉ символ конверта → Обработка запроса клиента

Типичные случаи использования:

Получение электронной почты
Получение запроса API
Получение заказа на покупку
Получение запроса от другого участника

Событие запуска по таймеру

Часы внутри события запуска указывают на то, что процесс начинается по расписанию или дате.

Примеры:

Запуск генерации счетов-фактур каждый месяц
Начать процесс продления за 30 дней до окончания срока действия
Запустить ежедневный процесс сверки

Условное событие запуска

Условное событие запуска начинается, когда деловое условие становится истинным.

Пример:

Уровень запасов падает ниже точки перезаказа

Событие запуска по сигналу

Событие запуска по сигналу начинается при получении широковещательного сигнала. В отличие от сообщения, сигнал обычно не предназначен для одного конкретного получателя.

Пример:

Получить сигнал «Чрезвычайное закрытие» → Закрыть все филиалы

Множественное событие запуска

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

Например, случай поддержки может начаться, когда:

Клиент отправляет веб-форму
Агент вручную вводит случай
Автоматизированная система мониторинга обнаруживает проблему

2.2 Промежуточные события

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

Оно изображается с двойной рамкой.

Промежуточные события могут быть:

Получающие: Ожидание или получение чего-либо
Генерирующие: Отправка или создание чего-либо

Событие получения обычно имеет незаполненный или контурный маркер, в то время как событие генерации обычно использует заполненный маркер.

Промежуточное событие таймера

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

Примеры:

Подождать три рабочих дня
Подождать до конкретной даты
Повысить приоритет, если ответ не придет в течение 24 часов
Выполнять повторяющееся действие, пока процесс активен

Пример:

Отправить коммерческое предложение → Ждать 3 дня → Проверить ответ

Промежуточное событие сообщения

Промежуточное событие сообщения либо ожидает сообщение, либо отправляет его.

Примеры:

Отправить запрос на одобрение → Ждать ответа на одобрение

Событие сообщения особенно полезно, когда процесс взаимодействует с другим участником, отделом, организацией или системой.

Промежуточное событие ошибки

Событие ошибки представляет состояние ошибки, которое влияет на нормальный ход процесса.

Оно обычно используется как граничное событие, привязанное к деятельности или подпроцессу.

Пример:

Обработка платежа
      │
      └── Ошибка → Обработка сбоя платежа

Промежуточное событие эскалации

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

Пример:

Решение жалобы клиента
      │
      └── Эскалация → Проверка руководителем

Промежуточное условное событие

Условное событие ожидает, пока указанное условие не станет истинным.

Пример:

Дождитесь проверки учетной записи клиента

Промежуточное событие сигнала

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

Пример:

Рассылка сигнала о вызове продукции

Событие промежуточной связи

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

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

Промежуточное событие компенсации

Событие компенсации запускает корректирующие действия для отмены или компенсации ранее выполненной деятельности.

Пример:

Отмена бронирования отеля

Компенсация отличается от обычного пути ошибки. Она специально направлена на отмену или компенсацию уже выполненной работы.

2.3 События границы

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

Пример:

┌────────────────────┐
│ Приложение процесса │
└────────────────────┘
          ○
          │
          └── Тайм-аут → Передача дела

События границы полезны для моделирования:

Тайм-ауты
Отмены
Ошибки
Эскалации
Входящие сообщения
Компенсация
Внешние сигналы

Прерывающие граничные события

Прерывающее граничное событие останавливает привязанную активность при его возникновении.

Пример:

Обработка оплаты
      │
      └── Ошибка оплаты → Обработка сбоя

Активность оплаты завершается при возникновении ошибки.

Непрерывающие граничные события

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

Обычно оно отображается с пунктирной рамкой.

Пример:

Обработка заявки
      │
      └── Напоминание по таймеру → Отправка напоминания

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

Это различие важно:

Тип граничного события	Влияние на привязанную активность
Прерывающий	Останавливает активность
Не прерывающий	Оставляет активность работающей

2.4 События окончания

Событие окончания указывает на завершение пути процесса. Оно изображается в виде круга с толстой границей.

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

Примеры:

Заказ завершен
Запрос отклонен
Платеж не удался
Дело отменено
Клиент уведомлен
Процесс завершен с компенсацией

Событие окончания без указания

Простое событие окончания указывает на то, что путь завершен без указания конкретного результата.

●

Событие окончания сообщения

Событие окончания сообщения отправляет сообщение при завершении процесса.

Пример:

Заказ одобрен → Отправить подтверждение → Конец сообщения

Событие окончания ошибки

Событие окончания ошибки завершает процесс, выбрасывая ошибку в более высокий уровень процесса или обработчик.

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

Событие окончания эскалации

Событие окончания эскалации завершает текущий путь процесса и сообщает, что произошла эскалация.

Событие окончания завершения

Событие окончания завершения немедленно завершает весь экземпляр процесса, включая другие активные пути.

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

Событие окончания компенсации

Событие окончания компенсации запускает компенсационные действия перед завершением пути процесса.

3. Действия: Работа, которая выполняется

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

Примеры включают:

Проверить заявку
Утвердить счет
Отправить подтверждение
Проверка данных клиента
Расчет стоимости доставки
Обновление учетной записи
Генерация отчета

Деятельность формирует операционную основу диаграммы BPMN, поскольку показывает, где сконцентрировано время, усилия, затраты и ответственность.

3.1 Назначение деятельности

Хорошее название деятельности обычно следует этой схеме:

Глагол + объект

Примеры:

Проверка заявки
Утверждение счета
Создание записи клиента
Проверка платежа
Отправка подтверждающего электронного письма

Избегайте неопределенных названий, таких как:

Обработка
Обработка запроса
Шаг 1
Другая работа
Администрирование

Четкое название действия должно описывать действие и его объект.

Слабое название	Лучшее название
Обработка	Обработка платежа
Проверка	Проверка заявки
Шаг клиента	Проверка личности клиента
Электронная почта	Отправка письма с одобрением
Обновление	Обновление статуса заказа

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

3.2 Задачи

Задача задача — это самый простой тип действия. Он представляет собой одну единицу работы.

Базовая задача отображается в виде закругленного прямоугольника:

╭────────────────────╮
│ Проверка заявки    │
╰────────────────────╯

Задачи могут включать маркеры, которые определяют тип выполняемой работы.

Задача пользователя

Задача пользователя выполняется человеком с использованием системы или приложения.

Примеры:

Утвердить отчет о расходах
Ввести информацию о клиенте
Просмотреть контракт
Назначить дело по поддержке

Ручная задача

Ручная задача выполняется человеком без помощи движка бизнес-процессов или приложения.

Примеры:

Проверить оборудование
Подписать бумажный документ
Упаковать физический продукт
Доставить документ вручную

Задача сервиса

Задача сервиса выполняется автоматически системой, приложением, веб-сервисом или API.

Примеры:

Получить кредитный рейтинг
Отправить автоматическое электронное письмо
Рассчитать налог
Создать запись в базе данных
Вызвать сервис оплаты

Задача скрипта

Задача скрипта выполняет скрипт или фрагмент кода в среде процесса.

Примеры:

Преобразовать данные
Рассчитать значение
Форматировать сообщение
Применить простое правило данных

Задача бизнес-правила

Задача бизнес-правила оценивает бизнес-правила, часто с помощью движка правил.

Примеры:

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

Задача отправки

Задача отправки отправляет сообщение другому участнику или системе.

Примеры:

Отправить счет
Отправить подтверждение заказа
Отправить уведомление на склад

Получить задачу

Задача получения ожидает сообщение от другого участника или системы.

Примеры:

Получить подписанное соглашение
Получить подтверждение оплаты
Получить статус доставки

3.3 Подпроцессы

A подпроцесс — это деятельность, содержащая более подробный процесс.

Он может быть показан двумя способами:

Свернутый подпроцесс: Округлый прямоугольник с маркером плюс
Развернутый подпроцесс: Более крупный округлый прямоугольник, отображающий внутренний поток

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

Пример:

╭──────────────────────────────╮
│ + Завершить регистрацию клиента │
╰──────────────────────────────╯

Подпроцесс может содержать:

Собрать информацию
        ↓
Проверить личность
        ↓
Создать учетную запись
        ↓
Отправить приветственное сообщение

Когда использовать подпроцесс

Используйте его, когда:

Группа шагов имеет четкую бизнес-цель
Группа может быть использована повторно в концептуальном смысле
Основная диаграмма становится перегруженной
Заинтересованные стороны нуждаются как в кратком, так и в подробном представлении
Внутренний процесс имеет собственную логику начала, завершения, исключений или принятия решений

Вложенный подпроцесс

Вложенный подпроцесс определяется внутри родительского процесса и является частью потока этого процесса.

Вызов активности

Активность вызова запускает отдельно определённый повторно используемый процесс или глобальную задачу.

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

Проверить личность клиента

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

Подпроцесс события

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

Пример:

Основной процесс: выполнение заказа

Событийный подпроцесс:
Запрос на отмену → Отмена выполнения → Возврат средств клиенту

3.4 Маркеры действий

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

Маркер цикла

Маркер цикла указывает, что действие повторяется до тех пор, пока условие не будет выполнено.

Пример:

Проверить документ
      ↻

Используйте его для действий, таких как:

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

Маркер параллельного многократного экземпляра

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

Пример:

Получить три одобрения

Действие может выполняться одновременно несколькими проверяющими.

Маркер последовательного многократного экземпляра

Это указывает на то, что несколько экземпляров выполняются один за другим.

Пример:

Проверять предметы по одному

Маркер компенсации

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

Пример:

Возврат средств клиенту

Маркер по требованию

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

4. Шлюзы: решения, разделения и слияния

Шлюзшлюзуправляет тем, как поток процесса расходится или сходится. Шлюзы изображаются в виде ромбов.

Шлюз обычно не является задачей. Он сам не выполняет работу по принятию решений. Вместо этого он представляет, как контролируется поток процесса после оценки решения, условия или события.

Например:

Проверка заявки → Заявка полностью заполнена?

Действие проверки собирает или оценивает информацию. Затем шлюз направляет процесс в соответствии с результатом.

Шлюзы могут:

Разделять один путь на несколько путей
Сливать несколько путей в один
Синхронизировать параллельную работу
Ожидать одного или нескольких событий
Направлять работу на основе условий или правил

4.1 Исключительный шлюз: ИЛИ

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

Обычно он отображается в виде ромба с буквой «X», хотя в некоторых диаграммах этот маркер может быть опущен.

Пример:

                    ┌── Утверждено → Создать аккаунт
Проверка заявки ─◇
                    └── Отклонено → Отправить отказ

Следуется только один путь.

Типичные применения:

Если оплата одобрена, продолжить; в противном случае отклонить
Если клиент имеет право на скидку, предложить скидку
Если запрос полный, обработать его; в противном случае вернуть его

Исходящие пути обычно должны иметь четкие условия или метки:

Утверждено
Отклонено
Полный
Неполный
Сумма > 10 000 $
Сумма ≤ 10 000 $

Исключительное слияние

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

Путь по умолчанию

Путь по умолчанию может использоваться, когда ни одно из указанных условий не выполняется.

Например:

Утверждено
Отклонено
Путь по умолчанию → Ручная проверка

Путь по умолчанию полезен для неожиданных или не классифицированных случаев.

4.2 Параллельный шлюз: И

A параллельный шлюз разделяет процесс на несколько путей, которые выполняются параллельно.

Он изображается в виде ромба с плюсом.

Пример:

                 ┌── Подготовить счет-фактуру ──┐
Заказ утвержден ─◇                       ◇── Отправить заказ
                 └── Зарезервировать товары ┘

Обе активности начинаются одновременно, и процесс может позже ждать завершения обеих.

Параллельное разделение

Параллельное разделение запускает все исходящие пути.

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

Примеры:

Отправить подтверждение и обновить запасы
Уведомить финансы и уведомить операции
Выполнить проверку безопасности и проверку мошенничества

Параллельное объединение

Параллельное объединение ожидает завершения всех входящих путей перед продолжением.

Иногда это называют синхронизацией.

Подготовить счет-фактуру ──┐
                  ◇── Выполнить заказ
Зарезервировать товары ┘

Если один из входящих потоков задерживается, объединение ждет его завершения.

4.3 Входящий шлюз: ИЛИ

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

Он изображается в виде ромба с кругом внутри.

Пример:

Клиент имеет право на:
- Стандартную скидку
- Скидку за лояльность
- Скидку по акции

Может быть выбрано более одного действия, связанного со скидкой, если выполняется несколько условий.

Используйте входящий шлюз, когда:

Одно или несколько условий могут быть истинными
Несколько путей могут выполняться одновременно
Процесс должен продолжаться после завершения всех выбранных путей

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

4.4 Шлюз на основе события

Один шлюз на основе события направляет процесс в соответствии с тем событием, которое произойдет первым.

Часто за ним следует захватывающее промежуточное событие или задача получения.

Пример:

Отправить коммерческое предложение → Шлюз на основе события
                         ├── Сообщение получено → Обработка одобрения
                         └── Таймер истек → Отправить напоминание

Определяет путь только первое произошедшее событие.

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

Шлюз на основе события против исключающего шлюза

Вопрос	Исключающий шлюз	Шлюз на основе события
Что определяет путь?	Условие или бизнес-правило	Первое произошедшее событие
Типичный вопрос	«Одобрена ли заявка?»	«Что произойдет первым?»
Обычные последующие элементы	Деятельность или последовательные потоки	Поймать события или задачи получения
Источник решения	Данные или логика	Внешнее событие

4.5 Сложный шлюз

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

Примеры включают:

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

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

4.6 Варианты шлюзов на основе событий

BPMN также поддерживает варианты шлюзов на основе событий, включая:

Исключающие шлюзы на основе событий
Параллельные шлюзы на основе событий
Шлюзы на основе событий, инициирующие процесс

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

5. Как работают вместе объекты потока

Значение диаграммы BPMN определяется отношениями между событиями, действиями, шлюзами и последовательными потоками.

Рассмотрим процесс заказа:

Начало
  ↓
Получить заказ
  ↓
Проверить наличие товара
  ↓
Товар доступен?
  ├── Да → Упаковать заказ → Отправить заказ → Конец
  └── Нет → Уведомить клиента → Конец

В этом примере содержится:

Событие начала процесса которое запускает процесс
Действия по получению, проверке, упаковке, отправке и уведомлению
Исключающий шлюз exclusive gateway который выбирает один путь
Два события окончания или пути окончания, представляющие различные результаты

Более сложная версия может быть следующей:

Начало
  ↓
Получить заказ
  ↓
Проверить наличие товара
  ↓
Товар доступен?
  ├── Нет → Уведомить клиента → Конец
  └── Да → Параллельный шлюз
                   ├── Зарезервировать товар
                   ├── Подготовить счет
                   └── Проверить мошенничество
                         ↓
                 Параллельное объединение
                         ↓
                    Отправить заказ
                         ↓
                        Конец

Здесь:

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

6. События, действия и шлюзы: Былое сравнение

Элемент	Ключевой вопрос	Пример
Событие	Что произошло или произойдет?	Оплата получена
Действие	Какая работа выполняется?	Проверить оплату
Шлюз	Какой маршрут должен пройти процесс?	Действительна ли оплата?

Полезное правило:

События происходят
Действия выполняются
Шлюзы контролируют путь

Если вы не уверены, какой символ использовать, спросите:

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

7. Правильное соединение объектов потока

Объекты потока соединяются различными типами линий. Неправильное использование соединителей может привести к неверному толкованию диаграммы.

7.1 Последовательный поток

Линияпоследовательный поток — это сплошная линия с стрелкой. Она показывает порядок выполнения объектов потока в рамках одного процесса.

Деятельность A → Деятельность B

Используйте последовательный поток для соединения:

События с деятельностью
Деятельность с шлюзами
Шлюзы с деятельностью
Деятельность с конечными событиями

Последовательность потока обычно не должна пересекать границу между отдельными бассейнами.

7.2 Поток сообщений

A поток сообщений — это штриховая линия с открытым концом стрелки. Она представляет обмен сообщениями между отдельными участниками или бассейнами.

Примеры:

Клиент отправляет заказ продавцу
Продавец отправляет подтверждение клиенту
Банк отправляет результат оплаты торговцу

Используйте поток сообщений для общения, а не для отображения внутреннего порядка процесса.

7.3 Ассоциация

Ассоциация ассоциация — это пунктирная линия, используемая для соединения объектов, заметок или представлений данных с объектами потока.

Примеры:

Привязать документ к задаче
Связать текстовую заметку с деятельностью
Показать, что задача использует объект данных

Три основных типа соединяющих объектов — это последовательные потоки, потоки сообщений и ассоциации.

8. Бассейны и полосы

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

Пул

Пул представляет участника в процессе.

Примеры:

Клиент
Поставщик
Банк
Компания
Государственное учреждение
Внешняя система

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

Лента

Лента делит пул по ответственности, роли, отделу, системе или местоположению.

Примеры:

Служба поддержки клиентов
Финансы
Склад
Менеджер
Система оплаты

Ленты помогают ответить на вопрос:

Кто несет ответственность за эту деятельность?

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

9. Объекты данных и другие вспомогательные элементы

Объекты данных не являются объектами потока, но они предоставляют полезный контекст относительно информации, используемой, создаваемой или изменяемой деятельностью.

Примеры:

Заявление на подачу заявки
Счет
Заказ на покупку
Запись клиента
Документ об утверждении
Ярлык для доставки

Объект данных может быть связан с деятельностью следующим образом:

Форма заявки → Проверка заявки

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

Другие вспомогательные элементы включают:

Хранилища данных:Постоянные места хранения данных
Текстовые примечания:Пояснительные заметки
Группы: Визуальная организация связанных элементов
Связи: Связи между вспомогательными элементами и объектами потока

10. Пошаговый метод моделирования процесса

Шаг 1: Определите границы процесса

Определите, где процесс начинается и заканчивается.

Например:

От: Клиент отправляет заказ
До: Заказ отправлен или отклонен

Избегайте моделирования всей организации на одном диаграмме.

Шаг 2: Определите участников

Перечислите людей, отделы, системы или организации, участвующие в процессе.

Примеры:

Клиент
Продажи
Финансовый отдел
Склад
Платежный шлюз

Они могут стать пулы или полосы.

Шаг 3: Определите триггер начала

Спросите:

Что вызывает начало этого процесса?

Используйте соответствующее событие начала:

Сообщение
Таймер
Условный триггер
Сигнал
Нет

Шаг 4: Перечислите основные действия

Запишите каждое действие в формате глагол-объект:

Получить заказ
Проверить заказ
Рассчитать итог
Утвердить оплату
Отправить заказ

На этом этапе не беспокойтесь о каждом исключении.

Шаг 5: Добавьте решения

Ищите вопросы, такие как:

Заказ завершен?
Оплата утверждена?
Наличие товара на складе?
Клиент соответствует требованиям?
Срок истек?

Используйте воронки для отображения того, как ответ влияет на процесс.

Шаг 6: Добавьте параллельные задачи

Определите действия, которые могут происходить одновременно.

Например:

Обновить остатки на складе
Отправить подтверждение
Создать счет-фактуру

Используйте параллельные воронки, когда все ветви должны быть завершены или синхронизированы.

Шаг 7: Добавьте промежуточные и граничные события

Задайте вопрос: что может произойти во время выполнения работы:

У действия есть срок?
Может ли быть отменено?
Может ли произойти ошибка?
Может ли прийти внешнее сообщение?
Должен ли процесс быть повышен, если он занимает слишком много времени?

Шаг 8: Добавьте конечные события

Определите все значимые результаты:

Завершено
Отклонено
Отменено
Неудача
Передано на рассмотрение
Компенсировано

Шаг 9: Добавьте данные и аннотации

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

Шаг 10: Проверьте диаграмму

Проверьте, что:

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

11. Распространенные ошибки моделирования BPMN

Ошибка 1: Использование шлюза в качестве действия принятия решения

Шлюз должен направлять процесс, а не выполнять анализ.

Слабая модель:

◇ Проверить кредитный рейтинг

Лучшая модель:

Проверить кредитный рейтинг → Кредит одобрен?

Деятельность выполняет проверку. Шлюз направляет в зависимости от результата.

Ошибка 2: Использование последовательного потока между отдельными пузырями

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

Неправильная концепция:

Пузырь клиента ── сплошной последовательный поток ── Пузырь продавца

Лучшая концепция:

Пузырь клиента ── пунктирный поток сообщений ── Пузырь продавца

Ошибка 3: Оставление путей шлюза без меток

Шлюз без метки создает неоднозначность.

Вместо:

◇ → Путь A
  → Путь B

Используйте:

◇
├── Одобрено
└── Отклонено

Ошибка 4: Использование исключительного шлюза для параллельной работы

Если все действия должны произойти, не используйте исключительный шлюз.

Неправильно:

◇ ├── Отправить подтверждение
   └── Обновить инвентаризацию

Это означает, что выбран только один путь.

Используйте параллельный шлюз, если оба действия должны произойти:

+ ├── Отправить подтверждение
  └── Обновить инвентаризацию

Ошибка 5: Использование параллельного шлюза для условных операций

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

Ошибка 6: Моделирование каждой незначительной операции

Диаграмма может стать непонятной, если включить каждый клик, ввод данных в поле и внутренние действия системы.

Моделируйте на уровне, соответствующем вашей аудитории:

Руководители нуждаются в основных этапах
Ответственные за процесс нуждаются в ответственности и решениях
Разработчики могут нуждаться в деталях реализации
Аудиторы могут нуждаться в контролях и доказательствах

Ошибка 7: Создание тупиковых путей

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

Ошибка 8: Необоснованное смешение бизнес-логики и технической реализации

Диаграмма бизнес-процесса должна сначала объяснить процесс. Технические детали следует включать только в том случае, если они помогают целевой аудитории.

12. Практические правила именования

Последовательное именование делает диаграммы проще для чтения.

События

Обозначьте события результатом, возникновением или условием:

Заказ получен
Оплата подтверждена
Срок достигнут
Клиент отменил
Произошла ошибка

Деятельность

Используйте:

Глагол + объект

Примеры:

Просмотреть контракт
Утвердить запрос
Обновить учетную запись
Отправить уведомление

Шлюзы

Шлюзы часто наиболее ясны, когда связаны с вопросом:

Заявка полностью заполнена?
Оплата одобрена?
Наличие товара на складе?
Срок истек?

Выходящие пути должны содержать ответы:

Да / Нет
Утверждено / Отклонено
Доступно / Недоступно

События завершения

Назовите события завершения в соответствии с результатом:

Заказ завершен
Запрос отклонен
Платеж не удался
Случай отменен

13. Выбор правильного шлюза

Используйте это руководство по принятию решений:

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

Быстрая умственная проверка:

Один путь? Исключительный
Все пути? Параллельный
Некоторые пути? Включающий
Первое событие? На основе события
Необычная пользовательская логика? Сложный

14. Полный пример: процесс возврата средств клиенту

Рассмотрим процесс возврата средств клиенту.

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

Начало: запрос на возврат получен
                ↓
        Рассмотрение запроса на возврат
                ↓
        Запрос соответствует условиям?
          ├── Нет
          │    ↓
          │  Отправка уведомления об отказе
          │    ↓
          │  Конец: возврат отклонен
          │
          └── Да
               ↓
          Утверждение возврата
               ↓
        Параллельный шлюз
          ├── Выпуск возврата
          └── Обновление учетной записи клиента
               ↓
        Объединение параллельных путей
               ↓
        Отправка подтверждения возврата
               ↓
        Конец: возврат завершен

Эта модель демонстрирует:

Событие начала сообщения
Пользовательские или ручные действия
Исключающий шлюз
Путь отклонения
Параллельное разделение
Параллельное объединение
Действие подтверждения
Разные конечные результаты

Если сервис возврата может выйти из строя, добавьте событие ошибки на границе к Выдать возврат:

Выдать возврат
      │
      └── Ошибка → Создать ручное дело для проверки

Если возврат должен быть завершен в течение пяти рабочих дней, добавьте событие таймера на границе:

Выдать возврат
      │
      └── Таймаут 5 дней → Усилить возврат

15. Сжатый справочник символов BPMN

Категория символа	Значение	Типичное использование
Тонкий круг	Событие начала	Начать процесс
Двойной круг	Промежуточное событие	Ожидание, отправка, получение или реакция
Толстый круг	Событие окончания	Завершить путь процесса
Округлый прямоугольник	Задача или действие	Выполнить работу
Округлый прямоугольник с плюсом	Свернутый подпроцесс	Группировать детальную работу
Ромб с крестом	Исключающий шлюз	Выбрать один путь
Ромб с плюсом	Параллельный шлюз	Запустить все пути
Ромб с кругом	Включающий шлюз	Запустить один или несколько путей
Диамант с маркером события	Шлюз на основе события	Следовать первому событию
Сплошная стрелка	Последовательный поток	Показать внутренний порядок
Штриховая стрелка	Поток сообщений	Показать коммуникацию
Пунктирный соединитель	Ассоциация	Связать заметки или данные
Бассейн	Участник	Представлять организацию или процесс
Полоса	Роль или ответственность	Назначить ответственность
Форма документа/данных	Объект данных	Показать информацию, используемую или создаваемую

16. Окончательные принципы моделирования

Наиболее эффективные диаграммы BPMN следуют нескольким основным принципам:

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

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

Эта статья также доступна на Deutsch, English, Español, فارسی, Français, English, Bahasa Indonesia, 日本語, Polski, Portuguese, Việt Nam, 简体中文 and 繁體中文