Rogan Documentation – BPMN 2.0 на русском языке. Документация. Обучение. Моделирование.

BPMN

Статьи

Введение в BPMN

Нотация BPMN

Нотация моделирования бизнес-процессов BPMN (Business Process Model and Notation) – это международный стандарт моделирования бизнес-процессов. Он является одним из важнейших компонентов для достижения согласованности между Бизнес-процессами и ИТ-системами.

Большинство современных компаний сегодня выбирают BPMN в качестве стандарта для моделирования своих процессов. Основные причины этого выбора:

Поддержка популярными программными продуктами для моделирования бизнес-процессов (Business Studio, ELMA, Bizagi и др.);
Оптимальный набор графических элементов, который позволяет детально описать любой процесс;
Возможность автоматизировать бизнес-процессы без необходимости программирования;
Уменьшение разрыва между моделями «Как есть» и «Как должно быть».

Как пользоваться данным руководством

Благодаря большому количеству примеров настоящее руководство по BPMN можно использовать как самоучитель для освоения нотации “с нуля”. Для этого рекомендуется читать все главы по порядку с самого начала. Также это руководство подходит в качестве справочника, в котором опытные специалисты могут найти ответ на вопрос, если что-то забыли.

Руководство по BPMN имеет следующие особенности:

Любую статью можно прокомментировать: задать вопрос или высказать пожелание по более подробному описанию отдельных моментов.

Все содержимое полностью соответствует последней версии спецификации нотации BPMN;

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

Диаграммы выполнены в едином стиле и в черно-белом цвете для удобства восприятия материала;

Мы постарались писать простым, понятным языком, чтобы любой специалист смог легко разобраться в теме;

Простая диаграмма в BPMN

Пример диаграммы

Для первоначального понимания нотации BPMN рассмотрим простую диаграмму процесса:

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

Описание примера диаграммы BPMN

Стартовое событие (Возникло чувство голода)

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

Действие (Купить продукты, Приготовить еду, Съесть еду)

Действие – это основа любого процесса, так как для достижения заданного результата процесса всегда необходимо что-то делать. Иногда действия BPMN называют «задачами» или «работами» – это тоже верно.

В BPMN действие может быть элементарным или составным. Составные действия сами являются процессами, поскольку содержат вложенные действия и другие процессы – так работает принцип декомпозиции. В нашем примере можно было бы декомпозировать действие «Приготовить еду» на более мелкие задачи: подготовить посуду и ингредиенты, выполнить все действия по рецепту, проверить готовность еды, подать еду на стол. Посмотрите, мы как будто «разворачиваем» подпроцесс «Приготовить еду» и показываем последовательность его подзадач:

Промежуточное событие (Еда приготовлена)

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

Конечное событие (Чувство голода удовлетворено)

Конечное (или «завершающее») событие показывает результат, достигнутый в ходе выполнения процесса и является конечной точкой процесса. В BPMN есть несколько видов конечных событий, благодаря которым при завершении процесса можно, например, генерировать сообщения и сигналы, запускать другие процессы и т.д. Примеры завершающих событий:

Практический совет

Как именовать элементы BPMN?

При наименовании процессов и задач необходимо придерживаться формулы: “глагол (указывает на выполняемую работу) плюс существительное (указывает на объект выполняемой работы)”. Например, «Выдать карту», «Оказать услугу», «Продать товар».

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

События относятся к тому, что уже произошло независимо от процесса или в результате процесса. Поэтому для наименования событий необходимо использовать формулу: “объект плюс глагол совершенного вида в прошедшем времени (отвечает на вопрос «что сделано?» или «что произошло?»)”. Например, «Поступила заявка», «Выполнено условие», «Истекло 15 минут».

В BPMN формально отсутствует требование, чтобы для каждой функции было смоделировано начальное и конечное событие, но каждый процесс должен каким-то событием начинаться и иметь определенный результат – конечное событие. Во-первых, таким образом можно определить событие, которое инициирует запуск процесса, а во-вторых, зафиксировать окончательный статус (результат) этого процесса.

Часто задаваемые вопросы

Обязательно ли моделировать диаграммы BPMN по горизонтали?

Что делать, если я предпочитаю моделировать их вертикально?

Вы можете моделировать диаграммы вертикально, стандарт BPMN разрешает это. Однако мы рекомендуем пользоваться горизонтальным расположением диаграммы. Опыт показывает, что люди склонны воспринимать лучше всего поток функций (действий), если он описан так же, как и письменный текст (слева направо).

Пример вертикального оформления диаграммы:

Использование шлюзов в BPMN

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

Параллельный шлюз BPMN

Стартовое событие «Товар заказан» означает, что действия по продаже товара уже были выполнены. Параллельный шлюз после стартового события показывает, что далее параллельно выполняются два действия. Иными словами, поток управления разветвляется и запускает одновременно две разные задачи. Пока секретарь выбирает способ доставки товара (критерии выбора мы не определяем, это решается внутри подпроцесса), работник склада уже может упаковать товар.

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

Эксклюзивный шлюз BPMN

Задача секретаря «Выбрать способ доставки», за которой следует эксклюзивный шлюз «Способ доставки», является хорошим примером для разъяснения использования этого шлюза. Шлюз не выбирает решение, будет это отправка простой почтой, либо курьерской службой. Данное решение принимается ранее. Шлюз работает только как маршрутизатор, который срабатывает в зависимости от результата предыдущей задачи и выбирает альтернативный путь. Задача (действие) представляет собой фактическую единицу работы, тогда как шлюз только маршрутизирует потоки информации.

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

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

Неэксклюзивный шлюз BPMN

В нашем примере используется два неэксклюзивных шлюза BPMN. Первый – после задачи «Проверить необходимость дополнительной страховки» и второй – после задач «Выбрать страховку» и «Заполнить бланк отправления». Первый неэксклюзивный шлюз BPMN выполняет ветвление потока управления и называется «открывающим». При этом одна образующаяся ветка процесса выполняется всегда, а ветка «Требуется страховка» выполняется только если требуется дополнительная страховка. Второй неэксклюзивный шлюз BPMN выполняет слияние двух потоков управления и называется «закрывающим». Он будет ждать завершения задач по всем потокам, которые были запущены «открывающим» шлюзом. В нашем случае может быть два варианта:

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

Такая логика работы пары неэксклюзивных шлюзов BPMN – «открывающего» и «закрывающего» – называется «динамическая синхронизация потоков управления».

Практический совет

Обращайте внимание на пулы

Обратите внимание, что в нашем примере использован только один пул – «Розничный продавец оборудования» и разные дорожки для сотрудников, участвующих в процессе. Это говорит нам об отсутствии автоматического назначения задач сотрудникам в ходе выполнения процесса, однако, предполагается, что они общаются друг с другом каким-то образом. Благодаря этому общению обеспечивается логика и последовательность выполнения всех шагов.

Пул и ролевые дорожки BPMN

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

Взаимодействие процессов

Пример взаимодействия процессов

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

Два взаимодействующих между собой пула изображены здесь чтобы показать потоки объектов (сообщений, документов, товаров, денег) между участниками процесса. Такой вид диаграмм называется «диаграмма взаимодействия BPMN» и позволяет отразить взаимодействие между различными отделами, командами, отдельными сотрудниками или даже программными системами.

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

Стартовое событие BPMN

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

Эксклюзивный шлюз по событиям BPMN

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

пицца доставлена, как указано в промежуточном событии с типом «Получение сообщения» – «Пицца доставлена»,
пицца не доставлена в течение 60 минут (событие «Таймер»), в этом случае клиент звонит в службу доставки. Далее администратор обещает, что пицца будет доставлена в ближайшее время (действие «Успокоить клиента»), и клиенты снова ждут пиццу, снова спрашивая после следующих 60 минут и так далее.

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

Промежуточное событие BPMN с типом «Сообщение»

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

Официальная документация BPMN

Нотация BPMN

Нотация BPMN разработана компанией Business Process Management Initiative и в настоящее время поддерживается организацией Object Management Group (OMG), после слияния обеих организаций в 2005 году.

OMG регулярно актуализирует и обновляет спецификацию нотации BPMN. Последняя версия BPMN — 2.0 (2.0.2), предыдущая версия — 1.2.

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

Спецификации BPMN

Постеры BPMN

Обзор всех видов диаграмм BPMN

В BPMN существует 4 вида диаграмм:

Первые три вида диаграмм являются основными, а четвертый вид – «Диалог» – является дополнительным и появился лишь в BPMN 2.0. На практике чаще всего используют 2 вида диаграмм: диаграммы «Процесс» и «Взаимодействие». Рассмотрим назначение всех видов диаграмм:

Процесс (Process Diagram)

Описывает содержание и логику бизнес-процесса BPMN в виде потока задач, условий и событий. Это самый распространенный, часто применяемый вид диаграмм, он является основой нотации BPMN. Пример диаграммы «Процесс»:

Взаимодействие (Collaboration Diagram)

Позволяет моделировать взаимодействие (обмен данными) между двумя или более бизнес-процессами BPMN. Для графического отображения такого взаимодействия используются потоки сообщений (message flow). Пример диаграммы «Взаимодействие»:

Хореография (Choreography Diagram)

Иногда диаграммы “Взаимодействие” оказываются слишком сложными для восприятия и требуют более наглядного представления. В этом случае применяют диаграммы хореографии. Они описывают поток (последовательность) взаимодействий участников при выполнении бизнес-процессов BPMN. Пример диаграммы «Хореография»:

Диалог (Conversation Diagram)

Является еще одним вариантом диаграммы для визуализации взаимодействий бизнес-процессов BPMN и их участников. Диаграмма “Диалог” описывает процессный ландшафт и взаимодействия верхнего уровня между вовлеченными сторонами. Пример диаграммы «Диалог»:

Процесс

Диаграмма «Процесс» описывает содержание и логику бизнес-процесса в виде потока задач, условий и событий. Это самый распространенный, часто применяемый вид диаграмм, он является основой нотации BPMN.

Графические элементы диаграммы «Процесс»

Задачи BPMN – это элементарные (неделимые) работы, которые должны быть выполнены в рамках бизнес-процесса. Примеры задач:

Поток управления BPMN – обозначает порядок (последовательность) выполнения действий в бизнес-процессе. Поток управления обозначается сплошной стрелкой:

Подпроцессы BPMN – это составные действия, которые можно декомпозировать на дочерние подзадачи и / или другие подпроцессы. Примеры подпроцессов:

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

Шлюзы BPMN – это логические операторы, которые используются для слияния и ветвления потоков управления в бизнес-процессах. Шлюзы могут работать в зависимости от определенных условий или безусловно. Примеры шлюзов:

Дорожки (ролевые дорожки BPMN) – обозначают исполнителей бизнес-процесса и изображаются в виде прямоугольников. Примеры дорожек:

Данные BPMN – обозначают информационные объекты, которые используются при выполнении бизнес-процесса или являются результатами выполнения процесса. Примеры графических элементов «Данные»:

Ассоциация BPMN – позволяет отразить передачу объектов данных (информации, документов и т.д.) между задачами бизнес-процесса. Также применяется для обозначения связи события «Компенсация» с задачей «Компенсация» и для привязки текстовых аннотаций к элементам диаграммы. Ассоциация может иметь вид пунктирной линии или пунктирной стрелки. Не следует путать Ассоциацию (пунктирные линии или стрелки) с Потоком сообщений (штриховые стрелки), который используется на диаграммах «Взаимодействие».

Артефакты BPMN – служат для указания дополнительной информации и вставки примечаний на диаграммах. Примеры артефактов:

Пример диаграммы «Процесс»

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

Процесс начинается со стартового события «У клиента возникла проблема». Это событие запускает экземпляр бизнес-процесса BPMN при поступлении соответствующего запроса от клиента. Затем менеджер вручную выполняет действие «Получить описание проблемы». Для этого он задает клиенту уточняющие вопросы, чтобы получить максимально подробную информацию.

Далее менеджер по работе с клиентами принимает решение, может ли он решить возникшую проблему сам? Это принятие решения отражено на диаграмме при помощи эксклюзивного шлюза «Могу решить проблему сам?». Если менеджер может решить проблему сам, то он рассказывает клиенту решение проблемы (см. на диаграмме задачу «Объяснить решение») и процесс завершается. Если не может – то обращается с запросом в первую линию техподдержки (см. на диаграмме задачу «Спросить у 1 линии техподдержки»).

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

Классификация диаграмм «Процесс»

Диаграммы вида «Процесс» принято подразделять на «исполняемые» (executable) и «не исполняемые» (non-executable).

Исполняемые модели BPMN процессов создаются в специальных информационных системах, которые автоматически назначают пользователям задачи в соответствии с логикой смоделированного бизнес-процесса и обеспечивают контроль исполнения этих задач. Такие системы называются BPM-системы (Business Process Management System, BPMS).

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

Пример исполняемой модели процессов

Не исполняемые модели процессов BPMN – это все остальные модели, кроме исполняемых. Они создаются с разными целями, поэтому их многообразие велико. Наиболее популярные цели создания не исполняемых моделей:

Формализация, регламентация и стандартизация деятельности
Описание требований при разработке и настройке информационных систем
Оптимизация бизнес-процессов: моделирование логики рабочих процессов «как есть» и «как надо»
Оптимизация организационной структуры и ролевой структуры
Имитационное моделирование бизнес-процессов и прогнозирование прироста эффективности от оптимизации

Пример не исполняемой модели бизнес-процессов

Взаимодействие

Диаграмма «Взаимодействие» BPMN позволяет моделировать обмен данными и управляющими воздействиями между двумя или более бизнес-процессами. Для графического отображения такого взаимодействия используются потоки сообщений (message flow).

Графические элементы диаграммы «Взаимодействие»

Поскольку диаграммы «Взаимодействие» отображают взаимодействие бизнес-процессов BPMN, следовательно, они включают все графические элементы, характерные для диаграммы «Процесс». Дополнительно используются два графических элемента: «Пул» и «Поток сообщений».

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

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

Пример диаграммы «Взаимодействие»

На данной диаграмме смоделирован бизнес-процесс BPMN обработки инцидентов в некоторой организации. Запросы поступают от клиентов Менеджеру по работе с клиентами. Бизнес-процессы Клиента являются внешними по отношению к рассматриваемой организации, поэтому неизвестны и представлены на диаграмме в виде пустого пула – своеобразного «черного ящика».

Рассмотрим бизнес-процесс BPMN Менеджера по работе с клиентами. Процесс инициируется стартовым событием, которое срабатывает при поступлении сообщения от Клиента. Далее Менеджер выполняет задачу «Получить описание проблемы». При этом он «отправляет» в сторону Клиента уточняющие вопросы, а в ответ получает более детальное описание проблемы. Затем Менеджер принимает решение, может ли он самостоятельно справиться с проблемой клиента? Если да, то он объясняет решение Клиенту и процесс завершается.

Если нет, то Менеджер отправляет запрос на первую линию техподдержки и его процесс приостанавливается, пока не будет получен ответ. Это показано на диаграмме в виде промежуточного события-обработчика «Ответ получен» с типом «Сообщение». В момент получения ответа от первой линии техподдержки указанное событие срабатывает, Менеджер передает полученное решение Клиенту и процесс Менеджера завершается.

Перейдем к рассмотрению процесса Агента 1 линии техподдержки. Его процесс начинается в том случае, если поступил запрос от Менеджера по работе с клиентами. Тогда Агент 1 линии пытается решить поступивший вопрос и принимает решение, потребуется ли ему помощь Агента 2 линии техподдержки? Если нет, то решение проблемы сообщается Менеджеру и процесс завершается. Если да, то Агент 1 линии отправляет запрос на вторую линию техподдержки и процесс приостанавливается до получения ответа. После получения ответа решение сообщается Менеджеру и процесс Агента 1 линии завершается.

Процесс Агента 2 линии техподдержки похож на процесс Агента 1 линии техподдержки. Если Агенту 2 линии требуется помощь Разработчика ПО, то он обращается к нему. Если проблема по-прежнему не решена, то она включается в план разработки на будущее, Агент 2 линии сообщает об этом Агенту 1 линии техподдержки. Агент 1 линии передает эту информацию Менеджеру, а тот в свою очередь – Клиенту.

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

Классификация диаграмм «Взаимодействие»

Диаграммы вида «Взаимодействие» принято классифицировать на внутренние (internal) и внешние (external):

Внутренние диаграммы BPMN (internal) – содержат только бизнес-процессы, происходящие внутри одной конкретной организации.

Внешние диаграммы BPMN (external) – содержат взаимодействия с внешними участниками и их бизнес-процессами. Пример, приведенный в данной статье выше, является внешней диаграммой, потому что на ней показано взаимодействие сотрудников организации с внешним участником – Клиентом.

Хореография

Диаграмма «Хореография» описывает последовательность взаимодействий участников при выполнении бизнес-процессов BPMN. Такие диаграммы строят для того, чтобы еще более наглядно показать взаимодействия между бизнес-процессами BPMN и их участниками. В данном руководстве диаграммам хореографии посвящен отдельный раздел.

Графические элементы диаграммы «Хореография»

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

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

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

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

Пример диаграммы “Хореография”

На диаграмме ниже изображена хореография процесса обработки инцидентов в некоторой организации. В соответствующих разделах Вы можете посмотреть диаграммы «Взаимодействие» и «Диалог» для этого же процесса.

Весь процесс инициируется первым взаимодействием «У клиента возникла проблема». В этом случае информация передается только в одну сторону. На диаграмме взаимодействия данной задаче хореографии соответствует одноименное стартовое событие бизнес-процесса.

Задача хореографии BPMN «Получить описание проблемы» соответствует одноименной задаче на диаграмме «Взаимодействие». В ходе выполнения этой задачи информация передается между Клиентом и Менеджером по работе с клиентами в обе стороны. Об этом говорит наличие как инициирующего сообщения, так и сообщения-ответа.

Далее следует эксклюзивный шлюз «Могу решить проблему сам?», в соответствии с которым Менеджер по работе с клиентами принимает решение: обращаться ли в техподдержку за помощью в решении проблемы. Если возможно самостоятельное решение (вариант «да»), то инициируется взаимодействие «Объяснить решение» и процесс завершается. Если требуется обратиться в техподдержку (вариант «нет»), то активируется диалог Менеджера с Агентом 1 линии техподдержки.

Аналогично можно проследить и дальнейшую логику хореографии процесса. Обратите внимание: диаграмма скомпонована так, что хорошо видна попарная работа задач хореографии в связках «запрос – ответ на запрос».

Практический совет

Попарно компонуйте задачи хореографии в связках «запрос – ответ на запрос»

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

Практический совет

Используйте для каждого участника одно постоянное положение во всех задачах хореографии – сверху или снизу

Посмотрите на пример ниже. Взаимодействуют два участника, причем, на каждом шаге инициатор меняется. Мы расположили во всех задачах хореографии Участника 1 сверху, а Участника 2 – снизу. Таким образом, последовательность взаимодействий каждого участника легко прочитывается слева направо.

Диалог

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

Графические элементы диаграммы «Диалог»

Информационное взаимодействие (Диалог) BPMN– это графический элемент, обозначающий цепочку логически взаимосвязанных обменов сообщениями. Изображается в виде шестиугольника с наименованием. Детализированные взаимодействия дополнительно обозначаются символом «+».

Вызов диалога BPMN предназначен для вызова глобальной (стандартной, многократно используемой) цепочки логически взаимосвязанных обменов сообщениями. Изображается также, как и элемент «Диалог», но жирными линиями.

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

Пример диаграммы «Диалог»

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

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

Еще один пример диаграммы «Диалог»

Для лучшего понимания диаграммы «Диалог» рассмотрим еще один пример. Ниже представлена диаграмма взаимодействия BPMN Пациента и Клиники, состоящая из процесса Пациента и процесса Клиники. В ходе взаимодействия Пациент записывается на прием к врачу Клиники, доктор выполняет прием, выписывает рецепт на лекарства, а затем Пациент забирает эти лекарства по рецепту.

Диаграмма «Диалог» для данного примера выглядит следующим образом:

Вся логическая цепочка взаимодействий между Пациентом и Клиникой «свернулась» в одно информационное взаимодействие (в один диалог) «Осуществление приема в клинике».

Оркестровка

Для отображения исполнителей (субъектов) процесса BPMN используются элементы: пул и дорожка. Чтобы понять суть оркестровки нужно сначала познакомиться с этими понятиями.

Дорожки и пулы BPMN

Дорожка BPMN– это графический элемент, который объединяет действия, выполняемые любым субъектом процесса: подразделением, сотрудником или ролью. Она именуется в соответствии с названием этого субъекта. Например, «Отдел продаж», «Логист», «Инициатор заявки», «Иванов Петр Сергеевич». Зачастую дорожка располагается внутри пула и её границы являются границами начала и окончания процесса.

Пул BPMN– это графический элемент, который показывает участника взаимодействия в процессе. Он может быть зоной ответственности отдельного исполнителя процесса или отображать действия сразу нескольких субъектов. В таком случае действия участников отображаются на отдельных дорожках внутри пула. Такой пул иногда называют «белый ящик». Но наличие процесса внутри пула – необязательное требование BPMN. Пустой пул (без процессов внутри) выполняет роль «черного ящика» на диаграмме процесса.

Принцип оркестровки

Оркестровка BPMN – это последовательность выполнения действий в рамках одного управляющего центра (пула). Оркестровка подразумевает, что процесс завершится только после выполнения всех его потоков управления.

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

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

Дополнительные операции по передаче объектов (результатов) задач между исполнителями являются излишними. Отображать их на диаграмме не имеет смысла.

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

Получилась достаточно сложная диаграмма. Такой подход не рекомендуется использовать при моделировании простых процессов, т.к он приводит к излишнему усложнению. Однако, эта диаграмма отображает основной принцип взаимодействия субъектов в BPMN. Несмотря на то, что дорожки BPMN похожи на дорожки других нотаций, они имеют особый смысл: они обозначают последовательность выполнения действий (поток управления) внутри процесса. Это и есть оркестровка.

Использование дорожек без пулов

При моделировании диаграмм можно использовать только дорожки, без пулов. В этом случае взаимодействие между субъектами обозначается с помощью потоков управления (оркестровки), как показано на первой диаграмме. Это самый простой подход, который можно использовать при изучении BPMN. Но он подходит для моделирования только очень простых процессов. Более сложные процессы обычно являются многопоточными, их рекомендуется моделировать с помощью диаграмм межпроцессного взаимодействия и хореографии.

Пулы

Обозначение пулов

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

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

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

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

Моделирование с использованием пулов BPMN

В статье «Взаимодействие процессов» был рассмотрен пример процесса «Заказ и доставка пиццы». Теперь давайте рассмотрим этот же процесс с точки зрения службы доставки пиццы. Как показано на рисунке ниже, он будет выглядеть следующим образом: служба доставки получает заказ от клиента, повар готовит пиццу, затем курьер доставляет её клиенту и получает деньги за заказ. После этого процесс успешно завершается.

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

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

Некоторые задачи при этом действительно взаимодействуют друг с другом. Например, «Выбрать пиццу» и «Заказать пиццу», а также «Доставить пиццу» и «Получить оплату». Эти пары действий выполняются одними и теми же субъектами, к тому же, действия в них следуют один за другим.

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

Кроме того, событие – «Пицца доставлена» должно быть связано с задачей «Доставить пиццу», а не только с задачами «Заказать пиццу» и «Позвонить в службу доставки», как это обозначено на диаграмме. Таким образом, данная диаграмме некорректно отображает взаимодействие службы доставки с клиентом и искажает реальный смысл процесса.

Чтобы отразить взаимодействие между клиентом и службой доставки нужно использовать два отдельных пула, как показано на рисунке ниже. Оба процесса (процесс Клиента и процесс Службы доставки) будут иметь такие же наборы задач, как и ранее, но теперь они взаимодействуют друг с другом с помощью потоков сообщений BPMN. Такая диаграмма называется диаграммой взаимодействия. Она показывает взаимодействие между двумя независимыми процессами.

На этой диаграмме есть потоки сообщений, которые не пересекают границы смежных пулов BPMN. Такие потоки сообщений не влияют на поток управления смежного пула. Например, действие «Позвонить в службу доставки» позволяет получить информацию о заказе, либо ускорить его обработку, но он никак не влияет на задачи «Приготовить пиццу», «Доставить пиццу» и «Получить оплату». Для того, чтобы выполнить действие «Получить оплату», в процессе клиента должна быть функция «Оплатить пиццу», т.к. действие «Съесть пиццу» может наступить только после того, как пицца оплачена.

На следующей диаграмме эта ошибка исправлена и поток сообщений напрямую присоединен к дополнительно созданной задаче «Оплатить пиццу».

Свернутый пул BPMN

Часто при моделировании взаимодействий между процессами с помощью пулов, нам не известны все детали этих процессов. Например, мы знаем процессы нашей собственной компании, но процессы компаний-партнеров нам не известны. До тех пор, пока взаимодействие между двумя процессами четко определено, оно работает без сбоев. В нашем примере «Заказ и доставка пиццы», как клиенты мы предполагаем, что служба доставки:

Примет заказ
Доставит пиццу и получит оплату
Готова принять претензию

Клиентов мало интересует внутренний процесс службы доставки. Возможно, она приготовит пиццу и затем доставит ее; возможно, она покупает пиццу в магазине и затем доставляет ее. Организация процесса службы доставки – это ее проблема. Цель клиента – получить пиццу. В таком случае, процессы службы доставки могут быть скрыты и отображены на диаграмме с помощью свернутого пула BPMN, как показано ниже.

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

Дорожки

Обозначение дорожек

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

Основные правила использования дорожек

Дорожки BPMN использовать не обязательно. Например, когда все операции процесса выполняет один исполнитель. Вообще, наличие дорожек на диаграмме – это не обязательное требование BPMN.
Дорожки BPMN можно декомпозировать. Это означает, что любая дорожка может включать в себя дочерние дорожки. Например, дорожка «Организация» может иметь дочерние дорожки – «Департаменты», а каждая дорожка «Департамент» может иметь дочерние дорожки «Отделы» и так далее.
Дорожки BPMN значимы только для операций. Дорожки обозначают исполнителей операций, которые на ней расположены. Остальные элементы нотации BPMN – события, шлюзы, объекты и т.д. – могут быть помещены на любую дорожку.
Дорожки BPMN могут быть как вертикальными, так и горизонтальными. Рекомендуется все же располагать дорожки BPMN горизонтально, и моделировать бизнес-процессы слева направо, поскольку так улучшается восприятие диаграммы и упрощается ее чтение.
Наименование исполнителя внутри дорожки BPMN может располагаться в любом месте и иметь любое направление (ориентацию) текста.

Примеры использования дорожек

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

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

Практический совет

Должна ли дорожка обозначать конкретного исполнителя – сотрудника или подразделение организации?

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

Конкретных сотрудников организации. Например, Бухгалтер.
Роли в организации, например, «Инициатор договора» или «Держатель бюджета».
Внешние по отношению к организации роли, например, «Клиент» или «Поставщик».
Отделы компании, например, «Отдел продаж» или «Бухгалтерия».
Коллегиальные органы компании, например, «Комитет по закупкам» или «Рабочая группа проекта».
Информационные системы или их модули, например, «CRM-система» или «Графическая подсистема».

Определенные сложности у начинающих бизнес-аналитиков вызывает вопрос, на какой дорожке разместить подпроцесс (т.е. «дочерний» процесс)? Действительно, диаграмма подпроцесса может содержать несколько дорожек, тогда на какой дорожке родительской диаграммы поместить этот процесс?

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

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

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

Часто задаваемые вопросы

Обязательно ли моделировать диаграммы BPMN по горизонтали? Что делать, если я предпочитаю моделировать их вертикально?

Вы можете моделировать диаграммы вертикально, стандарт BPMN разрешает это. Однако мы рекомендуем пользоваться горизонтальным расположением диаграммы. Опыт показывает, что люди склонны воспринимать лучше всего поток функций (действий), если он описан так же, как и письменный текст (слева направо).

Пример вертикального оформления диаграммы:

Действия

Действия (задачи, активности, работы) в BPMN

Основа любого бизнес-процесса BPMN – это последовательность действий. Каждое действие может быть элементарным (отдельная задача) или составным (подпроцесс).

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

Правила моделирования действий в BPMN

Действие может иметь любое количество входящих и исходящих потоков управления. Приведенные ниже изображения могут встречаться на диаграммах и не являются ошибками. Можно выделить три варианта:
- Множественные входы BPMN. В этом случае активация любого из входов приведет к выполнению действия. Рекомендуется с осторожностью использовать множественные входы, чтобы избежать дублирования выполнения действий.
- Множественные выходы BPMN. В этом случае после выполнения действия одновременно активируются все исходящие потоки управления. Это полный аналог параллельного шлюза, он описан в данной статье ниже.
- Множественные входы и выходы BPMN. В этом случае активация любого из входов приведет к выполнению действия, после которого будут одновременно активированы все исходящие потоки управления. Такая конфигурация сложна для чтения и применять ее нужно с осторожностью.
Действие, не имеющее ни одного входящего потока управления может быть изображено на диаграмме в виде подпроцесса. Такой подход часто используют при моделировании процессного ландшафта верхнеуровневой карты бизнес-процессов. Посмотрите на пример такой карты, спроектированной в соответствии с требованиями BPMN.
Каждый исходящий из действия поток управления создает новый маршрут процесса, параллельный остальным маршрутам. Другими словами, после выполнения действия с множественными выходами будут одновременно активированы все эти выходы. Механизм здесь работает в точности также, как и параллельный шлюз. Для удобства чтения диаграммы все же рекомендуется в таких случаях пользоваться параллельным шлюзом.
Действие, после которого не предполагается выполнение каких-либо дополнительных действий в процессе, является завершающим. После него обычно идет конечное событие.
Если на диаграмме используются пулы и / или дорожки, то каждое из имеющихся на диаграмме действий должно лежать в пределах какого-либо пула и / или дорожки. Следует избегать размещения действий на линиях, ограничивающих пулы и дорожки, так как это снижает удобство чтения диаграммы и может привести к неправильному пониманию процесса.

Типы задач

Что такое тип задачи в BPMN

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

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

Типы задач и примеры использования

Тип задачи BPMN определяет природу действия, которое будет выполнено. В BPMN существуют следующие типы задач:

	Задача без определенного типа называется абстрактной. Абстрактные задачи используют, когда тип задачи очевиден из контекста и его можно не указывать. Например, в бизнес-процессе, который выполняется полностью вручную, все задачи имеют тип «ручное выполнение» и это очевидно. Также абстрактные задачи используют для первичного «чернового» моделирования логики бизнес-процесса.
	Задача «Получение сообщения» ожидает поступление сообщения от другого участника или процесса. Задача считается выполненной, если сообщение получено хотя бы один раз. Такая задача приостанавливает выполнение процесса до тех пор, пока не будет получено сообщение. Альтернативой данной задаче является промежуточное событие-обработчик с типом «Сообщение»: Посмотрите примеры: следующие две схемы бизнес-процессов являются полностью идентичными: Пример 1: с задачей «Получение сообщения» Пример 2: с промежуточным событием-обработчиком «Сообщение»
	Суть задачи – отправка сообщения другому участнику или процессу. Задача считается выполненной сразу по факту отправки сообщения. Такая задача не приостанавливает выполнение процесса, и выполняется моментально. Альтернативной такой задаче является промежуточное событие-инициатор с типом «Сообщение»: Посмотрите примеры: следующие две схемы бизнес-процессов являются полностью идентичными: Пример 1: с задачей «Отправка сообщения» Пример 2: с промежуточным событием-инициатором «Сообщение»
	Данная задача запускает сценарий (т.е. последовательность действий) или программный код, который выполняется автоматически. «Задача-сценарий» всегда выполняется той информационной системой, которая управляет всем бизнес-процессом: запускает и завершает экземпляры процессов, назначает задачи пользователям и т.д. Это может быть корпоративный портал, BPM-система, система документооборота, система управления задачами или модуль исполняемых бизнес-процессов, встроенный в корпоративную информационную систему. Пример применения задач-сценариев:
	Сервисная задача выполняется автоматически (без участия человека) произвольной информационной системой, веб-сервисом, машиной или оборудованием. Сервисные задачи обычно применяют чтобы показать логику взаимодействия информационных систем с пользователем. Пример применения сервисных задач:
	Эта задача содержит правила и соответствующие им действия, которые должны быть выполнены при выполнении правила. Суть такой задачи похожа на «Задачу-сценарий», но есть отличия. «Задача-сценарий» содержит одно или несколько действий, причем их все необходимо выполнить для завершения задачи. «Бизнес-правило» содержит различные наборы действий, причем выполняется только тот набор, который соответствует определенному условию. Бизнес-правила используются, когда в бизнес-процесс нужно заложить сложную логику принятия решения или выполнения расчетов, или каких-либо действий. Пример применения бизнес-правил мы описываем в отдельной статье.
	Ручная задача выполняется человеком, без применения каких-либо автоматизированных решений и систем. Например: «Перенести груз из точки А в точку Б», «Визуально проверить отсутствие дефектов», «Налить стакан воды» и т.д. Пример применения ручных операций:
	Пользовательская задача выполняется человеком – пользователем произвольного сервиса, программного продукта (информационной системы), либо автоматизированного решения. При выполнении таких задач обычно требуется ввод данных, создание записей в информационных системах, выгрузка отчетов, манипуляции с объектами на экране и т.д. Пример применения пользовательских задач:

Маркеры задач

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

Маркер цикла BPMN

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

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

Многоэкземплярный маркер BPMN

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

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

Другим примером использования многоэкземплярного маркера BPMN может служить процесс заказа канцелярии сотрудниками одного офиса. Все сотрудники заказывают канцелярию одновременно. Затем офис-менеджер собирает все заказы и оплачивает счет. Если бы этот процесс был реализован по-другому, то заявка бы переходила от одного сотрудника к другому, пока каждый выберет себе канцелярию, что привело бы к удлинению этого процесса.

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

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

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

Пример 1 – Компенсация с циклом BPMN

Пример 2 – Компенсация с многоэкземплярным событием BPMN

В первом примере компенсация используется с маркером цикла BPMN. При необходимости отменить путешествие задача «Отменить поездку» выполняется пока исполнитель не дозвонится в турагентство и не отменит ее.

Во втором примере компенсация использована вместе с многоэкземплярным маркером BPMN. После рассылки приглашений по электронной почте необходимо позвонить последовательно всем адресатам, чтобы отменить приглашения.

Стрелки

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

Виды стрелок в BPMN

	Поток управления (поток операций) BPMN. Обозначает последовательность выполнения действий. Действие, присоединенное к окончанию стрелки выполняется непосредственно после действия, присоединенного к началу стрелки.
	Поток управления BPMN по умолчанию. Определяет ту ветвь бизнес-процесса, которая выполняется, когда все условия ветвления не выполнены. Может использоваться как совместно с эксклюзивным шлюзом, так и без него.
	Условный поток управления BPMN. Содержит условие, которое определяет, будет активирован данный поток или нет. Не может использоваться со шлюзами.
	Поток сообщений BPMN. Используется для обозначения передачи сообщение и объектов данных между пулами бизнес-процесса. Не может использоваться для передачи сообщений и объектов внутри одного пула.
	Стрелка-ассоциация BPMN (направленная ассоциация BPMN). Используется для обозначения передачи объектов данных между действиями бизнес-процесса внутри одного пула, а также для обозначения входов и выходов действий.

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

Правила использования стрелок в BPMN

Стрелки на диаграмме BPMN могут быть только горизонтальными или вертикальными. Наклонные стрелки запрещены. При необходимости линии стрелок изламывают под прямым углом.
Стрелки BPMN нельзя объединять или разветвлять.
Пересечение стрелок BPMN рекомендуется обозначать дугой.
Рекомендуется избегать большого количества пересечений стрелок BPMN, так как это ухудшает читабельность диаграммы. Советы по снижению количества пересечений:
- Предварительно продумайте размещение всех элементов на диаграмме, чтобы обеспечить минимум пересечений;
- «Убирайте» большие сложные цепочки действий в подпроцессы;
- Объединяйте объекты данных в комплекты объектов.

Контролируемый и неконтролируемый потоки управления

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

Контролируемый поток управления BPMN

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

Неконтролируемый поток управления BPMN

Неконтролируемый поток управления BPMN – это поток управления, не зависящий от событий и не проходящий через шлюзы. Неконтролируемый поток управления может соединять два или более действий, причем, действия могут иметь один или несколько входящих (исходящих) потоков. Рассмотрим три типовые ситуации:

Последовательный поток управления BPMN

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

Передача управления от одного действия к другому происходит моментально, паузы между действиями нет. В нашем случае Действие 2 начинается сразу после завершения выполнения Действия 1.

Неуправляемое ветвление BPMN

Неуправляемое ветвление порождает два параллельных потока управления BPMN. Механизм ветвления здесь работает точно также, как при использовании параллельного шлюза. В нашем примере это означает, что выполнение Действия 2 и Действия 3 начнётся одновременно, сразу после завершения выполнения Действия 1.

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

Неуправляемое слияние BPMN

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

В нашем примере, если Действие 1 и Действие 2 завершатся в разное время, то Действие 3 (и все последующие за ним действия!) будут выполнены дважды. Также стоит отметить, что неуправляемое слияние снижает «читабельность» диаграммы и может приводить к неоднозначному толкованию процесса. Вместо неуправляемого слияния рекомендуется использовать эксклюзивный шлюз:

Условный поток управления

Обозначение условных потоков

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

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

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

Варианты использования условных потоков

В качестве примера рассмотрим фрагмент диаграммы бизнес-процесса BPMN согласования договора. Суть в том, что договоры с ценой от 1 до 5 млн должны согласовываться по обычной схеме согласования, больше 5 млн – по усиленной схеме и меньше 1 млн – по упрощенной схеме.

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

Теперь отметим стрелку «От 1 до 5 млн» как поток по умолчанию. Это означает, что данный поток управления активируется, только если другие потоки не сработали. Следовательно, данную стрелку можно не подписывать.

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

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

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

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

Потоки сообщений и ассоциации

Обозначение потоков сообщений и ассоциаций

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

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

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

Использование потоков сообщений

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

Использование ассоциаций

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

Обратите внимание, что стрелками-ассоциациями показано движение объектов данных BPMN в процессе выдачи пропуска. Объект «Скан-копия паспорта» показан в виде графического элемента «Объект данных», к которому привязаны стрелки-ассоциации. В свою очередь, информация «Номер пропуска и паспортные данные» изображена в виде подписи над стрелкой-ассоциацией. Оба этих способа изображения потоков данных BPMN допускаются нотацией BPMN и применяются на усмотрение аналитика.

Подпроцессы

Суть подпроцессов

Подпроцесс BPMN – это действие, которое может включать в себя: другие действия, шлюзы, события и потоки операций. Необходимо отличать подпроцесс от процесса в BPMN:

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

BPMN не определяет какой уровень детализации должны иметь диаграммы. Каждый процесс или подпроцесс может содержать неограниченное количество задач и других подпроцессов. Бизнес-аналитик сам определяет уровень детализации в зависимости от целей моделирования.

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

Обозначение и моделирование подпроцессов

Подпроцесс BPMN, также как и задача, изображается в виде прямоугольника с закругленными углами. Единственное отличие – знак «плюс» в нижней части прямоугольника, который указывает на свернутую последовательность действий внутри подпроцесса. Такой подпроцесс называется свернутым.

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

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

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

Выполнение подпроцессов

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

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

Событийный подпроцесс

Определение и обозначение событийного подпроцесса

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

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

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

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

Пример использования событийного подпроцесса

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

На ужин были приглашены несколько друзей. В подпроцессе «Приготовление ужина» необходимо выбрать блюда и приготовить их. Пока готовится ужин позвонил друг, который тоже хочет прийти в гости. Это событие не прерывает приготовление ужина, и друг включается в список гостей. Внезапно во время приготовления еды блюдо было испорчено. Возникает событие «Блюдо испорчено», которое прерывает процесс приготовления ужина и запускает подпроцесс «Заказ еды». После того, как еда заказана родительский процесс «Приготовление ужина» завершается и переходит к следующей задаче «Съесть ужин».

Подпроцесс Транзакция

Определение и обозначение подпроцесса “Транзакция”

Транзакция BPMN – это подпроцесс, для которого может быть задано несколько вариантов выхода:

1. Успешное завершение – изображается в виде потока операций, выходящего из транзакции.
2. Отмена – изображается с помощью граничного события «Отмена». Это событие может быть использовано только c подпроцессом «Транзакция» BPMN. При возникновении события «Отмена» произойдет компенсация («откат назад») определенных действия транзакции, либо возврат к началу процесса.
3. Ошибка – изображается с помощью граничного события «Ошибка». Появление ошибки означает, что действия Транзакции BPMN выполняются неверно и становятся невозможными успешное завершение и отмена Транзакции. Выполнение Транзакции при этом завершается без компенсации, а поток операций родительского процесса продолжается от граничного события «Ошибка».

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

Успешное завершение Транзакции отличается от завершения обычного подпроцесса. Когда все действия Транзакции завершаются конечными событиями (кроме отмены, либо ошибки) моментального возврата к потоку операций родительского процесса не происходит. Протокол транзакции сначала проверяет состояние всех участников, завершивших Транзакцию. Если обнаруживается, что хотя бы один из них имеет проблемы при завершении действий, то транзакция активирует событие «Ошибки» или «Отмены». При этом поток операций родительского процесса направляется к соответствующему событию Транзакции.

Пример подпроцесса “Транзакция”

На диаграмме ниже приведен пример подпроцесса «Транзакция» BPMN:

В качестве примера Транзакции приведен подпроцесс «Организация путешествия». Подпроцесс инициируется из родительского процесса и заключается в параллельном выполнении двух действий: бронирование авиабилета и бронирование отеля. При успешном выполнении обоих действий подпроцесс завершается успешно и родительский процесс переходит к задаче оплаты бронирования.

Если хотя бы одно из действий «Забронировать авиабилет» или «Забронировать отель» выполняется с ошибкой (например, ошибка системы бронирования на сайте), то подпроцесс «Транзакция» последовательно выполняет следующие действия:

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

Если на любом этапе бронирования потребовалась отмена бронирования (например, клиент пожелал отменить бронирование, то подпроцесс «Транзакция» BPMN последовательно выполняет следующие действия:

Инициирует все граничные события-компенсации и выполняет все задачи-компенсации. Это задачи «Отменить бронирование» и «Отправить уведомление об отмене брони».
Инициирует граничное прерывающее событие «Бронирования отменены». При этом родительский процесс продолжает выполнение через задачу «Отправить уведомление об отмене».

Использование граничных событий

Что такое граничное событие

К подпроцессам можно присоединять граничные события BPMN. Это позволяет смоделировать альтернативные варианты исполнения действий родительского процесса в зависимости от состояния дочернего подпроцесса.

Пример использования граничных событий

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

При наступлении событий типа «Сообщение» (как в рассмотренном примере), а также «Таймер», либо «Условие» подпроцесс прерывается родительским процессом, который реагирует на внешнее обстоятельство. Затем поток управления BPMN в родительском процессе запускается по альтернативной ветви.

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

Еще один пример использования граничных событий

Диаграмма процесса BPMN «Обработка заказа»:

Диаграмма подпроцесса BPMN «Закупка товара»:

Рассмотрим диаграмму подпроцесса «Закупка товара». Этот подпроцесс может завершиться событием-ошибкой «Товар недоступен», которое запускает в родительском процессе «Обработка заказа» действие «Проинформировать клиента» о том, что товара нет в наличии.

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

Стартовое событие-сигнал «Достигнут минимальный уровень запаса» получает сигнал о том, что достигнут минимальный уровень запаса товаров и необходимо закупить товар. Благодаря такому процессу, при невозможности закупить товар, он удаляется из каталога до того, как клиент его закажет. Событие-сообщение похоже на событие-сигнал, но здесь не применимо, так как оно отправляет информацию участникам процесса, находящимся за рамками одного пула, а здесь показана передача информации между элементами процесса в одном пуле (событие «Достигнут минимальный уровень запаса» и подпроцесс «Закупка товара» находятся в одном пуле).

Принцип построения диаграмм, показанный на рисунках выше, можно использовать при создании процессного ландшафта BPMN (карты процессов).

Использование граничного события эскалации

В BPMN 2.0 вместо события-ошибки предпочтительней использовать событие-эскалацию. На диаграмме ниже приведен пример использования граничного непрерывающего события-эскалации. Граничные непрерывающие события обозначаются кругом из двойной штриховой линии. Они запускают дополнительную ветвь родительского процесса, без прерывания подпроцесса. В нашем примере подпроцесс «Закупка товара» передает информацию о задержке доставки товара в родительский процесс «Обработка заказа». При этом подпроцесс «Закупка товара» продолжает выполнение, а в родительском процессе активируется дополнительная ветвь «Поздняя доставка товара»:

Диаграмма процесса BPMN «Обработка заказа»:

Диаграмма подпроцесса BPMN «Закупка товара»:

Действие Вызов

Что такое действие “Вызов”

Действие «Вызов» BPMN – это задача, которая вызывает глобальный процесс BPMN или глобальную задачу. Глобальный процесс или глобальная задача – это такой процесс или задача, которые вызываются из различных других процессов. В некоторых источниках можно встретить название «универсальный процесс» или «универсальная задача».

Например, глобальный процесс «Вход в систему» может использоваться в разных процессах, причем, вместо дублирования данный процесс моделируется один раз и затем вызывается там, где это необходимо. Глобальными задачами в BPMN 2.0 могут быть: пользовательская задача, ручная операция, задача-сценарий и выполнение бизнес-правила.

Чтобы отличать повторно используемый подпроцесс от встроенного, в BPMN 1.2 ему назначался специальный атрибут. В BPMN 2.0 повторно используемый подпроцесс теперь реализуется действием «Вызов», а любой подпроцесс является встроенным. При этом любой встроенный подпроцесс может быть определен как глобальный и вызван действием «Вызов» в любом другом процессе.

Обозначение действия “Вызов”

Действие «Вызов» BPMN изображается на диаграмме в виде прямоугольника с закругленными углами, но с границами выполненными жирной линией:

Если целью действия «Вызов» является обычный подпроцесс, то оно изображается на диаграмме, с маркером подпроцесса (знаком «+»):
Если целью действия «Вызов» является циклический подпроцесс, то оно содержит маркер соответствующего цикла. Например, вызов параллельного циклического подпроцесса выглядит так:

Сравнение с обычными подпроцессами

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

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

Глобальные подпроцессы BPMN могут использоваться в различных процессах многократно. На диаграмме ниже приведен пример подпроцесса «Закупка товара», который вызывается в процессах «Обработка заказа» и «Управление закупками». В первом случае, если клиент купил товар и его нет в наличии. Во втором – если достигнут минимальный уровень запаса товара. Другой пример на этом же рисунке – подпроцесс «Оплата заказа», который вызывается в процессах «Обработка заказа» и «Ремонт».

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

Передача данных в глобальные подпроцессы

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

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

Адрес
Дата поставки
Описание товаров или услуг
Сумма счета-фактуры
Ожидаемая дата оплаты

Владельцы всех процессов, в которых предусмотрено выставление счета-фактуры (процесс обработки заказов, процесс ремонта и т.д.), должны предоставить эти данные. Учет будет нуждаться в данных в стандартном формате.

Это показывает, что BPMN требует сопоставления данных между вызывающими процессами и глобальными подпроцессами BPMN (Вы заметили, как часто эти странные технические вопросы соответствуют организационным потребностям?) BPMN просто заставляет нас формализовать многие вопросы, которые кажутся очевидными, или которые остались без внимания в процессе проектирования. Формализация – это лучший шанс сохранить целостность сложных бизнес-процессов в быстро меняющихся условиях.

Спонтанный подпроцесс

Определение и обозначение спонтанного подпроцесса

Спонтанный (Ad-Hoc) подпроцесс BPMN – это группа действий, взаимоотношения между которыми не установлены. Исполнители сами определяют последовательность и количество повторений этих действий, а также могут игнорировать выполнение действий.

Как правило, действия внутри спонтанного подпроцесса BPMN не соединяются. Графически такой процесс обозначается маркером тильды, как показано на рисунке. Этот маркер доступен только для подпроцессов.

Применение спонтанного подпроцесса

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

Можно подумать, что спонтанный подпроцесс BPMN противоречит принципам моделирования, которые подразумевают контроль процесса на всех его стадиях. Однако, для моделирования некоторых процессов нужно применять именно спонтанный (Ad-Hoc) подпроцесс BPMN. Это нужно делать в следующих случаях:

Когда выполняемая процессом задача является творческой.
Творческие задачи нельзя решать в строгой последовательности. Успех решения таких задач зависит от способностей исполнителя, причем, каждый исполнитель будет использовать собственный подход (порядок действий) для достижения результата.
Когда последовательность выполнения действий в процессе безразлична.
Бывают такие процессы, в которых последовательность действий безразлична для достижения результата. В этом случае исполнитель определяет порядок выполнения процесса на свое усмотрение. Например, при уборке квартиры безразлично, в каком порядке мы будем мыть посуду, пылесосить пол и вытирать пыль. В любом случае после выполнения этих действий квартира будет убрана и процесс завершится. Это похоже на выполнение задач по чеклисту.
Когда нужно отразить фактическое состояние процесса.
Иногда возникает необходимость смоделировать еще не «устоявшийся» в компании процесс, по которому, например, еще отсутствует регламент и понятная последовательность действий. Известны только задачи. Для этой цели можно использовать спонтанный (Ad-Hoc) подпроцесс BPMN.

Требования к спонтанным подпроцессам

Существуют требования по использованию элементов BPMN 2.0 в спонтанных (Ad-Hoc) подпроцессах:

Обязательные элементы	Необязательные элементы	Запрещенные элементы
Действия	Объект данных Поток управления Ассоциация Группа Поток сообщений Шлюз Промежуточное событие	Начальное событие Конечное событие Действия хореографии

Пример спонтанного подпроцесса

Ниже приведен пример диаграммы спонтанного (Ad-Hoc) подпроцесса BPMN с использованием необязательных элементов. Эти элементы накладывают дополнительные ограничения на подпроцесс. Например, задача «Написать текст» может быть выполнена только после получения объекта данных «Найденная информация». Кроме того, задача «Опубликовать статью» будет выполнена только после редактирования ее текста.

Шлюзы

Определение и типы шлюзов

Шлюзы BPMN (или Логические операторы BPMN) используются для контроля слияния и ветвления потоков управления. Если контроль потока управления не нужен, то шлюзы можно не использовать. Принцип работы шлюза похож на пропускное устройство, которое позволяет пройти через него в определенных направлениях и при определенных условиях. На диаграмме процесса шлюз графически изображается в виде ромба. Тип шлюза определяется маркером, помещенным внутри ромба:

	Эксклюзивный шлюз BPMN (Логический оператор исключающего ИЛИ, управляемый данными) используется для разделения потоков управления на альтернативные маршруты. В зависимости от заданного условия может быть выбран только один маршрут. В случае объединения потоков управления эксклюзивный шлюз приостанавливает выполнение процесса и «ждет» активации первого потока управления из всех возможных, после чего срабатывает – пропускает поток управления дальше по процессу. Если после этого входной поток шлюза будет активирован еще раз, то задачи, находящиеся после эксклюзивного шлюза, будут выполнены повторно.
	Неэксклюзивный (включающий) шлюз BPMN (Логический оператор ИЛИ) используется для разделения потока управления на несколько альтернативных параллельных маршрутов. В зависимости от выбранного условия активируется один или несколько маршрутов. В случае объединения потоков управления неэксклюзивный шлюз «ждет» активации всех тех потоков управления, которые были запущены «разветвляющим» неэксклюзивным шлюзом. Такая согласованная работа пары неэксклюзивных шлюзов называется «динамическая синхронизация потока управления».
	Комплексный шлюз BPMN (Сложный логический оператор) позволяет моделировать сложные условия ветвления и слияния, которые невозможно смоделировать другими видами шлюзов. Данный шлюз не рекомендуется использовать на диаграммах, поскольку он имеет нечеткую семантику.
	Параллельный шлюз BPMN (Логический оператор И) разделяет поток управления на несколько параллельных потоков, которые активируются все одновременно. В случае объединения потоков управления параллельный шлюз «ждет» все входящие в него потоки, а затем активирует исходящий поток управления. Такая работа «объединяющего» параллельного шлюза называется «синхронизация потока управления».
	Эксклюзивный событийный шлю BPMN (Логический оператор исключающего ИЛИ, управляемый событиями) используется для выбора альтернативного маршрута процесса. Исходящие потоки управления данного шлюза должны быть связаны только с событиями или задачами – обработчиками сообщений. Поток управления направляется по той ветви, событие по которой наступит раньше других. Остальные события будут проигнорированы.
	Эксклюзивный событийный шлюз BPMN с созданием нового экземпляра (Оператор ИЛИ, событийный) используется для запуска новых экземпляров процесса при наступлении определенных событий. Исходящие потоки управления данного шлюза должны быть связаны только с событиями или задачами – обработчиками сообщений. Наступление каждого из последующих событий создает экземпляр процесса. Данный шлюз не может иметь входящих потоков управления.
	Параллельный событийный шлюз BPMN с созданием нового экземпляра (Оператор И, событийный) используется для запуска новых экземпляров процесса при наступлении определенного сочетания событий. Исходящие потоки управления данного шлюза должны быть связаны только с событиями или задачам – обработчиками сообщений. Наступление всех последующих событий создает один экземпляр процесса. Данный шлюз не может иметь входящих потоков управления.

Практические советы по использованию шлюзов

Практический совет

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

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

Практический совет

Шлюз обязательно должен осуществлять ветвление или слияние потоков управления.

Недопустимы ситуации, когда количество входящих и исходящих потоков равно 1 или больше 1.

Практический совет

При необходимости шлюзы можно соединять между собой в любом порядке: нет необходимости «искусственно» предусматривать между ними задачи или события.

Эксклюзивный шлюз

Определение и обозначение эксклюзивного шлюза

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

Графически эксклюзивный шлюз BPMN обозначается на диаграмме в виде ромба, который может содержать внутри маркер «Х». Мы рекомендуем изображать шлюз с маркером, т.к. благодаря ему шлюз легче заметить на диаграмме.

Пример использования эксклюзивного шлюза

На диаграмме ниже приведен пример использования эксклюзивного шлюза.

В этом примере условие задано вопросом «Какое блюдо выбрано?». В зависимости от ответа процесс может быть пройден по одному из трех альтернативных маршрутов. Второй эксклюзивный шлюз BPMN использован для объединения маршрутов в один. Независимо от того, какой из маршрутов будет пройден бизнес-процесс достигнет действия «Съесть еду».

Правила использования эксклюзивного шлюза BPMN

Практический совет

Перед шлюзом должна находиться задача, после которой необходимо принять определенное решение.

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

Практический совет

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

Ошибкой является отсутствие наименования у эксклюзивного шлюза BPMN (даже если кажется, что смысл шлюза очевиден), или неполное, неточное наименование.

Практический совет

К шлюзу должны присоединяться взаимоисключающие варианты решения.

Это означает, что варианты решения не должны совпадать или пересекаться. Рассмотрим пример. Ниже приведен фрагмент бизнес-процесса ранжирования компаний по размеру на «большие», «средние» и «малые», в зависимости от численности сотрудников. В этом примере невозможно точно определить, к какому типу отнести компанию с численностью 60 человек, поскольку варианты решения для малых и средних компаний пересекаются. Это явная ошибка.

Практический совет

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

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

Практический совет

Не допускается одновременное использование на диаграмме шлюзов с маркером и без него. Все эксклюзивные шлюзы должны изображаться одинаково.

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

Определение и обозначение параллельного шлюза

Параллельный шлюз BPMN используется для ветвления потока управления, то есть, создания параллельных маршрутов, либо для объединения маршрутов. При этом условие ветвления/слияния маршрутов задавать не нужно. Графически параллельный шлюз BPMN отображается с маркером «+» внутри ромба.

Пример использования параллельного шлюза

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

В этом процессе для каждого действия отображено время его выполнения. Общее время выполнения процесса составляет 48 минут если будет выбран борщ, либо 43 минуты если котлеты. Таким образом, минимальное время ожидания еды составляет 23 минуты. Очевидно, что цель этого процесса – получить салат и основное блюдо, чтобы как можно скорее удовлетворить чувство голода. Для сокращения времени на ожидание еды два действия в этом процессе можно выполнять параллельно: приготовление салата и основного блюда. Для этого на диаграмму процесса необходимо добавить параллельный шлюз BPMN, как показано ниже:

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

Синхронизация потоков управления BPMN

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

Вначале поток операций разделяется на два параллельных маршрута: приготовить борщ и приготовить салат. Как только задача «Приготовить салат» будет выполнена поток управления от нее пройдет через эксклюзивный шлюз и придет к задаче «Съесть еду». Через 5 минут после задачи «Приготовить борщ» поток управления от нее снова пройдет через шлюз и придет в задачу «Съесть еду». Таким образом, задача «Съесть еду» будет выполнена дважды.

В этом случае мы создали множественный (двойной) поток управления, который может приводить к многократному исполнению одних и тех же задач. Здесь задача «Съесть еду» выполняется дважды, с задержкой в 5 минут. Поток управления рассинхронизировался.

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

Неэксклюзивный шлюз

Определение и обозначение неэксклюзивного шлюза

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

Пример использования неэксклюзивного шлюза

Пример использования неэксклюзивного шлюза BPMN приведен на диаграмме ниже:

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

Только салат
Только основное блюдо
Салат и основное блюдо

Динамическая синхронизация потоков управления BPMN

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

«Открывающий» (крайний левый) и «закрывающий» (крайний правый) неэксклюзивные шлюзы BPMN взаимодействуют друг с другом: «закрывающий» шлюз приостанавливает выполнение процесса до тех пор, когда будут выполнены все запущенные «открывающим» шлюзом потоки управления. Такое применение неэксклюзивного шлюза BPMN называется «динамическая синхронизация потоков управления».

Эксклюзивный событийный шлюз

Определение и обозначение эксклюзивного событийного шлюза

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

Графически событийный шлюз BPMN изображается в виде ромба с маркером – триггером составного промежуточного события – внутри:

Правила использования эксклюзивного событийного шлюза

Событийный шлюз BPMN должен содержать два или более исходящих потоков управления.
Потоки управления, исходящие от шлюза, не именуются.
С событийным шлюзом BPMN используются события с типом: “Сообщения”, “Сигнал”, “Таймер”, “Условие”, “Составное”. Они располагаются на исходящих от шлюза ветвях непосредственно после шлюза.
С событийным шлюзом BPMN запрещается использовать события с типом: “Ошибка”, “Отмена”, “Компенсация” и “Ссылка”.
Элементы (события или задачи), которые соединены исходящими потоками управления с событийным шлюзом BPMN являются частью конфигурации этого шлюза. Они не должны иметь дополнительных входящих потоков операций, исходящих от других элементов кроме этого шлюза.
Конфигурация шлюза задается любыми комбинациями событий или задач.
Если после шлюза идет событие с типом “Сообщение”, то после него нельзя использовать задачу с типом “Получение сообщения” и наоборот.

Пример использования эксклюзивного событийного шлюза

На рисунке ниже приведены примеры конфигураций событийного шлюза BPMN, заданных различными элементами BPMN:

Данные конфигурации описывают одинаковую ситуацию, но в первом случае использованы события, а во втором – событийные задачи. Обе диаграммы можно прочитать так: «процесс после событийного шлюза BPMN пойдет по тому пути, событие или событийная задача по которому наступит раньше». В приведенном примере возможно получение Сообщения 1, получение сообщения 2 и истечение интервала времени длительностью 3 дня. Процесс приостанавливается на событийном шлюзе BPMN и «ожидает» наступления любого события из перечисленных. Как только событие наступит, процесс продолжится дальше по соответствующему потоку.

Еще один пример использования эксклюзивного событийного шлюза

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

Эксклюзивный событийный шлюз с созданием нового экземпляра

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

Эксклюзивный событийный шлюз BPMN с созданием нового экземпляра (Оператор ИЛИ, событийный) используется для запуска новых экземпляров процесса при наступлении определенных событий. Исходящие потоки управления данного шлюза должны быть связаны только с событиями или задачами – обработчиками сообщений. Наступление каждого из последующих событий создает экземпляр процесса. Данный шлюз не может иметь входящих потоков управления.

Графически эксклюзивный событийный шлюз BPMN с созданием нового экземпляра изображается в виде ромба с маркером – триггером составного стартового события – внутри:

Пример использования эксклюзивного событийного шлюза с созданием нового экземпляра

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

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

Каждому из перечисленных случаев на диаграмме соответствует событие-обработчик с определенным типом: «Сообщение» – для случая когда получена заявка на обучение сотрудников, «Условие» – для случая когда уволился квалифицированный сотрудник и, наконец, «Таймер», который ожидает наступления второго рабочего дня сентября. Событийный оператор ИЛИ позволяет отследить наступление любого указанных выше событий и запустить очередной новый экземпляр бизнес-процесса организации обучения. Сколько раз произойдут события, столько новых экземпляров бизнес-процесса будет запущено.

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

Параллельный событийный шлюз с созданием нового экземпляра

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

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

Графически параллельный событийный шлюз BPMN с созданием нового экземпляра изображается в виде ромба с маркером – триггером параллельного составного стартового события – внутри:

Пример использования параллельного событийного шлюза с созданием нового экземпляра

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

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

Каждому из перечисленных условий на диаграмме соответствует событие-обработчик с определенным типом: «Сообщение» (Получен согласованный лист учета рабочего времени), «Условие» (Количество часов консультаций больше нуля) и, наконец, «Таймер», который отслеживает наступление 1 числа каждого месяца. Событийный оператор И позволяет отследить наступление этих трех и запустить очередной новый экземпляр бизнес-процесса выставления счетов. Сколько раз произойдут все три события, столько новых экземпляров бизнес-процесса будет запущено.

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

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

Комплексный шлюз

Определение и обозначение комплексного шлюза

Комплексный шлюз BPMN (Сложный логический оператор) позволяет моделировать сложные условия ветвления и слияния, которые невозможно смоделировать другими видами шлюзов. Данный шлюз не рекомендуется использовать на диаграммах, поскольку он имеет нечеткую семантику.

Графически комплексный шлюз BPMN изображается в виде ромба с маркером «звездочкой» внутри:

Пример использования комплексного шлюза

В качестве примера применения комплексного шлюза BPMN рассмотрим бизнес-процесс постройки и запуска метрополитена. Первой задачей процесса является проектирование метро. Затем параллельно запускается постройка станций, в нашем случае – три станции. Движение в метро можно открывать, когда построено хотя бы 2 станции, нет смысла ждать постройки всех станций. Это условие отражено на диаграмме комплексным шлюзом.

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

События

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

Классификация событий BPMN по местоположению в процессе

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

Классификация событий BPMN по характеру поведения

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

Граничные события BPMN

События могут быть граничными. Граничные события BPMN – это промежуточные события-обработчики, которые прикрепляются к контуру (к границе) действия на диаграмме процесса. Граничные события BPMN обрабатывают события, происходящие при выполнении действия или подпроцесса, к границе которого они прикреплены. Таким образом, они могут прерывать подпроцесс (граничные прерывающие события) или активировать дополнительный поток управления, который выполняется одновременно с выполнением подпроцесса (граничные не прерывающие события). Ниже приведен пример диаграммы с граничным прерывающим событием BPMN:

Если при выполнении задачи 1 возникает событие 1, то эта задача прерывается и поток операций направляется к задаче 3. Процесс продолжается по новой ветке. Если событие 1 не возникает, то после выполнения задачи 1, выполняется задача 2 и так далее.

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

Если при выполнении задачи 1 возникает событие 1, то эта задача не прерывается и поток операций процесса идет по двум маршрутам параллельно. Событие 1 может повторяться несколько раз, но только до момента завершения задачи 1. Если это событие не возникло, то процесс пойдет по стандартному маршруту – от задачи 1 к задаче 2 и т.д.

Сводная таблица событий BPMN 2.0

Сообщение

Определение и виды событий с типом “Сообщение”

Событие BPMN с типом «Сообщение» используется для генерации или обработки сообщений от других процессов либо субъектов. Графически оно обозначается кругом с триггером в виде конверта внутри. Сообщениями при этом могут быть не только письма, электронная почта или телефонные звонки. Сообщением может быть любой информационный или даже материальный объект. Ниже приведены все возможные виды событий BPMN с типом «Сообщение».

Пример использования событий с типом “Сообщение”

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

Практические советы

Практический совет

События с типом «Сообщение» можно заменять на задачи с типом «Сообщение» и наоборот.

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

В приведенном выше примере можно заменить задачу «Заказать пиццу» на событие-инициатор с типом «Сообщение».

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

Практический совет

События с типом «Сообщение» можно заменять на задачи с типом «Сообщение» и наоборот.

При наименовании процессов и задач необходимо придерживаться формулы: “глагол (указывает на выполняемую работу) плюс существительное (указывает на объект выполняемой работы)”. Например, «Выдать карту», «Оказать услугу», «Продать товар».

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

События относятся к тому, что уже произошло независимо от процесса или в результате процесса. Поэтому для наименования событий необходимо использовать формулу: “объект плюс глагол совершенного вида в прошедшем времени (отвечает на вопрос «что сделано?» или «что произошло?»)”. Например, «Поступила заявка», «Выполнено условие», «Истекло 15 минут».

В BPMN формально отсутствует требование, чтобы для каждой функции было смоделировано начальное и конечное событие, но каждый процесс должен каким-то событием начинаться и иметь определенный результат – конечное событие. Во-первых, таким образом можно определить событие, которое инициирует запуск процесса, а во-вторых, зафиксировать окончательный статус (результат) этого процесса.

Граничное событие BPMN с типом «Сообщение»

Рассмотрим пример использования граничного прерывающего события BPMN с типом «Сообщение» (см. диаграмму процесса ниже). При поступлении сообщения от пользователя о наличии ошибки на веб-сайте администратор выполняет поиск ошибки. Во время выполнения этой задачи пользователь может сообщить, что ошибка устранена им самостоятельно. Тогда задача по поиску ошибки прерывается и поток управления переходит к задаче «Предоставить информацию об ошибке». Однако, если ошибка обнаружена, администратор ее исправляет и одновременно выясняет по чьей вине она произошла. Если не по вине пользователя, то администратор сообщает ему, что ошибка устранена. Если по вине пользователя, то предоставляет информацию об ошибке.

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

Таймер

Определение и виды событий с типом “Таймер”

Событие BPMN с типом «Таймер» показывает ожидание процессом регулярного события, определенного момента времени или временного периода. На время ожидания текущий поток управления бизнес-процесса приостанавливается. Графически событие BPMN «Таймер» отображается в виде круга с триггером в виде часов внутри. Ниже приведены все возможные виды событий BPMN с типом «Таймер».

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

Примеры использования событий с типом “Таймер”

На диаграммах ниже показаны различные примеры использования событий BPMN с типом «Таймер»:

Граничное событие BPMN с типом «Таймер»

Событие BPMN с типом «Таймер» может быть граничным прерывающим и граничным не прерывающим. Граничное прерывающее событие используется когда нужно показать максимально допустимое время на выполнение задачи. Например, если пицца не выбрана в течение 30 минут, то задача «Выбрать пиццу» прерывается и поток управления направляется к задаче «Приготовить макароны».

Теперь рассмотрим пример граничного не прерывающего события BPMN с типом «Таймер». При выполнении задачи «Приготовить еду», событие «За 10 минут до завершения», не прерывая эту задачу, создает новый поток операций, идущий к задаче «Накрыть стол». Затем оба потока синхронизируются в одной точке и общий поток операций переходит к следующей задаче.

Эскалация

Определение и виды событий с типом “Эскалация”

Событие BPMN с типом «Эскалация» используется для безусловной передачи управления на уровень родительского бизнес-процесса относительно текущего, а также для обработки таких передач управления. Графически событие BPMN «Эскалация» отображается в виде круга с триггером стрелки, направленной вверх, внутри. Ниже приведены все возможные виды событий BPMN с типом «Эскалация».

Пример использования событий с типом “Эскалация”

Рассмотрим пример. На диаграмме показан развернутый подпроцесс «Формирование отчета». В этом подпроцессе, после выгрузки данных выполняется проверка, хватает ли их для построения отчета? Если да, то отчет сначала формируется, а потом отправляется заказчику. Если нет – то срабатывает завершающее событие BPMN с типом «Эскалация». Оно обрабатывается соответствующим граничным событием, и затем заказчик отчета уведомляется о невозможности создать отчет и процесс завершается.

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

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

Условие (условное событие)

Определение и виды условных событий

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

Пример использования условных событий

Рассмотрим пример процесса с использованием условных событий BPMN.

При выполнении условия «Возникло желание съесть пиццу» поток операций процесса переходит к задаче «Вынуть пиццу из холодильника», а затем «Разогреть духовку». Только при выполнении условия «Температура в духовке 180 градусов» начнет выполняться задача «Поместить пиццу в духовку». При выполнении условия «Пицца готова» поток операций перейдет к задаче «Съесть пиццу».

Граничное событие BPMN с типом «Условие»

Условное событие BPMN может применяться в качестве граничного. В следующем примере граничное прерывающее событие с типом «Условие» останавливает выполнение задачи по разгрузке грузовика, если на складе закончилось место и разгружать уже некуда. В этом случае выполнение разгрузки останавливается и грузовик отправляется на запасной склад.

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

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

Ссылка

Определение и виды событий с типом “Ссылка”

Событие BPMN «Ссылка» используется для связи потоков управления на разных частях или разных листах диаграммы процесса. Ссылка может быть только промежуточным событием-обработчиком или событием-инициатором. Графически такое событие отображается в виде круга с триггером в виде стрелки внутри. Ниже приведены все возможные виды событий BPMN с типом «Ссылка».

Пример использования событий с типом “Ссылка”

Теперь приведем пример использования события BPMN «Ссылка». События «Ссылки» заменяют часть потока управления в процессе. Событие-инициатор «Ссылка» – это точка завершения задачи 1, а событие-обработчик «Ссылка» – точка начала задачи 2. Оба события обозначены, как парные, буквой «А».

Событие BPMN «Ссылка» может быть полезно в следующих случаях:

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

Ошибка

Определение и виды событий с типом “Ошибка”

Событие BPMN с типом «Ошибка» используется для моделирования возможных ошибок при выполнении процесса, а также для отображения последовательности действий по устранению этих ошибок. Графически событие BPMN «Ошибка» отображается в виде круга с триггером молнии внутри. Ниже приведены все возможные виды событий BPMN с типом «Ошибка».

BPMN не приводит какой-либо классификации возможных ошибок. Бизнес-аналитик сам выбирает какая ошибка может возникнуть в проектируемом процессе. Событие «Ошибка» может быть стартовым, промежуточным и конечным.

Стартовое событие BPMN «Ошибка»

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

Рассмотрим пример. На диаграмме показан развернутый подпроцесс приготовления ужина, который состоит из двух шагов: «Купить продукты» и «Приготовить еду». Дополнительно здесь предусмотрен вариант, что делать, если продукты или готовое блюдо оказались испорчены – в этом случае нужно заказать еду в ресторане. Это реализовано с помощью событийного подпроцесса «Заказ еды», который прерывает родительский процесс «Приготовление ужина».

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

Промежуточное и конечное событие BPMN «Ошибка»

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

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

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

Отмена

Определение и виды событий с типом “Отмена”

Событие BPMN с типом «Отмена» используется только в подпроцессах “Транзакция” для инициирования и обработки отмены транзакций. Графически событие BPMN «Отмена» отображается в виде круга с триггером косого креста внутри. Ниже приведены все возможные виды событий с типом «Отмена».

Пример использования событий с типом “Отмена”

Рассмотрим пример. На диаграмме показан подпроцесс-транзакция «Покупка авиабилетов», который выполняется на сайте компании по продаже билетов. Этот подпроцесс может завершаться одним из трех завершающих событий, среди которых есть завершающее событие BPMN с типом «Отмена» – «Бронирование отменено». Это завершающее событие обрабатывается соответствующим граничным событием с таким же названием. В случае срабатывания данных событий пользователь покидает сайт по продаже авиабилетов, поскольку необходимость в них пропала.

Компенсация

Определение и виды событий с типом “Компенсация”

Событие BPMN «Компенсация» показывает начало выполнения компенсирующих действий (событие-обработчик) или инициирование компенсации в процессе (событие-инициатор). Сам термин «Компенсация» обозначает отмену одного или более действий процесса, предшествующих событию-компенсации. Графически такое событие обозначается кругом с триггером в виде двух треугольников, повернутых влево (как кнопка перемотки на проигрывателе). Ниже приведены все возможные виды событий BPMN с типом «Компенсация».

Необходимость использования события BPMN с типом «Компенсация» связана с тем, что иногда нужно отменить выполнение некоторых задач в процессе. Типичные примеры таких задач:

Бронирование билетов
Аренда автомобиля
Пополнение кредитной карты
Заключение договора с поставщиком услуг
…и так далее

Пример использования событий с типом “Компенсация”

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

Эта же ситуация может быть смоделирована с использованием события BPMN «Компенсация», как показано ниже:

Правила использования событий BPMN с типом «Компенсация»

Действия компенсации относятся к определенному действию в процессе, поэтому их лучше располагать в одном пуле, вместе с событием BPMN «Компенсация». Этим события «Компенсация» отличаются от событий «Сообщение», которые могут быть расположены, где угодно.
Событие BPMN «Компенсация» отличается от других граничных событий тем, что оно срабатывает только после успешного завершения действия, к которому оно прикреплено. Граничные события других типов могут возникнуть только пока действие остается активным и не завершено.
События BPMN «Компенсация» соединяются с задачами «Компенсация» с помощью связей-ассоциаций, а не потока операций. Такой тип связи подчеркивает, что компенсация выходит за рамки обычной последовательности действий в процессе. Выполнение компенсации является исключением в процессе.

Практический совет

Используйте событие «Компенсация»

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

Сигнал

Определение и виды событий с типом “Сигнал”

Событие BPMN «Сигнал» обозначает ожидание или отправку сигнала между процессами. Это событие похоже на событие с типом «Сообщение» по следующим признакам:

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

Основное отличие события BPMN «Сигнал» от события «Сообщение» в том, что сообщение направлено конкретному получателю (электронный адрес определенного получателя, звонок на конкретный номер и т.п.). В свою очередь, событие BPMN «Сигнал» не имеет конкретного получателя и направлено на рассылку неопределенному количеству получателей в процессе. Его может получить любой участник процесса и среагировать на него. Сигнал относительно не ориентирован.

Графически событие BPMN «Сигнал» отображается на диаграмме в виде круга с триггером в виде треугольника внутри. Ниже приведены все возможные виды событий с типом «Сигнал».

Пример использования событий с типом “Сигнал”

Рассмотрим пример на диаграмме ниже. Участник процесса увидел рекламу пиццы и купил ее. Реклама пиццы – это сигнал, направленный на неопределенное количество получателей. Затем возникло условное событие «Желание съесть пиццу» после чего участник процесса съедает пиццу. После того, как покупатель съел пиццу, он оставляет отзыв на сайте, где заказал пиццу. Процесс завершается событием «На сайте оставлен отзыв о пицце», которое также является сигналом для других пользователей этого сайта и для службы доставки пиццы об удовлетворенности клиента.

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

Составное

Определение и виды составных событий

Составное событие BPMN обрабатывает или генерирует одно из множества заранее заданных событий. В случае использования события-обработчика текущая ветка потока управления приостанавливается. Графически такое событие отображается в виде круга с триггером в виде пятиугольника внутри. Ниже приведены все возможные виды событий BPMN с типом «Составное».

Пример использования составного события

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

Практический совет

Не рекомендуется использовать Составные события BPMN при моделировании бизнес-процессов.

Моделируя составные события, нужно всегда помнить с какой целью вы их применяете. Они полезны при «грубом» описании бизнес-процессов, но становятся бесполезными при детальном описании, особенно, если целью является дальнейшая автоматизация. Использование отдельно нескольких событий делает процесс более полным и понятным. Поэтому мы не рекомендуем использовать составные события. Ниже приведен пример процесса, рассмотренного выше, но с использованием отдельных событий:

Параллельное составное

Определение и виды параллельных составных событий

Параллельное составное событие BPMN обрабатывает множество параллельных (то есть, происходящих совместно) событий. Оно было добавлено в BPMN 2.0 для дополнения составного события. Тогда как обычно составное событие имеет семантику «Исключающее ИЛИ», т.е. оно обрабатывает или генерирует одно из возможных событий, параллельное составное событие BPMN имеет семантику «И», т.е. оно обрабатывает все параллельные события.

В отличие от множественного события параллельное может быть только обработчиком. При использовании параллельного события поток операций в процессе приостанавливается до тех пор, пока не будут обработаны все параллельные события. Графически параллельное составное событие BPMN изображается в виде круга с символом «+» внутри. Ниже приведены все возможные вида событий с типом «Параллельное составное».

Пример использования параллельного составного события

Рассмотрим пример. Данный процесс начинается, когда выполнены одновременно два условия: наступило время 18:00 и все дела сделаны. В этом случае можно пойти домой и приготовить ужин.

Практический совет

Не рекомендуется использовать параллельные составные события BPMN при моделировании бизнес-процессов.

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

Останов

Определение и обозначение события с типом “Останов”

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

Пример использования события с типом “Останов”

Рассмотрим пример. Общее время выполнения процесса, изображенного на диаграмме – 55 минут. После выполнения задачи 1, задачи 2 и 3 выполняются одновременно. Выполнение задачи 2 занимает больше времени, чем выполнение задачи 3, поэтому она определяет время выполнения процесса. Поток операций процесса проходит через параллельный шлюз и разделяется на два параллельных маршрута. Первый маршрут остается в точке задачи 2 в течение 45 минут, второй – в точке задачи 3 в течение 30 минут. Таким образом, второй маршрут приходит в абстрактное завершающее событие Конец 2, на 15 минут раньше, чем первый маршрут приходит в абстрактное завершающее событие Конец 1. Поскольку доступных маршрутов процесса больше нет, процесс завершается через 55 минут.

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

В данном случае после выполнения задачи 3 срабатывает эксклюзивный шлюз, определяющий куда пойдет поток операций. Если выполнение задачи 2 уже не нужно, то процесс завершается на 15 минут раньше, без ожидания выполнения задачи 2. Если выполнение задачи 2 необходимо, то процесс выполняется в течение 55 минут, как было рассмотрено в примере выше.

Данные и артефакты

Назначение данных и артефактов

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

Данные

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

Артефакты

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

Данные на диаграммах BPMN

Определение и обозначение объектов данных

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

	Входные данные BPMN – это исходные информационные объекты, которые преобразуются при выполнении действия (задачи или подпроцесса) BPMN. Выходные данные BPMN – это информационные объекты, которые являются результатом выполнения действий BPMN.
	Объект данных BPMN – это информационный объект (документ, отчет, письмо и т.д.), который может обрабатываться или передаваться в ходе выполнения бизнес-процесса.
	Коллекция объектов данных BPMN – представляет собой группу объектов данных. Например, «Комплект отгрузочных документов» или «Пакет конструкторской документации».
	Хранилище данных BPMN – это специальный объект, который может использоваться бизнес-процессом для записи и / или извлечения данных. Например, это может быть база данных. Особенностью хранилища является то, что после окончания экземпляра процесса все данные сохраняются и могут быть использованы в других бизнес-процессах или экземплярах процессов.
	Инициирующее сообщение BPMN – позволяет явно указать сообщение, которое является первым в логической цепочке взаимодействий между процессами. Ответное сообщение BPMN – служит для явного указания сообщения, которое отправляется в ответ на инициирующее сообщение.

Примеры моделирования данных BPMN

Входные и выходные данные

Рассмотрим фрагмент бизнес-процесса поставки оборудования клиенту. В ходе бизнес-процесса выполняется подпроцесс «Заключить договор», «Сформировать счет на оплату» и «Сформировать товарную накладную». Для каждого из этих действий процесса указаны входные и выходные объекты данных. Обратите внимание на 2 момента:

Один и тот же объект может являться входом или выходом одновременно для нескольких действий бизнес-процесса;
Один и тот же объект может быть выходом для одного действия и входом для другого действия бизнес-процесса.

Обозначение передачи данных

На диаграмме ниже показан фрагмент бизнес-процесса подписания договора. Сначала договор подготавливается, затем исполнитель уведомляет контрагента о том, что договор готов, и в завершении подписывает договор. Как видно, объект данных BPMN «Договор» одновременно является выходом из задачи «Подготовить договор» и входом задачи «Подписать договор». Поэтому он прикреплен стрелками-ассоциациями к соответствующим задачам.

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

Коллекции объектов данных

Рассмотрим теперь фрагмент диаграммы BPMN, состоящий из одной задачи «Подготовить комплект проектных документов». В ходе выполнения этой задачи исполнитель получает из разных источников документы: Устав проекта, Бюджет проекта, План-график проекта, Приказ о старте проекта и объединяет их в единый комплект – «Комплект проектных документов». Здесь хорошо видно, из каких документов «составляется» итоговый комплект.

Хранилища данных

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

Обратите внимание на 2 способа изображения передачи данных в хранилище. «Скан-копия паспорта» показана в виде объекта данных BPMN, а «Номер пропуска» и «Паспортные данные» – в виде подписи к стрелке-ассоциации.

Инициирующие и ответные сообщения

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

Артефакты в BPMN

Назначение и виды артефактов

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

Ассоциация;
Группа;
Категория;
Текстовая аннотация.

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

Правила использования артефактов BPMN на диаграмме:

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

Ассоциация BPMN

Связь ассоциации BPMN используется для:

Для установления соответствия между текстовыми или графическими артефактами с элементами процесса;
Для отображения действия «Компенсация» на диаграмме.

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

Текстовая аннотация BPMN

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

Группа BPMN

Артефакт BPMN «Группа» используется для отображения группы элементов на диаграмме. Графически группа изображается в виде прямоугольника со скругленными углами, выполненного штрихпунктирной линией. Группа может пересекать границы пулов и дорожек. В примере ниже она показывает взаимосвязь между задачами двух разных процессов.

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

Категория BPMN

Категории используются для анализа выполнения действий процесса. Например, для анализа стоимости или времени выполнения. Для отображения категории на диаграмме используется артефакт BPMN «Группа». Название группы – это и есть категория. Одна и та же категория на диаграмме может быть использована в нескольких группах. Разработчик модели может использовать другие способы отображения категорий. Например, выделение цветом.

Практические примеры

О практических примерах

В этом разделе собраны примеры моделирования в нотации BPMN и практические советы по решению типовых задач, которые обычно вызывают сложности у новичков. Раздел постоянно пополняется новыми статьями. Если у Вы не нашли ответ на свой вопрос – свяжитесь с нами. Мы рассмотрим Вашу задачу и возможно выпустим отдельную статью, посвященную ее решению!

Содержание раздела

Бизнес-правила	Описано правильное использование бизнес-правил, рассмотрены типовые ошибки
Зависимые запросы	В статье рассматривается, как правильно моделировать бизнес-процессы, в которых может быть несколько одинаковых запросов и при этом нельзя допускать их дублирования.
Принцип четырех глаз	Данный принцип описывает правила моделирования бизнес-процессов согласования любых документов.
Ежемесячное выставление счетов	Решается задача моделирования бизнес-процесса, разные части которого должны происходить с разной частотой.
Запрос дополнительной информации	Описан типовой случай, когда для завершения задачи BPMN требуется получить (от другого человека или информационной системы) дополнительную информацию.
Обработка нескольких заказов	Рассматривается принцип «один ко многим», когда в рамках одного экземпляра процесса должно активироваться множество экземпляров подпроцессов.
Переназначение пользовательских задач	Дается ответ на вопросы: как динамически назначать исполнителей задач? Как проверять доступность исполнителя?
Двухэтапная эскалация	Частая проблема: как наиболее компактно смоделировать два этапа принятия решений, в зависимости от наступающих событий? Решение – в статье.
Правила хорошего тона	Здесь Вы найдете несколько универсальных рекомендаций, как сделать диаграммы BPMN более читабельными, комфортными для восприятия.

Бизнес-правила в BPMN

Постановка задачи

Предположим, мы хотим смоделировать процесс, в котором используются определенные бизнес-правила BPMN. Рассмотрим такую ситуацию на примере процесса «Выставление счета». Для того, чтобы выставить счет необходимо рассчитать скидку в зависимости от категории клиента и суммы его заказа.

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

Решение задачи

В этом примере наше внимание должно быть сфокусировано на потоке управления в процессе, который имеет две задачи: «Рассчитать скидку» и «Подготовить счет». Результат процесса – счет выставлен. Не имеет смысла отдельно моделировать расчет скидки с помощью диаграммы BPMN (см. пример ниже). Иначе для каждого правила, в том числе нового, необходимо будет моделировать все новые и новые задачи, т.е. наша диаграмма будет разрастаться. Также диаграмма будет каждый раз меняться при изменении правил. Поэтому необходимо различать процессы и бизнес-правила BPMN.

Бизнес-правила в BPMN не моделируются. Они обозначаются свернутым пулом, который соединен потоками объектов с задачей типа «Бизнес-правило». Само бизнес-правило описывается в произвольном формате: таблицей, формулами, программным кодом и т.д.

Неправильный способ решения

Неправильный способ описания бизнес-правила BPMN – в виде диаграммы BPMN:

Зависимые запросы

Постановка задачи

Предположим, что мы хотим смоделировать процесс BPMN, содержащий несколько одинаковых запросов, происходящих в ходе его выполнения. Рассмотрим простой пример процесса «Проверка кредитоспособности заемщика». В этом примере мы хотим исключить двойное проведение кредитной проверки по заемщику, если такая проверка была запущена ранее. Предположим, что мы выполняем проверку кредитоспособности заемщика и получили еще один запрос на проверку для того же заемщика. Эта задача может быть решена различными способами. Общим для всех моделируемых решений будет то, что перед проверкой кредитоспособности необходимо проверять ранее запущенные проверки, т.е. совпадающие (зависимые) запросы.

Решение с использованием события BPMN «Сигнал»

Событие «Сигнал» является одним из наиболее простых способов моделирования взаимодействия BPMN между различными запросами. Недостаток сигнала в том, что он не имеет определенного получателя, а распространяется на все множество получателей. Таким образом, поток операций в процессе будет приостановлен до тех пор, пока сигнал не будет обработан.

Решение с использованием события BPMN «Сообщение»

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

Решение с использования события BPMN «Таймер» и цикла

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

Принцип четырех глаз

Постановка задачи

Принцип четырех глаз – это правило, согласно которому моделируются процессы согласования BPMN. Например, когда для подписания юридического или финансово значимого документа или принятия решения требуется одобрение (или подпись) нескольких людей.

Пример

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

Данный сценарий может применяться для различных процессов:

Утверждение оплаты
Утверждение счета
Утверждение договора
И так далее

Решение задачи

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

Другие варианты решения задачи

Моделирование утверждающих в виде свернутых пулов BPMN

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

Определение утверждающих с помощью сервисной задачи BPMN

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

Ежемесячное выставление счетов

Постановка задачи

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

Рассмотрим структурирование диаграмм в BPMN на примере процесса «Юридическая консультация». Адвокат предлагает юридические консультации своим клиентам. Клиент при необходимости обращается за консультацией. Адвокат предоставляет нужную информацию и включает затраченные на консультацию часы в счет клиента. В конце каждого месяца бухгалтер адвоката подсчитывает количество часов и готовит счет-фактуру для оплаты клиентом.

Решение задачи

Самое важное в диаграмме – это ее структура. Процесс «Предоставление юридической консультации» выполняется несколько раз в месяц, а процесс «Выставление и оплата счета» – один раз в месяц. Поэтому эти процессы должны быть смоделированы в отдельных пулах. Однако, эти два пула взаимодействуют между собой с помощью базы данных – «Лист записи». В BPMN сложно моделировать потоки данных, т.к. он больше ориентирован на поток управления. Тем не менее, моделировать потоки данных можно с помощью баз данных, соединяющих процессы.

Неправильный способ моделирования

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

Запрос дополнительной информации после выполнения задачи

Постановка задачи

Предположим, что мы хотим смоделировать процесс BPMN, в котором после выполнения пользовательской задачи необходимо предоставление дополнительной информации от другого пользователя (решение 1), или от информационной системы (решение 2). Задачи выполняются с использованием системы назначения задач, например, корпоративного портала.

Решение 1: запрос информации от другого пользователя

Решение 2: запрос информации от информационной системы

Обработка нескольких заказов

Постановка задачи

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

Решение задачи

В этом примере показан общий принцип моделирования подобных сценариев. Иногда такой принцип называют «1 ко многим» (или «1-N»). Запуск одного заказа приводит к возникновению множества отдельных экземпляров подпроцесса в ERP-системе. Примером таких процессов могут быть многоэкземплярные или цикличные процессы BPMN, которые запускают другие процессы используя потоки сообщений.

Переназначение пользовательских задач

Постановка задачи

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

Решение 1: С использованием граничного прерывающего события с типом «Сообщение» и сервисной задачей

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

Решение 2: С использованием граничного прерывающего события с типом «Сообщение» и задачи «Бизнес-правило»

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

Решение 3: С использованием граничного прерывающего события с типом «Сообщение» и неявного переназначения

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

Двухэтапная эскалация

Постановка задачи

Рассмотрим моделирование двухэтапной эскалации в BPMN на примере процесса «Заказ пиццы». Предположим, мы заказали пиццу и ожидаем ее доставку. Если в течение 30 минут пицца не доставлена мы звоним в службу доставки. Затем мы опять ожидаем доставку пиццы. Если она не доставлена в течение 20 минут, то мы отменяем заказ. Ниже приведены возможные решения этого сценария.

Решение 1. Использование двух событийных шлюзов

Преимущества этого решения

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

Недостатки этого решения

Событийный шлюз – это сложный для визуального восприятия элемент BPMN. Нужен опыт, чтобы понять его значение. Кроме того, использование двух шлюзов приводит к дублированию события «Пицца доставлена», что делает диаграмму длиннее.

Решение 2. Использование задачи «Получение сообщения» и граничных событий

Преимущества этого решения

Это решение позволяет сделать диаграмму компактней. Использование граничного непрерывающего события-таймера «30 минут» делает процесс более гибким – мы можем звонить в службу доставки неограниченное количество раз до истечения 50-ти минут. Это решение является более универсальным по сравнению с первым.

Недостатки этого решения

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

Решение 3. Событийный шлюз с общим таймером

Преимущества этого решения

Это диаграмма представляет собой наиболее общее решение проблемы и является самой компактной. Она позволяет моделировать эскалации n-уровня без громоздких ветвлений на диаграмме.

Недостатки этого решения

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

Правила хорошего тона

Избегайте пересечения потоков операций на диаграммах

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

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

Хороший пример моделирования потоков

Плохой пример моделирования потоков

Наименование элементов в BPMN

Каждый элемент BPMN имеет свое обозначение и наименование. Событие необходимо именовать по формуле «существительное + глагол в прошедшем времени». Например, «сделка состоялась». Процесс (пул) должен содержать имя процесса или субъекта, который его выполняет. Например, «Корпоративный портал» или «Инициатор договора» или «Управление доставкой». Задачи желательно именовать по формуле «отглагольное существительное + наименование объекта, над которым совершается действие». Например, «Подготовка отчета» или «Отгрузка товара» или «Подписание договора». Эксклюзивные шлюзы нужно обозначать вопросами, а потоки операций от них – ответами (условиями).

Ниже приведены примеры, иллюстрирующие наименование элементов диаграммы.

Хороший пример наименования элементов на диаграмме

Формулы наименований элементов

Плохой пример наименования элементов на диаграмме

Симметричное моделирование

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

Пример 1: Приготовление ужина

Симметричное моделирование

Несимметричное моделирование

Пример 2: Выполнение заказа

Симметричное моделирование

Несимметричное моделирование

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

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

Диаграмма с одинаковыми размерами задач

Диаграмма с разными размерами задач

Хореография

Диаграмма хореографии

Диаграмма «Хореография» BPMN описывает последовательность взаимодействий участников при выполнении бизнес-процессов. Такие диаграммы строят для того, чтобы еще более наглядно показать взаимодействия между бизнес-процессами и их участниками. Для первоначального понимания хореографии рассмотрим простой пример.

Простая диаграмма хореографии

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

Данный бизнес-процесс описан четырьмя взаимодействиями хореографии.

Запрос доктору

Пациент является инициатором взаимодействия и отправляет в Клинику инициирующее сообщение «Мне требуется прием врача!». Ответное сообщение от Клиники – «Приходите на прием!». Таким образом, данное взаимодействие является двухсторонним, то есть, в ходе него происходит обмен сообщениями. Обратите внимание, что инициирующее сообщение и участник-инициатор имеют светлый фон, а ответное сообщение и отвечающий участник – имеют темный фон

Передача симптомов

Данное взаимодействие является односторонним. Это значит, что имеет место только передача инициирующего сообщения, а ответное сообщение отсутствует. Инициатором взаимодействия является Пациент: он передает доктору в Клинике симптомы своей болезни – «Я чувствую себя плохо…»

Передача рецепта

Данное взаимодействие также, как и предыдущее, является односторонним. Инициатор взаимодействия – Клиника. В ходе взаимодействия происходит отправка инициирующего сообщения «Возьмите Ваш рецепт!»

Передача медикаментов

Пациент является инициатором взаимодействия. Он предъявляет рецепт провизору в Клинике и таким образом транслирует ему инициирующее сообщение «Мне нужны мои лекарства». В ответ Пациент получает медикаменты. Это отражено на диаграмме в виде ответного сообщения «Вот Ваши лекарства!»

Для лучшего понимания хореографии здесь и далее мы приводим соответствующую диаграмму «Взаимодействие”

Практический совет

Инициирующее сообщение может отправлять только участник-инициатор, а ответное сообщение – может быть отправлено только в ответ на инициирующее сообщение!

На рисунке ниже показано, что нельзя прикреплять инициирующее сообщение к границе отвечающего участника и также нельзя прикреплять ответное сообщение к границе участника-инициатора.

Задачи хореографии

Определение и обозначение задач хореографии

Задачи хореографии BPMN предназначены для обозначения взаимодействий между двумя участниками бизнес-процессов (или между двумя бизнес-процессами). Они изображаются в виде графических объектов, которые состоят из нескольких элементов.

Задачи хореографии BPMN могут изображаться по-разному, в зависимости от характера описываемого взаимодействия. Возможно всего два варианта:

Передача сообщения (одностороннее взаимодействие, one-way collaboration)
Этот вид взаимодействия представляет собой передачу одного сообщения от инициатора ко второму участнику и изображается в виде задачи хореографии любым из приведенных ниже способов. Более предпочтительным является изображение с инициирующим сообщением, так как в этом случае можно указать название этого сообщения.

Соответствующая ситуация на диаграмме «Взаимодействие» может выглядеть по-разному. Ниже представлены два возможных примера: передача сообщения между свернутыми пулами и между задачами в разных пулах.
Обмен сообщениями (двухстороннее взаимодействие, two-way collaboration)
Этот вид взаимодействия представляет собой обмен сообщениями между инициатором и вторым участником, и изображается в виде задачи хореографии с инициирующим сообщением и ответным сообщением.
Соответствующая ситуация на диаграмме «Взаимодействие» может выглядеть по-разному. Ниже представлены три возможных примера обмена сообщениями: между двумя, тремя и четырьмя задачами.
Обмен сообщениями между двумя задачами
Обмен сообщениями между тремя задачами
Обмен сообщениями между четырьмя задачами
Практические советы

Изображение ответного сообщения без инициирующего сообщения является ошибкой!

Соблюдайте правильную последовательность задач хореографии!

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

Подпроцессы хореографии

Определение и обозначение подпроцессов хореографии

Подпроцесс хореографии BPMN – это составное действие хореографии, которое декомпозируется на поток из нескольких дочерних задач хореографии. Количество участников подпроцесса хореографии может быть от двух и более. Свернутый подпроцесс хореографии BPMN на диаграммах отмечается символом «+».

Свернутый подпроцесс хореографии

Развернутый подпроцесс хореографии и соответствующая ему диаграмма «Взаимодействие»

Практический совет

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

Маркеры задач и подпроцессов хореографии

Маркеры задач и подпроцессов хореографии служат для обозначения циклов и множественных экземпляров задач и подпроцессов. Рассмотрим применение маркеров подробнее на примере задач хореографии BPMN.

Циклическая задача

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

Многоэкземплярная задача (параллельные экземпляры)

Многоэкземплярная задача хореографии BPMN (параллельные экземпляры) и соответствующий ей фрагмент диаграммы «Взаимодействие». Обратите внимание, что обе соответствующие задачи – отправка и получение сообщений – должны быть многоэкземплярными.

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

Многоэкземплярная задача хореографии BPMN (последовательные экземпляры) и соответствующий ей фрагмент диаграммы «Взаимодействие». Обратите внимание, что обе соответствующие задачи – отправка и получение сообщений – должны быть многоэкземплярными.

Задача с множественными участниками

Задача хореографии BPMN с множественным участником и соответствующий ей фрагмент диаграммы «Взаимодействие». Обратите внимание, что на диаграмме взаимодействия пул множественного участника также должны быть обозначен как множественный.

Маркеры подпроцессов хореографии

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

Вызов хореографии

Определение вызова хореографии

Вызов хореографии BPMN предназначен для вызова глобальной (стандартной, многократно используемой) задачи или подпроцесса хореографии.

Обозначение вызова хореографии

Обозначается графическим символом задачи или подпроцесса в жирной рамке.

События хореографии

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

Использование стартовых событий на диаграммах хореографии

Тип стартового события	Можно ли использовать?	Комментарии
Абстрактное	Да	Используется для старта хореографии во всех случаях, когда процесс должен запуститься первым инициирующим сообщением. Также используется для старта подпроцессов хореографии.
Сообщение	Нет
Таймер	Да	Все участники должны иметь соглашение об одинаковом времени выполнения действий.
Эскалация	Нет
Ошибка	Нет
Компенсация	Нет
Условие	Да	Используется с обычной семантикой.
Сигнал	Да	Источник сигнала не требуется изображать. Все участники хореографии «видят» сигналы, т.к. сигнал не имеет конкретного получателя и этим отличается от сообщения.
Множественное	Да	Используется с обычной семантикой.

Использование стартовых событий на диаграммах хореографии

Тип стартового события	Можно ли использовать?	Комментарии
Абстрактное	Да	Используется с обычной семантикой, для обозначения определенной точки, достигнутой в процессе. Не может передавать сообщения.
Абстрактное (граничное)	Нет
Сообщение	Нет
Сообщение (граничное)	Да	Можно использовать только для задач хореографии (не для подпроцессов!) Сообщение прикрепляется к границе участника – получателя сообщений.
Сообщение (в событийном шлюзе)	Нет
Таймер	Да	При условии синхронизации времени между участниками хореографии.
Таймер (граничное)	Да	При условии синхронизации времени между участниками хореографии.
Таймер (в событийном шлюзе)	Да	При условии синхронизации времени между участниками хореографии.
Ошибка (граничное)	Нет
Эскалация	Нет
Эскалация (граничное)	Нет
Отмена	Нет
Отмена (граничное)	Да	Применяется только как прерывающее событие – обработчик. Событие должно быть прикреплено к границе того участника взаимодействия, который получает ошибку.
Компенсация	Нет
Компенсация (граничное)	Да	Применяется только как прерывающее событие – обработчик. Событие должно быть прикреплено к границе того участника взаимодействия, который инициирует компенсацию.
Условие	Да	Используется как задержка, которая ожидает изменения данных для того, чтобы событие сработало. Данные должны быть видны всем участникам и содержаться в одном из предыдущих сообщений.
Условие (граничное)	Да	Применяется только как прерывающее событие – обработчик.
Условие (в событийном шлюзе)	Да	Используется как задержка, которая ожидает изменения данных для того, чтобы событие сработало. Данные должны быть видны всем участникам и содержаться в одном из предыдущих сообщений.
Ссылка	Да	Используется с обычной семантикой.
Сигнал	Да	Используется только как событие-обработчик.
Сигнал (граничное)	Да	Используется только как событие-обработчик.
Сигнал (в событийном шлюзе)	Да	Используется только как событие-обработчик.
Множественное	Да	Используется с обычной семантикой.
Множественное (граничное)	Да	Используется с обычной семантикой.

Использование завершающих событий на диаграммах хореографии

Тип стартового события	Можно ли использовать?	Комментарии
Абстрактное	Да	Используется для завершения хореографии, то есть, обозначения той точки в процесс хореографии, после которой участники взаимодействия прекращают отправлять сообщения и ожидать получения каких-либо сообщений.
Сообщение	Нет
Ошибка	Нет
Эскалация	Нет
Отмена	Нет
Компенсация	Нет
Сигнал	Нет
Множественное	Нет
Останов (терминатор)	Да	Используется с обычной семантикой.

Шлюзы на диаграммах хореографии

Назначение шлюзов

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

Типы шлюзов

В таблице ниже представлены шлюзы BPMN, которые можно использовать на диаграммах хореографии.

	Эксклюзивный шлюз хореографии – используется для отображения принятия решений и выбора одной альтернативной последовательности задач хореографии на основании этого решения.
	Событийный шлюз хореографии – обозначает точку ветвления последовательности задач хореографии, в которой выбор альтернативного пути происходит в зависимости от того, какое событие из множества предопределенных наступит раньше.
	Неэксклюзивный шлюз хореографии – используется для отображения принятия решений и выбора одной или нескольких альтернативных последовательностей задач хореографии на основании этого решения.
	Параллельный шлюз хореографии – используется для ветвления последовательности хореографии на две или более последовательности, которые должны выполняться в одно и то же время.
	Комплексный шлюз хореографии – используется для моделирования «частичного слияния». Это означает, что комплексный шлюз срабатывает, когда какие-то, но не все предыдущие ветви процесса завершены.

Эксклюзивный шлюз хореографии

Назначение

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

Обозначение на диаграмме

Ниже приведен пример применения эксклюзивного шлюза и соответствующий фрагмент диаграммы «Взаимодействие».

Диаграмма хореографии

Диаграмма взаимодействия

Событийный шлюз хореографии

Назначение

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

Обозначение на диаграмме

Ниже приведен пример применения событийного шлюза и соответствующий фрагмент диаграммы «Взаимодействие».

Диаграмма хореографии

Диаграмма взаимодействия

Неэксклюзивный шлюз хореографии

Неэксклюзивный шлюз ветвления

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

Диаграмма хореографии

Диаграмма взаимодействия

Неэксклюзивный шлюз слияния

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

Диаграмма хореографии

Диаграмма взаимодействия

Параллельный шлюз хореографии

Назначение

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

Обозначение на диаграмме

Ниже приведен пример применения параллельного шлюза и соответствующий фрагмент диаграммы «Взаимодействие».

Диаграмма хореографии

Диаграмма взаимодействия

Комплексный шлюз хореографии

Назначение

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

Обозначение на диаграмме

Ниже приведен пример применения комплексного шлюза и соответствующий фрагмент диаграммы «Взаимодействие».

Диаграмма хореографии

Диаграмма взаимодействия

Комбинированные диаграммы хореографии

Назначение

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

Примеры

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

Эксклюзивный шлюз хореографии

Назначение

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

Обозначение на диаграмме

Ниже приведен пример применения эксклюзивного шлюза и соответствующий фрагмент диаграммы «Взаимодействие».

Диаграмма хореографии

Диаграмма взаимодействия

Введение в BPMN

Нотация BPMN

Нотация моделирования бизнес-процессов BPMN (Business Process Model and Notation) – это международный стандарт моделирования бизнес-процессов. Он является одним из важнейших компонентов для достижения согласованности между Бизнес-процессами и ИТ-системами.

Большинство современных компаний сегодня выбирают BPMN в качестве стандарта для моделирования своих процессов. Основные причины этого выбора:

Поддержка популярными программными продуктами для моделирования бизнес-процессов (Business Studio, ELMA, Bizagi и др.);
Оптимальный набор графических элементов, который позволяет детально описать любой процесс;
Возможность автоматизировать бизнес-процессы без необходимости программирования;
Уменьшение разрыва между моделями «Как есть» и «Как должно быть».

Как пользоваться данным руководством

Благодаря большому количеству примеров настоящее руководство по BPMN можно использовать как самоучитель для освоения нотации “с нуля”. Для этого рекомендуется читать все главы по порядку с самого начала. Также это руководство подходит в качестве справочника, в котором опытные специалисты могут найти ответ на вопрос, если что-то забыли.

Руководство по BPMN имеет следующие особенности:

Любую статью можно прокомментировать: задать вопрос или высказать пожелание по более подробному описанию отдельных моментов.

Все содержимое полностью соответствует последней версии спецификации нотации BPMN;

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

Диаграммы выполнены в едином стиле и в черно-белом цвете для удобства восприятия материала;

Мы постарались писать простым, понятным языком, чтобы любой специалист смог легко разобраться в теме;

Статьи

Простая диаграмма в BPMN

Пример диаграммы

Для первоначального понимания нотации BPMN рассмотрим простую диаграмму процесса:

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

Описание примера диаграммы BPMN

Стартовое событие (Возникло чувство голода)

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

Действие (Купить продукты, Приготовить еду, Съесть еду)

Действие – это основа любого процесса, так как для достижения заданного результата процесса всегда необходимо что-то делать. Иногда действия BPMN называют «задачами» или «работами» – это тоже верно.

В BPMN действие может быть элементарным или составным. Составные действия сами являются процессами, поскольку содержат вложенные действия и другие процессы – так работает принцип декомпозиции. В нашем примере можно было бы декомпозировать действие «Приготовить еду» на более мелкие задачи: подготовить посуду и ингредиенты, выполнить все действия по рецепту, проверить готовность еды, подать еду на стол. Посмотрите, мы как будто «разворачиваем» подпроцесс «Приготовить еду» и показываем последовательность его подзадач:

Промежуточное событие (Еда приготовлена)

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

Конечное событие (Чувство голода удовлетворено)

Конечное (или «завершающее») событие показывает результат, достигнутый в ходе выполнения процесса и является конечной точкой процесса. В BPMN есть несколько видов конечных событий, благодаря которым при завершении процесса можно, например, генерировать сообщения и сигналы, запускать другие процессы и т.д. Примеры завершающих событий:

Практический совет

Как именовать элементы BPMN?

При наименовании процессов и задач необходимо придерживаться формулы: “глагол (указывает на выполняемую работу) плюс существительное (указывает на объект выполняемой работы)”. Например, «Выдать карту», «Оказать услугу», «Продать товар».

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

События относятся к тому, что уже произошло независимо от процесса или в результате процесса. Поэтому для наименования событий необходимо использовать формулу: “объект плюс глагол совершенного вида в прошедшем времени (отвечает на вопрос «что сделано?» или «что произошло?»)”. Например, «Поступила заявка», «Выполнено условие», «Истекло 15 минут».

В BPMN формально отсутствует требование, чтобы для каждой функции было смоделировано начальное и конечное событие, но каждый процесс должен каким-то событием начинаться и иметь определенный результат – конечное событие. Во-первых, таким образом можно определить событие, которое инициирует запуск процесса, а во-вторых, зафиксировать окончательный статус (результат) этого процесса.

Часто задаваемые вопросы

Обязательно ли моделировать диаграммы BPMN по горизонтали?

Что делать, если я предпочитаю моделировать их вертикально?

Вы можете моделировать диаграммы вертикально, стандарт BPMN разрешает это. Однако мы рекомендуем пользоваться горизонтальным расположением диаграммы. Опыт показывает, что люди склонны воспринимать лучше всего поток функций (действий), если он описан так же, как и письменный текст (слева направо).

Пример вертикального оформления диаграммы:

Использование шлюзов в BPMN

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

Параллельный шлюз BPMN

Стартовое событие «Товар заказан» означает, что действия по продаже товара уже были выполнены. Параллельный шлюз после стартового события показывает, что далее параллельно выполняются два действия. Иными словами, поток управления разветвляется и запускает одновременно две разные задачи. Пока секретарь выбирает способ доставки товара (критерии выбора мы не определяем, это решается внутри подпроцесса), работник склада уже может упаковать товар.

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

Эксклюзивный шлюз BPMN

Задача секретаря «Выбрать способ доставки», за которой следует эксклюзивный шлюз «Способ доставки», является хорошим примером для разъяснения использования этого шлюза. Шлюз не выбирает решение, будет это отправка простой почтой, либо курьерской службой. Данное решение принимается ранее. Шлюз работает только как маршрутизатор, который срабатывает в зависимости от результата предыдущей задачи и выбирает альтернативный путь. Задача (действие) представляет собой фактическую единицу работы, тогда как шлюз только маршрутизирует потоки информации.

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

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

Неэксклюзивный шлюз BPMN

В нашем примере используется два неэксклюзивных шлюза BPMN. Первый – после задачи «Проверить необходимость дополнительной страховки» и второй – после задач «Выбрать страховку» и «Заполнить бланк отправления». Первый неэксклюзивный шлюз BPMN выполняет ветвление потока управления и называется «открывающим». При этом одна образующаяся ветка процесса выполняется всегда, а ветка «Требуется страховка» выполняется только если требуется дополнительная страховка. Второй неэксклюзивный шлюз BPMN выполняет слияние двух потоков управления и называется «закрывающим». Он будет ждать завершения задач по всем потокам, которые были запущены «открывающим» шлюзом. В нашем случае может быть два варианта:

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

Такая логика работы пары неэксклюзивных шлюзов BPMN – «открывающего» и «закрывающего» – называется «динамическая синхронизация потоков управления».

Практический совет

Обращайте внимание на пулы

Обратите внимание, что в нашем примере использован только один пул – «Розничный продавец оборудования» и разные дорожки для сотрудников, участвующих в процессе. Это говорит нам об отсутствии автоматического назначения задач сотрудникам в ходе выполнения процесса, однако, предполагается, что они общаются друг с другом каким-то образом. Благодаря этому общению обеспечивается логика и последовательность выполнения всех шагов.

Пул и ролевые дорожки BPMN

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

Взаимодействие процессов

Пример взаимодействия процессов

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

Два взаимодействующих между собой пула изображены здесь чтобы показать потоки объектов (сообщений, документов, товаров, денег) между участниками процесса. Такой вид диаграмм называется «диаграмма взаимодействия BPMN» и позволяет отразить взаимодействие между различными отделами, командами, отдельными сотрудниками или даже программными системами.

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

Стартовое событие BPMN

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

Эксклюзивный шлюз по событиям BPMN

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

пицца доставлена, как указано в промежуточном событии с типом «Получение сообщения» – «Пицца доставлена»,
пицца не доставлена в течение 60 минут (событие «Таймер»), в этом случае клиент звонит в службу доставки. Далее администратор обещает, что пицца будет доставлена в ближайшее время (действие «Успокоить клиента»), и клиенты снова ждут пиццу, снова спрашивая после следующих 60 минут и так далее.

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

Промежуточное событие BPMN с типом «Сообщение»

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

Официальная документация BPMN

Нотация BPMN

Нотация BPMN разработана компанией Business Process Management Initiative и в настоящее время поддерживается организацией Object Management Group (OMG), после слияния обеих организаций в 2005 году.

OMG регулярно актуализирует и обновляет спецификацию нотации BPMN. Последняя версия BPMN — 2.0 (2.0.2), предыдущая версия — 1.2.

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

Спецификации BPMN

Постеры BPMN

Простая диаграмма в BPMN

Пример диаграммы

Для первоначального понимания нотации BPMN рассмотрим простую диаграмму процесса:

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

Описание примера диаграммы BPMN

Стартовое событие (Возникло чувство голода)

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

Действие (Купить продукты, Приготовить еду, Съесть еду)

Действие – это основа любого процесса, так как для достижения заданного результата процесса всегда необходимо что-то делать. Иногда действия BPMN называют «задачами» или «работами» – это тоже верно.

В BPMN действие может быть элементарным или составным. Составные действия сами являются процессами, поскольку содержат вложенные действия и другие процессы – так работает принцип декомпозиции. В нашем примере можно было бы декомпозировать действие «Приготовить еду» на более мелкие задачи: подготовить посуду и ингредиенты, выполнить все действия по рецепту, проверить готовность еды, подать еду на стол. Посмотрите, мы как будто «разворачиваем» подпроцесс «Приготовить еду» и показываем последовательность его подзадач:

Промежуточное событие (Еда приготовлена)

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

Конечное событие (Чувство голода удовлетворено)

Конечное (или «завершающее») событие показывает результат, достигнутый в ходе выполнения процесса и является конечной точкой процесса. В BPMN есть несколько видов конечных событий, благодаря которым при завершении процесса можно, например, генерировать сообщения и сигналы, запускать другие процессы и т.д. Примеры завершающих событий:

Практический совет

Как именовать элементы BPMN?

При наименовании процессов и задач необходимо придерживаться формулы: “глагол (указывает на выполняемую работу) плюс существительное (указывает на объект выполняемой работы)”. Например, «Выдать карту», «Оказать услугу», «Продать товар».

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

События относятся к тому, что уже произошло независимо от процесса или в результате процесса. Поэтому для наименования событий необходимо использовать формулу: “объект плюс глагол совершенного вида в прошедшем времени (отвечает на вопрос «что сделано?» или «что произошло?»)”. Например, «Поступила заявка», «Выполнено условие», «Истекло 15 минут».

В BPMN формально отсутствует требование, чтобы для каждой функции было смоделировано начальное и конечное событие, но каждый процесс должен каким-то событием начинаться и иметь определенный результат – конечное событие. Во-первых, таким образом можно определить событие, которое инициирует запуск процесса, а во-вторых, зафиксировать окончательный статус (результат) этого процесса.

Часто задаваемые вопросы

Обязательно ли моделировать диаграммы BPMN по горизонтали?

Что делать, если я предпочитаю моделировать их вертикально?

Вы можете моделировать диаграммы вертикально, стандарт BPMN разрешает это. Однако мы рекомендуем пользоваться горизонтальным расположением диаграммы. Опыт показывает, что люди склонны воспринимать лучше всего поток функций (действий), если он описан так же, как и письменный текст (слева направо).

Пример вертикального оформления диаграммы:

Курсы

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

Форматы проведения курсов

Обучение может проходить в удобном для вас формате:

Очно – в вашем офисе или в нашем учебном классе.

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

Наши преподаватели

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

Индивидуальный подход

Мы всегда адаптируем программу обучения под потребности вашей организации. Это включает:

Разбор реальных задач и процессов вашей компании.
Использование выбранной вами платформы моделирования: Camunda Modeler, Business Studio, MS Visio, Storm BPMN, Bizagi или других.
Учет специфики выбранной платформы и разбор ее функциональности в ходе обучения.
Дату и время проведения курсов мы согласуем с вами индивидуально, чтобы обучение было максимально удобным для всех участников.

Почему выбирают наши курсы?

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

Свяжитесь с нами

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

Моделирование процессов

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

Зачем нужно моделирование процессов?

Услуга по моделированию процессов в BPMN подходит вам, если:

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

Источники исходных данных

Мы работаем с любыми источниками информации для моделирования процессов:

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

Наши специалисты

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

Почему выбирают нас?

Быстрое выполнение: предоставляем схемы процессов в короткие сроки.

Гибкость: работаем с любыми источниками данных.

Опытные аналитики: специалисты с практическим опытом в BPMN.

Свяжитесь с нами

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

Событийный шлюз хореографии

Назначение

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

Обозначение на диаграмме

Ниже приведен пример применения событийного шлюза и соответствующий фрагмент диаграммы «Взаимодействие».

Диаграмма хореографии

Диаграмма взаимодействия

Использование шлюзов в BPMN

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

Параллельный шлюз BPMN

Стартовое событие «Товар заказан» означает, что действия по продаже товара уже были выполнены. Параллельный шлюз после стартового события показывает, что далее параллельно выполняются два действия. Иными словами, поток управления разветвляется и запускает одновременно две разные задачи. Пока секретарь выбирает способ доставки товара (критерии выбора мы не определяем, это решается внутри подпроцесса), работник склада уже может упаковать товар.

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

Эксклюзивный шлюз BPMN

Задача секретаря «Выбрать способ доставки», за которой следует эксклюзивный шлюз «Способ доставки», является хорошим примером для разъяснения использования этого шлюза. Шлюз не выбирает решение, будет это отправка простой почтой, либо курьерской службой. Данное решение принимается ранее. Шлюз работает только как маршрутизатор, который срабатывает в зависимости от результата предыдущей задачи и выбирает альтернативный путь. Задача (действие) представляет собой фактическую единицу работы, тогда как шлюз только маршрутизирует потоки информации.

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

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

Неэксклюзивный шлюз BPMN

В нашем примере используется два неэксклюзивных шлюза BPMN. Первый – после задачи «Проверить необходимость дополнительной страховки» и второй – после задач «Выбрать страховку» и «Заполнить бланк отправления». Первый неэксклюзивный шлюз BPMN выполняет ветвление потока управления и называется «открывающим». При этом одна образующаяся ветка процесса выполняется всегда, а ветка «Требуется страховка» выполняется только если требуется дополнительная страховка. Второй неэксклюзивный шлюз BPMN выполняет слияние двух потоков управления и называется «закрывающим». Он будет ждать завершения задач по всем потокам, которые были запущены «открывающим» шлюзом. В нашем случае может быть два варианта:

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