Введение и выбор диаграммы
Рассмотрим моделирование процессов в нотации BPMN (Business Process Model and Notation) на примере открытого инструментария. Для начала работы нужно выбрать тип модели. В палитре из девяти вариантов нас интересует левый нижний угол — BPMN Diagram (диаграмма BPMN). Она позволяет описывать процессы на основе спецификации 2.0, причем как внутри одной организации, так и между несколькими.
В качестве примера смоделируем выполнение работ для заказчика. Это будет общий шаблон.
Три уровня детализации BPMN
Концепция BPMN предполагает три основных сценария использования нотации по глубине проработки:
- Простое моделирование (базовое описание потока работ).
- Аналитическое моделирование (максимально полное использование всех объектов).
- Исполняемое моделирование (подготовка диаграмм для автоматизации и создания приложений).
Построение простого приватного процесса
Начнем с так называемого приватного процесса (private process). Его можно начать без пулов и дорожек, сразу со стартового события.
Стартовое событие
Выбираем стартовое событие (start event) — оно всегда отображается зеленым цветом. Поскольку действие начинается с получения послания, тип события меняем на Message Event (событие-сообщение). Атрибут Name задаем как «Сообщение от клиента на тему обсуждения условий договора».
Первая задача
Следом добавляем задачу (task). В BPMN существует несколько типов задач: абстрактная, пользовательская, ручная, скрипт (программа) и сервисная. Если нюансы неизвестны, выбираем абстрактную задачу (abstract task). Называем ее «Обсуждение условий договора».
Отличие от EPC
В нотации EPC (Event-driven Process Chain) начальное событие (розовый объект) не имеет типов, тогда как в BPMN мы специфицировали его как сообщение. Это ключевое различие: модель обогащается не только атрибутами, но и внешним видом объектов. Кроме того, для задач в BPMN принято использовать глагол в повелительном наклонении («Обсудить условия»), а не существительное («Обсуждение условий»), подчеркивая действие.
Ветвление процесса (шлюз)
После обсуждения нужна развилка. Для этого служит шлюз (gateway) — аналог логического оператора из EPC. Выбираем Exclusive Gateway (исключающий шлюз, «исключающее ИЛИ»). Он создает только один альтернативный путь. К шлюзу подводим поток управления (sequence flow).
Завершающие события
Если условия не согласованы, процесс завершается. Ставим конечное событие (end event) и подписываем связь от шлюза к нему: «Не согласованы». Если условия согласованы, ставим следующую задачу, например «Отправить типовой договор руководителю». Надпись на связи уточняет результат ветвления.
Структурирование процесса: Пулы и дорожки
Чтобы показать зоны ответственности, переходим от плоского описания к ролевому.
Создание пула и дорожек
Вводим объект пул (pool) — он обозначает сам процесс. Называем его «Оформление работ для клиента». Внутри пула создаем дорожки (lanes). Каждая дорожка — это роль или должность. Например, «Менеджер по работе с клиентами». Затем распределяем существующие задачи. Все действия, относящиеся к роли менеджера, переносятся в его дорожку. Это ключевое визуальное преимущество перед EPC: мы видим матрицу процесса, где каждое действие сразу привязано к конкретному исполнителю и не требует многократного дублирования оргструктурных единиц по всей диаграмме.
Добавление роли и фиксация результата
Добавляем вторую дорожку — «Руководитель». Поток управления от менеджера переходит к задаче руководителя «Подписать договор». После этой задачи снова ставим исключающий шлюз с вопросом «Подписан?».
- Если нет: поток через конечное событие возвращается на дорожку менеджера, так как именно он должен получить информацию об отказе.
- Если да: руководитель выполняет задачу «Присвоить договору идентификатор» (зафиксировать в базе). Затем руководитель выполняет задачу «Уведомить клиента о подписании договора».
Взаимодействие с внешней средой («Черный ящик»)
Клиент — это внешняя по отношению к организации роль. Он не может быть дорожкой внутри нашего пула. Для него создается отдельный свернутый пул (black box pool). Он изображается как «черный ящик»: мы знаем, что процесс у клиента существует, но не знаем его внутренней структуры и не должны ее описывать. Поток сообщения (message flow) от задачи «Уведомить клиента» направляется к границе пула «Клиент».
Обратная связь
Клиент может отреагировать. Мы моделируем получение ответа через промежуточное событие-сообщение (intermediate message event) на дорожке менеджера, связывая его потоком сообщения с пулом клиента. Называем событие «Получено сообщение о подтверждении договора».
Далее менеджер может выполнить финальную задачу (например, «Составить акт к договору») и завершить процесс. Завершающее событие, в отличие от EPC, не требует детальной подписи о результате — его тип уже сигнализирует об окончании потока.
Краткие итоги
Стержнем изложенного подхода является эволюция представления процесса от линейной последовательности функций к многомерной ролевой матрице. Исходная логика базируется на переходе от парадигмы EPC, где событие является абстрактным фактом, к типизированным событиям и задачам BPMN. Этот сдвиг критически важен: он позволяет уже на уровне графического примитива различать природу действия (получение сигнала, таймер, ручная обработка), что снижает когнитивную нагрузку и делает диаграмму семантически прозрачной без погружения в текстовые атрибуты.
В практической плоскости демонстрируется метод управления сложностью через грануляцию процесса. Применение исключающих шлюзов формирует строгую логику принятия решений, где каждый выход из развилки детерминирован и исключает неоднозначность. Принципиальным является прием дублирования конечного события на дорожках разных ролей: при отказе в подписании процесс завершается не у руководителя, а в зоне ответственности менеджера-инициатора, что подчеркивает важность информационного замыкания цикла на том, кто должен инициировать корректирующее воздействие.
Архитектурное решение по вынесению контрагента в отдельный свернутый пул иллюстрирует зрелый подход к коллаборации. Это позволяет четко отделить зону прямой управленческой досягаемости от внешней среды. Взаимодействие строится исключительно на обмене сообщениями между границами пулов, что соответствует асинхронной природе коммуникации. Такой прием предотвращает распространенную ошибку аналитиков — попытку детализировать неконтролируемый внешний процесс, экономя ресурс на описание нерелевантной информации.
Анализ приемов наполнения модели также важен: использование инструментария Smart Design для быстрой генерации каркаса дорожек преодолевает неудобства конкретной среды разработки. Это учит гибкости в обходе ограничений инструментария ради сохранения стройности нотации. Агрегирование этих методов дает на выходе не просто схему, а регламентированный артефакт, готовый к валидации и последующей автоматизации, особенно в части присвоения идентификаторов объектам учета на стадии формализации результата.
Рассмотрим моделирование процессов в нотации BPMN 2.0. Работа начинается с выбора BPMN Diagram, позволяющей описывать процессы внутри и между организациями.
Уровни моделирования
BPMN предполагает три уровня:
- Простое моделирование для базового описания потока.
- Аналитическое — с максимальной детализацией.
- Исполняемое — подготовка диаграммы к автоматизации.
Приватный процесс без ролей
Модель можно начать без пулов и дорожек, просто с объектов.
Стартовое событие — всегда зелёный кружок. Если процесс начинается с получения данных, выбираем тип Message Event (событие-сообщение) и присваиваем название, например «Сообщение от клиента на тему обсуждения условий договора». Ключевое отличие от EPC: в EPC событие однотипно, здесь же его тип визуально специфицирован.
Задача (Task) — прямоугольник. Если нюансы неясны, используем абстрактную задачу (Abstract Task). Формулировка названия должна быть глагольной: «Обсудить условия договора» (а не «Обсуждение»).
Ветвление осуществляется через шлюз (Gateway). Для альтернативных сценариев применяется Exclusive Gateway (исключающий шлюз, «исключающее ИЛИ»). Связи от шлюза подписываются результатами: «Согласованы» или «Не согласованы». Если условия не согласованы, поток идет к конечному событию (End Event).
Ролевое моделирование: Пулы и дорожки
Чтобы показать исполнителей, создается пул (Pool) — граница процесса. Внутри пула рисуются дорожки (Lanes), каждая соответствует роли (например, «Менеджер» или «Руководитель»). Все задачи роли помещаются на её дорожку. Это матричный принцип, не требующий дублирования оргструктуры.
После отправки договора руководителю тот выполняет задачу «Подписать договор». На выходе ставится шлюз «Подписан?».
- Ветка «Нет» завершается событием на дорожке менеджера (цикл информации замыкается на инициаторе).
- Ветка «Да» ведет к задачам «Присвоить идентификатор» и «Уведомить клиента».
Взаимодействие с внешней средой
Клиент — внешняя сторона. Его нельзя размещать на дорожке внутреннего пула. Он отображается отдельным свернутым пулом (Black Box Pool), так как его внутренние процессы неизвестны. Взаимодействие между нашим процессом и клиентом показывается потоком сообщений (Message Flow), который подводится к границе пула. Обратная связь от клиента отображается как промежуточное событие (например, «Получено подтверждение») на дорожке менеджера, после чего выполняются финальные задачи и процесс завершается.
Общий итог построения: модель эволюционирует от линейной последовательности к ролевой кросс-функциональной схеме, где внешние участники инкапсулированы, а логика переходов строго детерминирована.
1. Нотация BPMN позволяет выполнять моделирование на трех уровнях: простое описание, детальный анализ и подготовка к автоматизации исполнения.
2. В отличие от EPC, объекты BPMN (события, задачи) имеют визуальную и семантическую типизацию, что обогащает модель информацией без использования дополнительных атрибутов.
3. Названия задач («действий») в BPMN следует формулировать в формате глагола («Согласовать»), а не существительного («Согласование»).
4. Исключающий шлюз (Exclusive Gateway) создает строго альтернативное ветвление, направляя процесс только по одному из возможных путей.
5. Приватный процесс можно моделировать как без ролей (простая последовательность), так и с детализацией ответственности внутри организации.
6. Пул обозначает границы процесса, а дорожка внутри него — конкретную роль или организационную единицу, что создает матрицу ответственности.
7. Внешний участник (клиент) всегда моделируется отдельным свернутым пулом («черный ящик»), так как его внутренний процесс неизвестен или неважен для анализа.
8. Взаимодействие между пулами осуществляется только через потоки сообщений (Message Flow), а внутри пула — через потоки управления (Sequence Flow).
9. Конечное событие не требует детального текстового описания результата, так как само по себе является маркером завершения ветки потока.
10. Размещение конечного события должно отражать логику процесса: при отказе информация возвращается инициатору, а не остается у текущего исполнителя.
1. Чем пиктограмма события-сообщения (Message Event) принципиально отличается от события в нотации EPC с точки зрения семантики модели?
2. В какой ситуации при моделировании задачи допустимо использовать тип «абстрактная задача» (Abstract Task) вместо пользовательской или сервисной?
3. Каков критерий выбора исключающего шлюза (Exclusive Gateway) для ветвления, а не создания нескольких параллельных потоков?
4. Почему конечное событие в ветке «Договор не подписан» располагается на дорожке менеджера, а не руководителя?
5. Чем регламентируется использование свернутого пула (Black Box Pool) для роли клиента, и почему его нельзя отобразить как дорожку внутри основного пула?
6. В чем заключается ограничение графического редактора при вставке дополнительных дорожек в уже построенный процесс и какой существует метод его обойти?
7. Как тип связи (поток сообщений или поток управления) зависит от того, соединяет ли она объекты внутри одного пула или разных?
8. Какую функцию выполняет атрибут Placement в свойствах объекта диаграммы?
9. Зачем задаче «Присвоить договору идентификатор» предшествует успешное ветвление шлюза «Подписан?», а не прямой поток от задачи подписания?
10. На основе чего принимается решение об обогащении модели аннотациями вместо добавления новых узлов в основной поток управления?
