Графическая нотация для моделирования бизнес процессов bpmn отображает

Введение

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

Главное назначение и практическое применение

Нотация BPMN (Business Process Modeling Notation) нужна для подробного описания логики выполнения бизнес-процесса, в том числе для отражения деталей процессов, таких как: события, исполнители каждого из действий, используемые и создаваемые документы и другие объекты, использующиеся в качестве входных данных для тех или иных действий или создающиеся в результате их выполнения.

BPMN позволяет описать бизнес-логику выполнения действий в виде наглядной диаграммы, а также запустить отрисованный бизнес-процесс на исполнение. Для этого используются специализированные системы BPMS (Business Process Management System), поддерживающие эту нотацию.

BPMS-системы могут автоматически перевести схему бизнес-процесса в исполняемый код и создать веб-приложение, которое будет обрабатывать данные, введённые пользователями и сторонними сервисами. Это соответствует концепции Low Code/No Code (создание программного обеспечения без разработки кода) и отлично подходит для автоматизации офисных процессов.

Технически такая возможность реализуется за счёт перевода BPMN-диаграмм в документы формата BPEL (Business Process Execution Language). BPEL-документы представляют собой инструкции исполнения бизнес-процессов для веб-сервисов.

Таким образом, BPMN используется в следующих случаях:

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

2. Когда требуется запустить схему бизнес-процесса на исполнение в BPMS-системах

Краткая история появления нотации

BPMN считается довольно молодой нотацией: её 1-я версия вышла в 2009 году под эгидой профессионального консорциума OMG. Сегодня эта нотация является стандартом де-факто в ИТ-сфере и используется для описания бизнес-процессов. Текущая версия BPMN 2.0 вышла в 2011 году и используется до сих пор. В 2014 году в дополнение к BPMN группа OMG выпустила нотацию описания бизнес-правил и принятия решений (Decision Model and Notation, DMN).

DMN упрощает построение BPMN-диаграмм в случаях сложной бизнес-логики и многоуровневых её ветвлениях.

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

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

Уровни моделирования

В зависимости от целей построения BPMN-диаграмм, различают 3 уровня моделирования:

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

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

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

Алфавит нотации

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

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

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

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

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

События

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

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

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

Поток управления

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

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

Процесс утреннего пробуждения

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

После выполнения действия оператор включающего ИЛИ (OR) пропускает поток на действие «Выпить кофе» или на действие «Узнать новости» или по обоим веткам. Исключения здесь нет, ручеёк потока управления распараллеливается на две ветки, чтобы потом объединиться снова в одну и один раз выполнить действие «приготовиться к делам». После выполнения этого действия процесс заканчивается конечным событием.

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

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

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

Процесс утоления голода

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

Стартовым событием является простое событие «Возникло чувство голода» на дорожке Ребёнок, а конечным — простое событие «Чувство голода удовлетворено» на этой же самой дорожке.

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

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

Типы событий

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

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

Также некоторые события могут быть прерывающими и не прерывающими.

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

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

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

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

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

Типы действий

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

• Выполняемые вручную без использования какого-либо ПО, например, съесть пиццу.

• Выполняемые пользователем с помощью ПО, к примеру, заказать пиццу.

• Выполняемые скриптом или сервисом, например, изменить статус заказа пиццы.

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

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

Логические операторы

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

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

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

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

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

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

Следующий рисунок показывает использование эксклюзивного шлюза по событиям, который запускает движение потока только по той ветке, где событие произойдёт раньше. Например, получено согласие от клиента ИЛИ прошло 5 дней (без новостей от клиента).

Все остальные шлюзы, которые есть в BPMN, приведены в Приложении В.

Артефакты

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

Вы можете найти полный перечень артефактов в Приложении Г.

Правила построения диаграмм

Рассмотрим пример бизнес-процесса обработки заявки:

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

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

После действия «Направить клиенту коммерческое предложение (КП)» на диаграмме используется логический оператор ИЛИ (событийный XOR), после которого возможен один из двух вариантов:

1. Если прошло 5 дней, что показано событием с триггером таймер, и ответа от клиента нет, заявке присваивается статус «Отказ» в CRM-системе и наступает финишное событие «Заявка закрыта».

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

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

В результате этой задачи создаётся документ «Проект договора» и наступает финишное событие «Заявка успешно обработана».

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

Если в диаграмме используются операторы обычного XOR, проверяющего условия по данным, и OR (неисключающего ИЛИ) рекомендуется помечать поток по умолчанию, который активируется, если другие условия не сработали. Поток по умолчанию допустимо не подписывать, если подписаны остальные потоки и диаграмма остаётся понятной. В примере ниже «‎Нецелевой» — поток по умолчанию.

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

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

Задачи и события

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

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

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

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

Рекомендации по использованию BPMN

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

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

• Использовать только пользовательские и ручные задачи — без сценариев, сервисов и бизнес-правил, отправки и получения сообщений.

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

• Использовать только XOR и AND, без событийных шлюзов и OR, так как разница между исключающим и не исключающим ИЛИ понятна не всем пользователям.

• Использовать события с типом простое, таймер, сообщение и останов.

Для упрощения восприятия диаграммы стоит придерживаться правил наименования:

• Внешних контрагентов показывать как закрытые, они же — свёрнутые пулы (пулы, в которых нет действий).

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

• Называть дорожки также, как роль, должность или структурное подразделение.

• Называть действия (задачи) в стиле Глагол-Существительное, например, «‎Проверить счёт», «Подтвердить заявку», «Оформить договор».

• Называть события как свершившийся факт в прошедшем времени, к примеру, «Поступила заявка», «Прошло 3 дня».

• Подписывать исходящие из XOR стрелки, например, «Да» и «Нет», а также отмечать поток по умолчанию.

Также рекомендуется:

• Показывать успешное и неуспешное завершение процесса разными финишными событиями.

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

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

Наконец, при разработке любой диаграммы нужно помнить о главном правиле аналитика: независимо от нотации, ваша схема должна быть МАКСИМАЛЬНО простой и понятной читателю БЕЗ знания тонкостей процессного моделирования!

В целом алгоритм разработки BPMN-диаграммы можно представить как набор следующих 7 шагов:

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

2. Описать «счастливый» путь (happy path), который ведёт к созданию полезного результата (продукта).

3. Добавить условия и альтернативные потоки.

4. Добавить неуспешные завершения.

5. Добавить артефакты (объекты и хранилища данных).

6. Раскрыть на новых связанных диаграммах свёрнутые подпроцессы.

7. Добавить промежуточные событийные потоки к внешним пулам.

Пример построения диаграммы по текстовому описанию

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

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

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

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

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

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

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

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

• ШТОРМ — веб-редактор от команды Дениса Котова, пожалуй, главного евангелиста BPMN в России, с автопроверкой диаграмм и возможностями командной работы в одном пространстве;

• Online BPMN — простой и удобный веб-редактор, поддерживает интеграцию с BPMS-системой;

• Cavemo — веб-редактор, аналогичный предыдущему, имеет офлайн-версию

• простые веб-«рисовалки‎» Lucidchart, Draw.io, Visual Paradigm

Также алфавит нотации BPMN поддерживается и в MS Visio, ARIS Express и других редакторах диаграмм общего назначения.

Заключение

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

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

---

• Кандидат технических наук (Системный анализ, управление и обработка информации, 2013)

• Сертифицированный бизнес-аналитик (IIBA CBAP, 2020)

• Сертифицированный специалист Business Studio и СЭД Directum

Профессиональные интересы: системный анализ, бизнес-анализ, разработка и поддержка СМК, ССП (KPI), анализ и формализация бизнес-процессов (UML, IDEF, BPMN), Data Science, технологии Big Data, разработка технической документации (ТЗ по ГОСТам серии 19, 34, руководства пользователя и администратора, описание программных продуктов), управление продуктами и проектами.

Иллюстрация: Оля Ежак для SKillbox Media

Рассказывает просто о сложных вещах из мира бизнеса и управления. До редактуры — пять лет в банке и три — в оценке имущества. Разбирается в Excel, финансах и корпоративной жизни.

Бизнес-аналитик с опытом работы более четырёх лет, магистр в области информационной бизнес-аналитики. Сейчас участвует в проектах, связанных с нефтедобычей, геологоразведкой, логистикой. Принимала участие во внедрении «1С:ERP» как основной бизнес-аналитик. Проверяющий куратор курсов Skillbox «Профессия Бизнес-аналитик», «Профессия Операционный менеджер».

Перед тем как улучшать процессы любого бизнеса, важно описать, как они работают сейчас, — смоделировать их. Нотация BPMN (Business Process Model and Notation) — один из способов такого моделирования.

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

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

В статье для Skillbox Media расскажем:

• что такое бизнес-процессы и для чего ими управлять;
• какие есть способы описания бизнес-процессов;
• что такое нотация BPMN и в чём её главные преимущества;
• из каких элементов состоит BPMN;
• как построить модель бизнес-процесса с помощью BPMN пошагово;
• как применяют нотацию BPMN в бизнес-аналитике;
• как узнать больше об управлении бизнес-процессами.

---

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

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

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

• анализ бизнес-процессов;
• выявление проблем;
• оптимизация бизнес-процессов.

В Skillbox Media есть статья, где подробно рассказано об управлении бизнес-процессами.

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

Три самых распространённых способа описания бизнес-процессов:

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

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

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

Нотации описывают:

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

Есть несколько вариантов нотаций — их выбирают в зависимости от типов бизнес-процессов и потребностей бизнеса. Вот некоторые примеры нотаций:

• Блок-схема — используют для описания алгоритмов, статусов и ролей процесса.
• EPC — используют для описания событий бизнес-процессов.
• IDEF0 — используют для описания логических отношений между этапами процесса.
• ARIS — используют для описания одновременно всех бизнес-процессов компании и её архитектуры.
• BPMN — используют для подробной детализации действий в бизнес-процессах.

В следующих разделах подробно говорим о нотации BPMN.

BPMN — аббревиатура от Business Process Model and Notation. Это система условных обозначений и их описания для моделирования бизнес-процессов.

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

Первая версия BPMN создана в 2004 году рабочей группой IBM. В 2010 году — дополнена и выпущена под названием BPMN 2.0. В неё добавили новые типы событий и диаграмм, устранили ошибки первой версии.

Вот главные преимущества нотации BPMN перед другими нотациями:

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

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

Ниже на иллюстрации приведён пример процесса — поиска и приёма на работу нового сотрудника.

Разберём основные элементы нотации. Их будет достаточно для большинства схем.

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

Примеры задач в иллюстрации выше — «Заявка на подбор нового сотрудника», «Проведение собеседования». Часто задачи формулируют через глагол: «Провести собеседование», «Подобрать сотрудника».

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

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

В нашем примере стартовые события — «Потребность в расширении штата» и «Текущий сотрудник написал заявление на увольнение».

Шлюзы. Показывают слияния потоков управления в рамках процесса. Среди них выделяют:

• Параллельный шлюз — означает, что два процесса исполняются одновременно. Читается как «И».

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

• Эксклюзивный шлюз — используют, чтобы обозначить ветвление потока управления на несколько альтернативных потоков, когда процесс зависит от выполнения условия. Читается как «ИЛИ».

  В этом случае процесс идёт чётко по одному из потоков.

• Неэксклюзивный шлюз — применяют, чтобы показать ветвление потока управления на несколько других, когда процесс зависит от выполнения условий. Читается как «И/ИЛИ».

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

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

В нашем примере объекты данных — «Заявка на подбор», «Лист оценки кандидата», «Предложение о работе».

Потоки. Это стрелки, которые показывают движение по процессам и порядок их выполнения. Есть несколько видов потоков:

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

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

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

• Ассоциация — показывает связи объектов данных и баз данных с процессами.

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

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

Например, в нашей иллюстрации дорожки соответствуют кандидату, HR-менеджеру, руководителю отдела.

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

Существует много инструментов для разработки процессов в BPMN. Мы рекомендуем бесплатный онлайн-сервис Diagrams.net. В нём можно создавать схемы, модели, диаграммы и обмениваться ими в браузере.

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

Вот пошаговый план того, как построить бизнес-процессы в нотации BPMN:

1. Изучите процесс: для чего он нужен и какие задачи решает.

2. Определите, является он основным, вспомогательным или процессом управления.

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

Вспомогательный процесс — процесс, который не генерирует доход, но обеспечивает качественное выполнение основных процессов. Например, бухгалтерский учёт.

Процесс управления — процесс, влияющий на существование и развитие компании. Например, управление командами компании.

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

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

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

6. Отметьте все внутренние события бизнес-процесса. Дополнительные детали можно при необходимости уточнить у владельцев процесса.

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

Задачи бизнес-аналитика, для которых требуется BPMN, делят на два этапа:

• Построение схем «как есть» (as is) — описание текущей последовательности работ бизнес-процесса.
• Построение схем «как будет» (to be) — описание целевого процесса с фиксацией требуемых изменений: этапов модернизации, автоматизации.

Разберём на примере. Допустим, в компании N было 70 сотрудников, которые работали в одном офисе. Всю необходимую документацию они распечатывали, подписывали от руки и самостоятельно относили получателю — например, бухгалтеру, отделу кадров или секретарю.

Потом компания выросла в 2,5 раза, появились удалённые сотрудники. Руководство приняло решение внедрить систему электронного документооборота (СЭД). Перед внедрением такой системы бизнес-аналитику потребуется выполнить три основные задачи:

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

Что даёт описание текущего процесса и моделирование целевого процесса документооборота? Снизится риск упустить ключевые функции СЭД и получить на выходе систему, которая не будет решать задачи компании.

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

• Бизнес-процессы — все операции, которые помогают решать задачи бизнеса и получать доход. Чтобы всё работало по плану, процессами нужно управлять: описывать их, анализировать и оптимизировать.
• Эффективнее всего описывать бизнес-процессы графически — в виде интуитивно понятных схем. Для этого используют различные нотации — системы условных обозначений. Они нужны для того, чтобы любой человек понимал, что изображено на схеме.
• Одна из универсальных и самых наглядных нотаций — нотация BPMN (Business Process Model and Notation). Она в графическом виде отражает последовательность работ бизнес-процессов и логику их выполнения.

• Если вы только начали разбираться в управлении бизнес-процессами — прочитайте статью Skillbox Media «Большой гайд по управлению бизнес-процессами: главное, что должен знать каждый менеджер».
• В этой статье отдельно разбирали вопрос моделирования бизнес-процессов, в этой — процесс их автоматизации.
• Также в Skillbox есть курс «Профессия Бизнес-аналитик». На нём учат собирать данные о финансах компании и бизнес-процессах, проводить продуктовые интервью и определять стратегии развития, оптимизировать процессы.

Другие материалы Skillbox Media для менеджеров

Научитесь: Профессия Бизнес-аналитик
Узнать больше

Название	Кнопка	Графический символ	Описание
Процесс (Задача, Подпроцесс)			Блок представляет собой процесс — действие или набор действий, выполняемых над исходным объектом (документом, материальным объектом и прочим) с целью получения заданного результата. Внутри блока помещается наименование процесса. Временная последовательность выполнения процессов задается расположением процессов на диаграмме слева направо (сверху вниз на вертикальной диаграмме процесса BPMN). Процессы BPMN подразделяются на задачи и подпроцессы. Задача — это простое действие (или операция), которое не имеет дальнейшей декомпозиции в рамках рассматриваемого процесса. Задачи подразделяются на типы, каждый из которых (за исключением абстрактной задачи) обозначается своим маркером в левом верхнем углу блока задачи: — Абстрактная задача (задача с неопределенным типом); — Пользовательская задача (задача, которую выполняет человек при содействии других людей или программного обеспечения); — Сервисная задача (задача, предназначенная для оказания услуги, которая может являться как web-сервисом, так и автоматизированным приложением); — Отправка сообщений (задача, суть которой заключается в отправлении сообщения внешнему участнику за пределы рассматриваемого процесса); — Получение сообщений (задача, суть которой заключается в получении сообщения от внешнего участника, находящегося за пределами рассматриваемого процесса); — Ручное выполнение (задача, выполнение которой подразумевает действия человека и исключает использование каких-либо автоматизированных механизмов исполнения или приложений); — Бизнес-правило (задача, суть которой заключается в выполнении бизнес-правила); — Задача-сценарий (задача, суть которой заключается в выполнении некоторого сценария (или скрипта) — некоторой автоматической операции). По умолчанию создается Задача с типом «Абстрактная задача». На Рис.2 изображена задача с типом «Отправка сообщений». Рисунок 2. Задача Подпроцесс — это декомпозированный процесс, включенный в состав рассматриваемого процесса, который описан более подробно на своей диаграмме. На диаграмме подпроцесс обозначается блоком со знаком «плюс» в центре нижней части фигуры. Подпроцессы подразделяются на типы: — Подпроцесс (подпроцесс с неопределенным типом); — Событийный подпроцесс (подпроцесс, не имеющий входящих и исходящих потоков управления. Событийный подпроцесс запускается всякий раз, когда его стартовое событие запускается во время выполнения родительского процесса); — Транзакция (подпроцесс, состоящий из набора процессов, которые в совокупности представляют некий неделимый процесс: либо весь процесс выполняется полностью, либо не выполняется вообще. Транзакции используются тогда, когда необходимо выполнить несколько процессов, но при каких-то исключительных ситуациях необходимо «откатить» выполняемые процессы); — Ad-Hoc процесс (подпроцесс, представляющий собой группу процессов, взаимодействие между которыми не поддаются строго регламентированным правилам. Определяется только набор процессов, однако, их последовательность и количество выполнений определяются исполнителями этих процессов). По умолчанию создается подпроцесс с типом «Подпроцесс». На Рис.3 изображен событийный подпроцесс. Рисунок 3. Подпроцесс Для процессов BPMN (и для задач, и для подпроцессов) предусмотрено обозначение циклического выполнения. Для процесса BPMN можно задать следующие типы циклов: — Стандартный цикл (используется, когда количество циклов заранее неизвестно. Процесс будет выполняться в цикле, пока верно некоторое условие); — Многоэкземплярный параллельный цикл (используется, когда количество циклов известно заранее. При этом экземпляры процесса будут выполняться параллельно); — Многоэкземплярный последовательный цикл (используется, когда количество циклов известно заранее. При этом экземпляры процесса будет выполняться последовательно). Для процесса BPMN можно задать специальный тип процесса — Компенсация. Некоторые процессы могут приводить к нежелательным результатам, которые следует отменить. Процессы-компенсации как раз предусмотрены для отмены результатов выполнения некоторого процесса. Процессы-компенсации не должны иметь входящих и исходящих потоков управления и могут соединяться входящей ассоциацией с граничным событием с типом «Компенсация». Пример соединения события и процесса с типом «Компенсация» специальным типом соединения «Ассоциация» см. в описании к символу «Ассоциация», приведенному в данной таблице ниже. Изменение типа задачи или подпроцесса, типа цикла или выбор для процесса типа «Компенсация» осуществляется при помощи подменю в контекстном меню, вызываемом от процесса на диаграмме. Подробнее об особенностях работы с процессами на диаграмме процесса в нотации BPMN см. Руководство пользователя в статье Процессы.
Событие			Событие — состояние, которое является существенным для целей управления бизнесом и оказывает влияние или контролирует дальнейшее развитие одного или более бизнес-процессов. Внутри блока помещается наименование события. При выполнении процесса могут происходить различные события, оказывающие влияние на ход процесса: старт процесса, его завершение, смена статуса документа, получение сообщения и многое другое. Но событие – элемент необязательный, поэтому на диаграмме процесса в нотации BPMN его может и не быть. Если же события возникают при выполнении процесса, то они разделяются на 2 категории: возникающие из-за какой-то причины и инициирующие какой-то результат. И причина возникновения события, и результат, который инициирует событие, называются триггером. События, обрабатывающие триггер, который привел к их возникновению, называются обработчиками. События, которые инициируют триггер (или некий результат), называются инициаторами. По типу триггера события делятся на следующие типы: Неопределенное (без триггера), Сообщение, Таймер, Условие, Сигнал, Множественное, Параллельное множественное, Эскалация, Ошибка, Ссылка, Компенсация, Завершение. Триггер обозначается специальным маркером внутри события. События-обработчики — это все стартовые и некоторые промежуточные события. Если встречается событие-обработчик, то процесс ожидает наступления этого события, т.е. ожидает появления причины возникновения этого события. На диаграмме триггер внутри события, являющегося обработчиком, показывается незакрашенным. События-инициаторы – это некоторые промежуточные события (включая промежуточное событие с типом «Неопределенное») и все конечные события. Если встречается событие-инициатор, то процесс просто выполняется дальше и ничего не ожидает. На диаграмме триггер внутри события, являющегося инициатором, показывается закрашенным. На Рис.4 изображены различные типы событий: — Событие 1 — стартовое событие с типом триггера «Сообщение»; — Событие 2 — промежуточное событие (обработчик) с типом триггера «Таймер»; — Событие 3 — промежуточное событие (инициатор) с типом триггера «Сигнал»; — Событие 4 — конечное событие с типом триггера «Сообщение». Рисунок 4 Промежуточные события (обработчики) могут присоединяться к границе процесса. Такие события называются граничными. Граничное событие изображает событие, возникающее при выполнении процесса, к границе которого это событие присоединено. Причем граничное событие может прервать выполнение процесса — граничное прерывающее, и не прерывать — граничное непрерывающее. Граничное непрерывающее событие изображается пунктирными линиями. На Рис.5 изображено использование граничного прерывающего события. Если при выполнении Процесса 1 возникнет Событие 2, то выполнение Процесса 1 прервется и на текущей диаграмме дальнейшее выполнение процесса будет происходить по потоку, исходящему от граничного события, т.е. начнется выполнение Процесса 3. Рисунок 5. Граничное прерывающее событие На Рис.6 изображено использование граничного непрерывающего события. Если при выполнении Процесса 1 возникнет Событие 2, то выполнение Процесса 1 продолжится. На текущей диаграмме дальнейшее выполнение процесса будет происходить по потоку, исходящему от граничного события, т.е. начнется выполнение Процесса 3. А также после выполнения Процесса 1 начнет выполняться Процесс 2 Рисунок 6. Граничное непрерывающее событие Подробнее об особенностях работы с событиями на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье События.
Параллельный шлюз			Параллельный шлюз (AND, «И») используется для обозначения слияния/ветвления потоков управления в рамках процесса. На Рис.7 параллельный шлюз используется для ветвления потоков управления или создания параллельных веток выполнения процесса: после выполнения Процесса 1 запустится выполнение и Процесса 2, и Процесса 3. Рисунок 7 На Рис.8 параллельный шлюз используется для слияния потоков управления или синхронизации параллельных веток выполнения процесса. Выполнение Процесса 3 запустится только тогда, когда выполнится и Процесс 1, и Процесс 2. Рисунок 8 Подробнее об особенностях работы со шлюзами на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Шлюзы.
Эксклюзивный шлюз			Эксклюзивный шлюз (XOR, «Исключающее ИЛИ») используется для ветвления потока управления на несколько альтернативных потоков, когда выполнение процесса зависит от выполнения некоторого условия. Символ «Эксклюзивный шлюз» может содержать внутренний маркер, выполненный в виде «X», но это не является обязательным. По умолчанию эксклюзивный шлюз добавляется на диаграмму с маркером. Управление отображением маркера в эксклюзивном шлюзе осуществляется с помощью параметра «Параметры диаграммы BPMN» в Настройках для всех пользователей Business Studio (пункт Главного меню Главное меню → Главная → Настройки для всех пользователей). Для шлюза можно указывать наименование. Условия на диаграмме задаются при помощи условных потоков управления, исходящих из шлюза. При использовании эксклюзивного шлюза можно продолжить выполнение процесса только по одному из возможных условных потоков управления. Среди потоков управления, исходящих из эксклюзивного шлюза, допускается использование потока управления по умолчанию: если ни одно из условий не выполняется, дальнейшее выполнение процесса продолжится по потоку управления по умолчанию. На Рис.9 после выполнения Процесса 1 дальнейшее выполнение процесса может продолжиться только по одному потоку, исходящему из шлюза: — если Условие 1 верно, то выполнится только Процесс 3; — если Условие 2 верно, то выполнится только Процесс 4; — если ни Условие 1, ни Условие 2 не верны, то выполнится только Процесс 2. Рисунок 9 Эксклюзивный шлюз может использоваться и для слияния потоков управления. В данном случае шлюз просто пропускает через себя все потоки управления без синхронизации. На Рис.10 Процесс 3 будет выполнен дважды: после выполнения Процесса 1 и после выполнения Процесса 2. Рисунок 10 Подробнее об особенностях работы со шлюзами на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Шлюзы.
Неэксклюзивный шлюз			Неэксклюзивный шлюз (OR, «ИЛИ») используется для ветвления потока управления на несколько потоков, когда выполнение процесса зависит от выполнения условий. При этом каждое из указанных условий является независимым, и дальнейшее выполнение процесса может продолжиться сразу по нескольким потокам управления, если условия будут выполнены. Для шлюза можно указывать наименование. Условия на диаграмме задаются при помощи условных потоков управления, исходящих из шлюза. Среди потоков управления, исходящих из неэксклюзивного шлюза, допускается использование потока управления по умолчанию: если ни одно из условий не выполняется, дальнейшее выполнение процесса продолжится по потоку управления по умолчанию. На Рис.11 после выполнения Процесса 1 дальнейшее выполнение процесса может продолжиться по любому потоку, исходящему из шлюза, если условие, заданное на этом потоке, выполняется: — если Условие 1 верно, то выполнится Процесс 3; — если Условие 2 верно, то выполнится Процесс 4; — если ни Условие 1, ни Условия 2 не верны, то выполнится только Процесс 2. Рисунок 11 Показать ветвление потоков управления подобно неэксклюзивному шлюзу можно при помощи условных потоков управления (Рис.20). Неэксклюзивный шлюз может использоваться для слияния потоков управления. В данном случае шлюз может использоваться для синхронизации. На Рис.12 Процесс 3 будет выполнен только тогда, когда выполнится и Процесс 1, и Процесс 2. Рисунок 12 Подробнее об особенностях использования неэксклюзивного шлюза для слияния потоков управления при имитационном моделировании см. в методике Имитационное моделирование деятельности в статье Ветвление и слияние типа «ИЛИ» в нотации BPMN. Об особенностях работы со шлюзами на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Шлюзы.
Комплексный шлюз			Комплексный шлюз используется для ветвления потока управления на несколько потоков, когда выполнение процесса зависит от выполнения условий. По своему действию комплексный шлюз аналогичен неэксклюзивному шлюзу. Для шлюза можно указывать наименование. На Рис.13 после выполнения Процесса 1 дальнейшее выполнение процесса может продолжиться по любому потоку, исходящему из шлюза, если условие, заданное на этом потоке, выполняется: — если Условие 1 верно, то выполнится Процесс 2; — если Условие 2 верно, то выполнится Процесс 3; — если Условие 3 верно, то выполнится Процесс 4. Рисунок 13 Подробнее об особенностях использования комплексного шлюза для слияния потоков управления при имитационном моделировании см. в методике Имитационное моделирование деятельности в статье Ветвление и слияние типа «ИЛИ» в нотации BPMN. Об особенностях работы со шлюзами на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Шлюзы.
Эксклюзивный шлюз по событиям			Эксклюзивный шлюз по событиям (XOR, «Исключающее ИЛИ») используется для ветвления потока управления на несколько альтернативных потоков, когда дальнейшее выполнение процесса зависит от возникновения некоторого события-обработчика, следующего после шлюза. Отдельно взятое событие, обычно с типами «Получение сообщения» или «Таймер», определяет выбор только одного маршрута, по которому будет проходить дальнейшее выполнение процесса: событие, идущее после шлюза и возникшее первым, определяет дальнейший ход выполнения процесса. На Рис.14 после выполнения Процесса 1 дальнейшее выполнение процесса может продолжиться только по одной ветке, исходящей из шлюза: — если первым возникло Событие 1, то выполнится только Процесс 2; — если первым возникло Событие 2, то выполнится только Процесс 3. Рисунок 14 Существует 2 типа шлюзов по событиям, которые могут быть использованы в начале процесса: — эксклюзивный шлюз по событиям (для запуска процесса) (Рис.15); — параллельный шлюз по событиям (для запуска процесса) (Рис.16). В случае, когда шлюз по событиям используется для запуска процесса, у него не должно быть входящих связей. Эксклюзивный шлюз по событиям (для запуска процесса) аналогичен обычному эксклюзивному шлюзу по событиям: событие, идущее после шлюза и возникшее первым, определяет дальнейший ход выполнения процесса. На Рис.15 выполнение процесса начнется с возникновения одного из событий, идущих после шлюза: — если первым возникнет Событие 1, то дальнейшее выполнение процесса будет осуществляться только по потоку управления, исходящему из этого события, т.е. выполнится Процесс 1; — если первым возникнет Событие 2, то дальнейшее выполнение процесса будет осуществляться только по потоку управления, исходящему из этого события, т.е. выполнится Процесс 2. Рисунок 15 При использовании параллельного шлюза по событиям (для запуска процесса) выполнение процесса запускается по всем возникшим событиям, идущим после шлюза. На Рис.16 Процесс 1 и Процесс 2 будут выполнены, если возникнут события, идущие перед этими процессами. Рисунок 16 Подробнее об особенностях работы со шлюзами на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Шлюзы.
Поток управления			Стрелка используется для связи элементов потока BPMN (событий, процессов, шлюзов). Поток управления отображает ход выполнения процесса. При необходимости поток может быть именованным. Стандартный поток управления является неконтролируемым, т.е. на поток не воздействуют никакие условия, и поток не проходит через шлюзы. Простейшими примерами неконтролируемого потока управления могут служить отдельно взятый поток управления, связывающий два процесса (Рис.17), или потоки управления, сходящиеся в процессе (Рис.18) или расходящийся от него (Рис.19). Рисунок 17 Рисунок 18 Рисунок 19
Условный поток управления			Стрелка используется для отображения потока управления и используется тогда, когда необходимо показать, что по рассматриваемому потоку будет происходить дальнейшее выполнение процесса только в том случае, если выполнится условие, указанное в названии потока. В случае, если условный поток управления является исходящим от процесса, то у основания линии изображается небольшой ромбик (Рис.20). Если же условный поток управления является исходящим от шлюза, то никакого ромбика у основания линии не будет (см. Рис.9). Рисунок 20 Подробнее об особенностях работы с потоками управления на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Создание связей.
Поток управления по умолчанию			Стрелка используется для отображения потока управления и используется тогда, когда необходимо показать, что по рассматриваемому потоку будет происходить дальнейшее выполнение процесса только в том случае, если не выполнилось ни одно из условий, заданных на условных потоках управления, исходящих из процесса или эксклюзивного/неэксклюзивного шлюза. Для изображения таких потоков управления используется диагональная черточка, располагающиеся у основания линии. При необходимости поток управления по умолчанию может быть именованным (см. Рис.20). Подробнее об особенностях работы с потоками управления на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Создание связей.
Поток сообщений			Стрелка используется для отображения межпроцессного взаимодействия — для связи элементов потока со свернутыми пулами. При необходимости поток может быть именованным. Поток сообщений не отображает ход выполнения процесса, а показывает передачу сообщений или объектов из одного процесса в другой процесс или внешнюю ссылку. На Рис.21 представлено 4 примера использования потоков сообщений: — поток сообщений представляет механизм запуска процесса: Поток сообщений 1 выходит из внешнего процесса (или внешней ссылки) и входит в стартовое Событие 1. В качестве события может выступать и промежуточное событие-обработчик, но в этом случае поток сообщений будет инициировать лишь возникновение события, а не запуск процесса; — поток сообщений используется для передачи сообщений или объектов из внешнего процесса (или внешней ссылки) в один из процессов рассматриваемого процесса: Поток сообщений 2 выходит из Процесса 2 и входит в Задачу 1; — поток сообщений используется для передачи сообщений или объектов из одного процесса рассматриваемого процесса во внешний процесс (или внешнюю ссылку): Поток сообщений 3 выходит из Задачи 2 и входит во внешний процесс (или внешнюю ссылку); — передача сообщения (или объекта) во внешний процесс (или внешнюю ссылку) инициируется конечным событием: Поток сообщений 4 выходит из конечного События 2 и входит во внешний процесс (или внешнюю ссылку). В качестве события может выступать и промежуточное событие-инициатор. Рисунок 21 Подробнее об особенностях работы с потоками сообщений на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Создание связей.
Ассоциация			Стрелка используется для отображения связи объектов данных и баз данных с процессами. Связь может быть направленной и ненаправленной в зависимости от соединяемых элементов и типа связи. На Рис.22 Объект данных передается из Процесса 1 в Процесс 3. При этом при помощи ассоциаций устанавливается 2 связи: связь процесса с объектом данных и связь объекта данных с процессом. При наведении связи между двумя элементами предлагается выбрать тип связи. Рисунок 22 Если объект данных передается между двумя последовательно соединенными процессами, то можно использовать одну ассоциацию, которая строится в направлении от объекта данных к потоку управления, связывающему два процесса (Рис.23). После добавления ассоциации последовательно будет предложено выбрать типы связи: тип связи процесса с объектом данных и тип связи объекта данных с процессом. Рисунок 23 Подобно ассоциации, связанной с потоком управления, объекты данных можно присоединять ассоциацией к потокам сообщений. При этом также будет создано две связи: связь процесса с объектом данных и связь объекта данных с процессом. Выбрать тип соответствующей связи также будет предложено последовательно (Рис.24). Рисунок 24 Возможные типы связей, которые могут быть выбраны при установлении связей двух элементов при помощи ассоциации приведены ниже в Табл.2 — Табл.6 в статье Типы связей между элементами диаграммы BPMN. Ассоциации также используются для отображения обработчика компенсации, т.е. когда процесс с типом «Компенсация» используется для компенсации выполнения другого процесса. В этом случае промежуточное событие с типом «Компенсация» присоединяется к границам процесса для того, чтобы указывать на то, что этому процессу может потребоваться компенсация. В то же время событие соединяется ассоциацией с процессом, который будет компенсировать выполнение первого процесса (Рис.25). Рисунок 25 Подробнее об особенностях работы с ассоциациями на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Создание связей.
Пул			Пул предназначен для отображения потока рассматриваемого процесса. Содержимое пула — это и есть тот процесс, диаграмма которого рассматривается. На диаграмме развернутый пул может быть только один.
Дорожка			Дорожка предназначена для отображения исполнителей задач и подпроцессов процесса BPMN (оргединиц или объектов деятельности). Внутри блока помещается наименование исполнителя. Подробнее об особенностях работы с дорожками на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Работа с дорожками.
Свернутый пул			Символ, обозначающий внешний (по отношению к текущей диаграмме) процесс или внешнюю ссылку. Внутри блока помещается наименование внешнего процесса или внешней ссылки. Свернутый пул используется для указания взаимосвязей процесса: — обозначает процесс или внешнюю ссылку, откуда поступил или куда передается поток сообщений; — обозначает предыдущий или следующий процесс по отношению к диаграмме рассматриваемого процесса. На Рис.26 показано, что сдаточная документация поступает в процесс «Организация итогового собрания по проекту» из процесса «Внесение сдаточной документации в папку проекта». Рисунок 26 На Рис.27 показано, что после окончания Процесса 1 Событие 2 инициирует отправку сообщения в Процесс 2. Рисунок 27. Диаграмма Процесса 1 На диаграмме Процесса 2 (Рис.28) показано, что поток сообщений, поступающий из Процесса 1, инициирует Событие 2, запускающее выполнение Процесса 2. Рисунок 28. Диаграмма Процесса 2
Документы			Используется для отображения на диаграмме документов, сопровождающих выполнение процесса. Рядом с блоком размещается наименование документа. В качестве объекта данных может использоваться объект справочников: Бумажный документ, Электронный документ.
Программные продукты			Используется для отображения на диаграмме программных продуктов, сопровождающих выполнение процесса. Рядом с блоком размещается наименование продукта.
Базы данных			Используется для отображения на диаграмме базы данных, сопровождающей выполнение процесса. Рядом с символом размещается наименование базы данных.
Материальные объекты			Используется для отображения на диаграмме материальных объектов, сопровождающих выполнение процесса. Рядом с символом размещается наименование объекта.
Прочее			Используется для отображения на диаграмме объектов справочника Прочее, сопровождающих выполнение процесса. Рядом с символом размещается наименование объекта.
Сноска			Выносной символ, предназначенный для нанесения текстовых комментариев. Символ может быть использован на диаграммах процессов в любых нотациях.

BPMN (Business Process Model and Notation — нотация и модель бизнес процессов) разработана компанией Business Process Management Initiative и поддерживается Object Management Group после слияния организаций в 2005 г. Последняя версия 2.0 вышла в 2012 г. В 2013 году BPMN утверждена в качестве международного стандарта ISO/IEC 19510.

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

Бизнес-процессы

Существует множество определений бизнес-процессов. Например Википедия дает такое определение:

Бизнес-процесс — это совокупность взаимосвязанных мероприятий или работ, направленных на создание определённого продукта или услуги для потребителей. Управленческая концепция BPM рассматривает бизнес-процессы как важные ресурсы предприятия, и предполагает управление ими как одну из ключевых организационных систем.

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

Еще одним определением процесса (бизнес-процесса) будет:

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

Входы и выходы — это информационные и материальные потоки.
Прежде чем описывать процесс в виде графической схемы, очень важно определить его контекст

Запомните принцип:

процесс может:

• получать входы от других процессов;
• передавать выходы другим процессам

Процесс НЕ может:

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

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

Бизнес-процесс состоит из операций и действий. Дадим определение этим понятиям.

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

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

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

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

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

И давайте рассмотрим следующую схему:

Зеленый круг — стартовое событие, которое указывает на начало того или иного процесса;

Красный круг — конечное событие, которое указывает на точку завершения процесса;

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

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

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

Область применения нотации BPMN

Нотация BPMN предназначена для описания:

• Порядка исполнения работ образующих бизнес-процесс,
• Потоков данных между операциями процесса;
• Потоков сообщений между процессами;
• Ассоциации обрабатываемых объектов данных с операциями процесса.

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

• Функциональную (структурную) декомпозицию работ;
• Организационную структуру предприятия;
• Модель данных;
• Бизнес правила,
• Бизнес стратегию компании

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

Основные элементы нотации

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

1.Элементы управления;
2. Соединительные элементы;
3. Артефакты;
4. Данные.
5. Зоны ответственности

Зоны ответственности

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

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

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

Пул разделен на дорожки, которые служат для группировки операций диаграммы. Дорожки имеют имя. Дорожки принято называть в терминах исполнителей процесса. Ими могут быть:
• должности;
• роли.

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

События

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

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

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

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

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

В BPMN разные события изображаются по разному.

Операции и логические операторы

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

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

Соединительные элементы

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

Операции процесса на схеме соединены стрелками. Эти стрелки имеют тип «Sequence flow» — они показывают последовательность выполнения операций во времени. Можно сказать, что они управляют «потоком операций» — Work Flow.

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

Поток операций (управления) (Sequence Flow)	Поток операций служит для отображения того порядка, в котором организованы действия Процесса или условия Хореографии.
Поток сообщений (Message Flow)	Поток сообщений служит для отображения обмена сообщениями между двумя участниками, готовыми эти сообщения отсылать и принимать. На диаграмме взаимодействия BPMN два отдельно взятых Пула представляют собой двух участников Процесса (бизнес-сущности или бизнес-роли).
Ассоциация (Association)	Ассоциация служит для установления связи между информацией или Артефактами (объектами, не относящимися к Элементам потока) и элементами потока. Текстовые объекты, а также графические объекты, не относящиеся к элементам потока, могут соотноситься с элементами потока. При необходимости Ассоциация может указывать направление потока (например, потока данных).

Данные

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

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

Хранилища данных изображают внешние по отношению к процессу системы хранения, например, СУБД.

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

Артефакты

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

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

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

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

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

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

Субклассы нотации BPMN

Полный набор графических элементов в нотации BPMN 2.0 содержит 116 графических элементов, для упрощения работы с ними их можно разделить на несколько групп (взято из книги Федорова И.Г. «Моделирование бизнес-процессов в нотации BPMN 2.0»)

Основной набор включает 7 элементов, достаточен для разработки концептуальной (не исполняемой) модели процесса.

• Подмножество описательных элементов (+17) достаточно для построения исполняемой модели;
• Подмножество аналитических элементов (+29) • Наконец, полный набор (+50) позволяет создавать любые типы диаграмм.

Логика процесса

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

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

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

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

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

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

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

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

Пример построения процесса с помощью BPMN

Ниже представлена схема процесса «Подача заявления на отпуск сотрудником». Это наверное  вариант самой встречаемой схемы, которой будет достаточно для построения 90% схем и она досточно понятна даже стороннему наблюдателю.

BPMN 2.0 Метамодель и нотация бизнес-процессов (сводная информация)

BPMN (Business Process Management Notation) – это язык моделирования бизнес-процессов, который является промежуточным звеном между формализацией/визуализацией и воплощением бизнес-процесса.

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

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

Является ли нотация BPMN лучшей для поставленных перед ней задач? Хороший ответ, актуальный до сих пор, дал еще в семидесятых годах XX века Чарльз Бокс «Все модели неверны, некоторые полезны». BPMN точно полезна, а некоторые ограничения, которые нотация имеет, по мнению экспертов не столь важны на практике:

Моделируя что-либо, мы удаляем некоторые аспекты реального мира, чтобы их визуализировать. И все же ИТ-профессионалы продолжают искать одну истинную нотацию моделирования и набор семантики, чтобы управлять сразу всем. Они предполагают, что должно быть возможно перевести все аспекты и их взаимосвязи на визуальный язык. Я думаю, что большинству людей бизнеса это не нужно. Они используют модели для общения друг с другом … и да, в ходу круги и стрелки, прямоугольники и облака, и … лишь очень немногие заинтересованы в том, чтобы отразить взаимосвязь всех аспектов друг с другом. Дерек Миерс (Derek Miers) – Отраслевой аналитик и консультант. Более 25 лет специализируется в сферах управления бизнес-процессами, цифровой трансформации, бизнес-архитектуры и технологических инноваций. В настоящее время работает в Gartner время на позиции директора по исследованиям в сфере Enterprise Architecture (EA)

Первая версия нотации BPMN вышла в мае 2004 года (BPMN 1.0). Следующая версия появилась в январе 2011 года (BPMN 2.0). Наконец, в январе 2013 года компания OMG выпустила ту версию, которая в основном используется и сегодня – BPMN 2.0.2.

Основные графические элементы BPMN

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

Элементы нотации BPMN – это элементы графической схемы, но также и элементы самого бизнес-процесса.

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

• Пул и Дорожки
• Действия
• Шлюзы или Развилки
• События
• Потоки
• Артефакты

В BPMN 2.0 элементы представлены в виде специальных значков. Создатели данной системы стремились к тому, чтобы набор значков был исчерпывающим и обеспечивал возможность наглядного отображения максимального разнообразия схем бизнес-процессов. В итоге значков очень много и с полным списком можно ознакомиться в документации по BPMN, которая переведена на русский язык членами Ассоциации BPM-профессионалов России. Здесь мы остановимся только на базовых элементах, без которых не обойдётся ни одна схема бизнес-процесса. Этого достаточно для общего знакомства с BPMN и понимания основных принципов нотации.

BPMN элементы “Пул” и “Дорожка”

Весь бизнес-процесс состоит из пулов: совокупности операций + лиц, которые эти операции выполняют.

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

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

BPMN элемент “Действие”

Под “действием” понимается единица работы, выполняемой в ходе исполнения бизнес-процесса. Действия могут быть как элементарными (задача/task), так и составными (подпроцесс/sub-process).

Есть несколько типов элементарных действий, которые отличаются условиями выполнения:

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

BPMN предполагает следующие графические отображения для основных типов действий:

Здесь стоит отметить, что современные BPM-системы зачастую предлагают более широкий набор типов действий, чем предлагает BPMN. Например, в инструменте для моделирования бизнес-процессов в Comindware Business Application Platform вы найдёте графические элементы для нескольких типов элементарных действий, а также встроенных кейсов:

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

BPMN элементы “Развилка” или “Шлюз”

Под шлюзами понимаются элементы, определяющие ветвление и слияние потоков работ.

BPMN описывает 7 типов развилок. В качестве основных выделяют 2 типа:

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

Пример использования шлюза исключающего «или» для создания альтернативных потоков процесса:

• Этап 7. Звонок клиенту с целью оценить качество обслуживания.
• 1. Если клиент доволен, фиксация положительной оценки, закрытие бизнес-процесса.
• 2. Если клиент недоволен, выяснение причины.

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

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

BPMN элемент “Событие”

“Событие” является одним из главных элементов BPMN и служит для описания того, что должно случиться (в отличие от задачи, когда что-то должно быть сделано). Событием может быть, например, подписание договора, или разговор с клиентом.

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

1. В зависимости от положения события на схеме процесса:

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

1. По типу события классификация следующая:

Очень часто начальные и конечные события являются событиями-сообщениями.

BPMN элементы “Потоки”

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

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

BPMN элементы “Артефакт”

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

Основные виды артефактов:

Преимущества BPMN

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

Первое – простота трансляции диаграмм в исполняемые модели с помощью языка формального описания бизнес-процессов.

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

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

Comindware Business Application Platform – современная платформа для автоматизации бизнес-процессов с поддержкой нотации BPMN 2.0, включая как возможность моделирования BPMN-процессов прямо в платформе, так и импорт схем бизнес-процессов из сторонних инструментов моделирования для их дальнейшего исполнения в системе Comindware.

Хотите узнать больше о платформе Comindware и оценить насколько она подойдёт для вашей компании? Закажите бесплатную демо-презентацию.

Заказать демо

Елена Гайдукова, маркетолог-аналитик. Работает в сфере BPM и автоматизации процессов с 2014 года. В настоящее время является бренд-менеджером решений на базе Comindware Business Application Platform.

<<предыдущая содержание следующая>>

• 7.1 Область применения BPMN
  • 7.1.1 Использование BPMN
• 7.2. Элементы BPMN
  • 7.2.1 Основные графические элементы моделирования
  • 7.2.2 Полный перечень графических элементов диаграмм бизнес-процессов
• 7.3. Типы Диаграмм Бизнес-процессов (BPMN Diagram Types)
• 7.4. Использование текста, цвета и линий в моделировании диаграмм
• 7.5. Правила соединения элементов потока
  • 7.5.1. Правила соединения потоков операций
  • 7.5.2. Правила соединения потоков сообщений
• 7.6. Расширяемость BPMN
• 7.7. Примеры Процессов BPMN

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

Существуют пять основных категорий элементов:

1. Элементы потока (Flow Objects);
2. Данные (Data)
3. Соединяющие элементы (Connecting Objects);
4. Зоны ответственности (Swimlanes);
5. Артефакты (Artifacts).

Примените знания нотации BPMN 2.0 на практике
в Low-code BPM-системе ELMA365

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

1. События (Events);
2. Действия (Activities);
3. Шлюзы (Gateways).

Данные на диаграмме могут быть представлены любыми из следующих четырех элементов:

1. Объект данных (Data Objects)
2. Входные данные (Data Inputs)
3. Выходные данные (Data Outputs)
4. Хранилища данных (Data Stores)

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

1. Поток операций (Sequence Flow);
2. Поток сообщений (Message Flow);
3. Ассоциация (Association);
4. Ассоциация данных (Data Associations).

Существуют два способа группировки основных элементов моделирования с помощью Зон ответственности:

1. Группировка с помощью Пула (Pool);
2. Группировка с помощью Дорожки (Lane).

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

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

1. Группа (Gruop);
2. Текстовая аннотация (Text Annotation).

7.2.1. Основные графические элементы моделирования

Примените знания нотации BPMN 2.0 на практике
в Low-code BPM-системе ELMA365

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

Элемент	Описание	Нотация
Событие (Event)	Событие – это то, что происходит в течение бизнес-процесса или его Xореографии. Событие оказывает влияние на ход бизнес-процесса и чаще всего имеет причину (триггер) или воздействие (результат). Изображается в виде круга со свободным центром, предназначенным для дифференцировки внутренними маркерами различных триггеров или их результатов. Согласно влиянию Событий на ход бизнес-процесса, выделяют три типа: Стартовое событие (Start), Промежуточное событие (Intermediate) и Конечное событие (End).
Действие (Activity)	Действие – общий термин, обозначающий работу, выполняемую исполнителем в ходе бизнес-процесса. Действия могут быть либо элементарными, либо неэлементарными (составными). Выделяют следующие виды действий, являющихся частью модели Процесса: Подпроцесс (Sub-Process) и Задача (Task). И Задача, и Подпроцесс изображаются в виде прямоугольников с закругленными углами. Все Действия могут являться элементами как стандартных Процессов, так и Хореографий.
Шлюз (Gateway)	Шлюзы используются для контроля расхождений и схождений Потока операций как в Процессе, так и в Хореографии. Таким образом, данный термин подразумевает ветвление, раздвоение, слияние и соединение маршрутов. Внутренние маркеры указывают тип контроля развития бизнес-процесса.
Поток операций (Sequence Flow)	Поток операций служит для отображения того порядка, в котором организованы действия Процесса или условия Хореографии.
Поток сообщений (Message Flow)	Поток сообщений служит для отображения обмена сообщениями между двумя участниками, готовыми эти сообщения отсылать и принимать. На диаграмме взаимодействия BPMN два отдельно взятых Пула представляют собой двух участников Процесса (бизнес-сущности или бизнес-роли).
Ассоциация (Association)	Ассоциация служит для установления связи между информацией или Артефактами (объектами, не относящимися к Элементам потока) и элементами потока. Текстовые объекты, а также графические объекты, не относящиеся к элементам потока, могут соотноситься с элементами потока. При необходимости Ассоциация может указывать направление потока (например, потока данных).
Пул (Pool)	Пул представляет собой Участника Взаимодействия. Пул также может выступать в качестве Зоны ответственности или графического контейнера, отвечающего за разделение определенного набора действий, относящихся к другим Пулам, что обычно встречается в ситуациях типа «бизнес для бизнеса» (B2B). Внутри Пула МОЖЕТ находиться дополнительная информация по выполняемому Процессу. В случае, если такой информации в Пуле не содержится, то он МОЖЕТ представлять собой «черный ящик».
Дорожка (Lane)	Дорожка используется для отображения распределения ролей и может быть как вертикальной, так и горизонтальной (также может использоваться для разделения внутреннего пространства Пула). Служит для упорядочивания и категоризации Действий.
Объект данных (Data Object)	Объект данных предоставляет информацию о том, какие действия необходимо выполнить и/или каков результат этих действий. Может изображаться как в единственном экземпляре, так и в нескольких. Входные и Выходные данные Объекта данных представляют собой одну и ту же информацию о Процессе.
Сообщение (Message)	Сообщение используется для отображения сущности взаимодействия между двумя Участниками бизнес-процесса (Участники определяются командами business PartnerRole или business PartnerEntity).
Группа (блок, содержащий группу объектов одной категории) (Group)	Группа предназначена для группировки графических элементов, принадлежащих одной и той же категории. Такая группировка не оказывает влияния на Поток операций. На диаграмме бизнес-процесса название категории, к которой принадлежат сгруппированные элементы, отображается в качестве названия группы. Такого рода группировка может использоваться в целях составления документации или при проведении анализа. Графически Группы отображаются так же, как и Категории объектов.
Текстовая аннотация (связана с Ассоциацией) (Text Annotation)	Текстовые аннотации являются механизмом, позволяющим разработчику модели бизнес-процесса вводить дополнительную информацию для тех, кто работает с BPMN диаграммами.

7.2.2. Полный перечень графических элементов диаграмм бизнес-процессов

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

Элемент	Описание	Нотация
Событие (Event)	Событие – это то, что происходит в течение бизнес-процесса или его Xореографии. Событие оказывает влияние на ход бизнес-процесса и чаще всего имеет причину (триггер) или воздействие (результат). Изображается в виде круга со свободным центром, предназначенным для дифференцировки внутренними маркерами различных триггеров или их результатов. Согласно влиянию Событий на ход бизнес-процесса, выделяют три типа: Стартовое событие (Start), Промежуточное событие (Intermediate) и Конечное событие (End).
Состав потока (Flow Dimension) (например, Стартовое событие, Промежуточное событие, Конечное событие) Стартовое событие Промежуточное событие Конечное событие	Как видно из названия, Стартовое событие указывает на то, в какой точке берет начало тот или иной Процесс или Хореография(Choreography). Промежуточное событие происходит на отрезке, ограниченном Стартовым и Конечным Событиями. Промежуточное событие оказывает влияние на ход Процесса или Хореографию, однако, не может являться началом или непосредственным завершением Процесса. Как видно из названия, Конечное событие указывает на то, в какой точке завершится тот или иной Процесс или Хореография.
Тип (Type Dimension) (например, Неопределенный, Сообщение, Таймер, Ошибка, Отмена, Компенсация, Условие, Связь, Сигнал,Множественный, Завершение)	Стартовые и некоторые Промежуточные события имеют триггеры, определяющие причины происхождения Событий данных типов (см. разделы Стартовое событие и Промежуточное событие далее по тексту). Существует множество причин, инициирующих появление События. Конечные события МОГУТ определять результат, являющийся следствием окончания Потока операций. В отличие от Стартового события, которое лишь обрабатывает триггер, Промежуточное может как обрабатывать триггеры, так и возбуждать их. Конечное событие лишь определяет результат (инициирует триггер). Маркеры Событий, обрабатывающих триггеры, отображаются без заливки, в то время, как маркеры инициирующих триггеры Событий закрашены. Кроме того, некоторые типы Событий, используемые в BPMN 1.1 для прерывания хода Действия, в данной редакции могут использоваться для других целей. Такое Событие изображается в виде круга с пунктирными границами (см. ряд Событий справа).
Действие (Activity)	Действие – общий термин, обозначающий работу, выполняемую исполнителем в ходе бизнес-процесса. Действия могут быть либо элементарными, либо неэлементарными (составными). Выделяют следующие виды действий, являющихся частью модели Процесса: Подпроцесс (Sub-Process) и Задача (Task). И Задача, и Подпроцесс изображаются в виде прямоугольников с закругленными углами. Все Действия могут являться элементами как стандартных Процессов, так и Хореографий.
Задача (элементарное действие) (Task)	Задача представляет собой элементарное действие, включенное в состав Процесса. Используется в случае, если Процесс не детализируется далее в данной Модели.
Задача Хореографии (Choreography Task)	Задача Хореографии представляет собой элементарное действие в составе Хореографии. Отображает один или несколько случаев обмена сообщениями и подразумевает наличие как минимум двух Участников. Название Задачи Хореографии и имена Участников отображаются в трех разных частях данного графического элемента. Таким образом, графически Задача Хореографии должна быть разделена на дорожки с именами участников (две или более), а также содержать дорожку, предназначенную для названия данной Задачи.
Процесс/Подпроцесс (неэлементарное действие) (Process/Sub-Process)	Подпроцесс представляет собой комплексное Действие, включенное в состав Процесса. Такой вид действия считается составным, т.к. может быть разбит на составляющие (Процесс, Хореография (Choreography)) благодаря использованию поддействий (sub-Activities).	См. следующие 4 фигуры
Свернутый Подпроцесс (Collapsed Sub-Process)	Диаграмма не отображает детали Подпроцесса. Знак «плюс» находится в центре нижней части фигуры, символизирующей Подпроцесс, и указывает на то, что данное действие является Подпроцессом. В данном случае детали Процесса находятся на нижнем уровне.
Развернутый Подпроцесс (Expanded Sub-Process)	Границы Подпроцесса расширены. Внутри границ просматриваются детали. Важно отметить, что Поток операций не может пересекать границ Подпроцесса.
Скрытая Подхореография (Collapsed Sub- Choreography)	Диаграмма не отображает детали Подхореографии. Знак «плюс» находится в центре нижней части дорожки с названием Задачи и указывает на то, что данное Действие является Подпроцессом. В данном случае детали Хореографии находятся на нижнем уровне.
Развернутая Подхореография (Expanded Sub- Choreography)-	Границы Подхореографии расширены. Внутри границ просматриваются детали. Важно отметить, что Поток операций не может пересекать границ Подхореографии.
Шлюз (Gateway)	Шлюзы используются для контроля расхождений и схождений множественных Потоков операций Процесса и Хореографии. Таким образом, данный термин подразумевает ветвление, раздвоение, слияние и соединение маршрутов. Могут содержать внутренние маркеры, предназначенные для дифференцировки направления потоков.
Типы Шлюзов (Gateway Control Types)	Шлюзы — фигуры в виде ромба — влияют на потоки. Выделяют следующие типы Шлюзов: Эксклюзивные условия и объединения. Могут быть исключающими и основываться на событиях. Данный тип Шлюзов может отображаться как с маркером «X», так и без него. Шлюзы, основанные на Событиях, и Параллельные Шлюзы, основанные на Событиях, инициируют появление нового экземпляра Процесса. Включающие условия и объединения. Комплексные Шлюзы, представляющие собой сложные условия и ситуации (например, 3 из 5). Параллельные Шлюзы, представляющие собой раздвоение и слияние. Шлюзы каждого из типов оказывают влияние как на входящие, так и на исходящие потоки.
Поток операций (Sequence Flow)	Поток операций служит для отображения того порядка, в котором выполняются действия Процесса или Хореографии.	См. следующие 7 фигур
Стандартный поток операций (Normal Flow)	Стандартный поток операций относится к потокам, берущим начало от Стартового события и следующим по ходу выполнения Действий.
Неконтролируемый поток операций (Uncontrolled Flow)	Неконтролируемый поток операций относится либо к потокам, на которые не воздействую никакие условия, либо к потокам, не проходящим через Шлюзы. Простейшими примерами Неконтролируемого потока операций могут послужить отдельно взятый Поток операций, объединяющий два Действия, или составной Поток операций, сходящийся в Действии или расходящийся от него. Для каждого Неконтролируемого потока операций возникает «токен», проходящий от ресурсного объекта до целевого.
Условный поток операций (Conditional Flow)	Поток операций может зависеть от условных выражений, оценивающихся согласно времени выполнения для того, чтобы определить, будет ли использоваться поток или нет (например, будет ли токен перемещаться вместе Потоком операций). В случае, если Условный поток операций является исходящим от Действия, то у основания линии изображается небольшой ромбик (см. фигуру справа). Если же Условный поток операций является исходящим от Шлюза, то никакого ромбика у основания линии не будет (см. фигуру ряда выше).
Поток операций по умолчанию (Default Flow)	Для основанных на данных Эксклюзивных и Неэксклюзивных Условий предназначен лишь один тип потоков – Условный поток операций по умолчанию. Поток операций данного типа используется в том случае, если все остальные исходящие Условные потоки операций не являются верными во время выполнения действия. Для изображения таких Потоков операций используются диагональная черточка, располагающиеся у основания линии (см. фигуру справа).
Поток исключений (Exception Flow)	Поток исключений встречается за пределами Стандартного потока операций. Основывается на Промежуточных событиях, возникающих в ходе Процесса.
Поток сообщений (Message Flow)	Поток сообщений используется для отображения потока сообщений между двумя участниками Процесса, готовыми принимать и отсылать сообщения. На диаграмме взаимодействия два отдельно взятых Пула представляют собой двух Участников Процесса (e.g., PartnerEntities and/or PartnerRoles).
Компенсирующая ассоциация (Compensation Association)	Компенсирующая ассоциация происходит за рамками Стандартного потока операций. Основой такого рода Ассоциации служит Промежуточное событие «Компенсация», инициируемое ошибкой, совершенной в ходе транзакции, либо инициирующим триггер Событием Компенсация. Целью Компенсирующей ассоциации ДОЛЖНО являться компенсирующее действие.
Объект данных (Data Object)	Однако Объект данных предоставляет информацию о том, какие действия необходимо выполнить и/или каков результат этих действий. Может изображаться как в единственном экземпляре, так и в нескольких. Входные и Выходные данные Объекта данных представляют собой одну и ту же информацию о Процессе.
Сообщение (Message)	Сообщение используется для отображения сущности взаимодействия между двумя Участниками бизнес-процесса (Участники определяются командами business PartnerRole или business PartnerEntity).
Раздвоение (Fork)	Термин «раздвоение» служит в BPMN для обозначения разделения на два или более параллельных маршрутов (данное явление также называется «И-Разделение»). Раздвоение происходит в том случае, если предпочтение отдается параллельному выполнению действий, нежели последовательному. Существуют два типа Раздвоения: Множественный исходящий поток операций (см. фигуру справа вверху) Представляет собой Неконтролируемый поток операций, являющийся предпочтительным в большинстве ситуаций. Параллельный Шлюз (см. фигуру справа ниже). Используется реже, обычно – в сочетании с другими видами Шлюзов.
Соединение (Join)	Термин «соединение» используется в BPMN для обозначения слияния двух или более параллельных маршрутов в один (данное явление также называется И-Соединение или синхронизация). Параллельный Шлюз предназначается для объединения множественных потоков.
Условие, Точка ветвления (Decision, Branching Point)	Условиями являются Шлюзы, находящиеся в рамках Процесса или Хореографии, где контрольный поток движется по одному или нескольким альтернативным маршрутам.	См. следующие 5 ячеек
Эксклюзивный шлюз (Exclusive)	Эксклюзивный шлюз представляет собой Точку ветвления, в которой выбор маршрута основывается на условных выражениях (conditional Expressions), хранимых в исходящем Потоке операций. В данном случае может быть выбран лишь один из предложенных маршрутов.
Шлюз, основанный на Событиях (Event-Based)	Данный вид Шлюзов представляет собой Точку ветвления, в которой выбор маршрута основывается на Событии, происходящем в данной точке в ходе Процесса или Хореографии. Отдельно взятое Событие, обычно являющееся получением Сообщения, определяет выбор необходимого маршрута. Также могут использоваться другие типы Событий, например, Событие «Таймер». В данном случае может быть выбран лишь один из предложенных маршрутов. Существуют два пути получения сообщения: через Задачи типа «Получение» (см. фигуру справа вверху) и Промежуточные события «Сообщение» (см. фигуру справа ниже).
Неэксклюзивный шлюз (Inclusive)	Данный вид Шлюзов представляет собой Точку ветвления, в которой выбор маршрута основывается на условных выражениях, хранимых в Исходящем потоке операций. В некотором смысле, данный вид Шлюзов является группировкой связанных между собой независимых Бинарных Шлюзов (Да/Нет). Т.к. любой из маршрутов является независимым, то МОГУТ использоваться любые сочетания маршрутов (от нуля до максимального количества комбинаций маршрутов). Однако при построении диаграмм необходимо учитывать то, что должен быть выбран хотя бы один маршрут. Для проверки того, что выбран по меньшей мере один маршрут, может быть использовано Условие по умолчанию. Существую два вида данного типа Шлюзов. Первый тип использует совокупность Условных потоков операций. На схеме выделяется при помощи небольших ромбиков (см. фигуру справа вверху). Второй тип использует Неэксклюзивные Шлюзы (см. фигуру справа ниже).
Слияние (Merging)	Термин «слияние» используется в BPMN для обозначения исключающего объединения двух или более маршрутов в один (данное явление также называется ИЛИ-Соединение). Эксклюзивный шлюз «Слияние» предназначается для отображения слияния множества потоков. В случае, если все Входящие потоки операций являются альтернативными, то необходимость в Шлюзе отпадает. Это означает, что такое же влияние на ход Процесса оказывает и Неконтролируемый поток операций (см. фигуру справа ниже).
Цикличность (Looping)	В BPMN существуют два механизма, обеспечивающих цикличность внутри Процесса.	См. следующих две фигуры
Цикличность действия (Activity Looping)	Атрибуты Задач и Подпроцессов указывают на то, будут ли они повторяться или будут выполнены единожды. Существуют два вида циклов: Стандартный и Многоэкземплярный. Графически цикличность отображается в виде небольшого маркера в центре нижней части фигуры.
Цикличность Потока операций (Sequence Flow Looping)	Циклы могут появляться благодаря присоединению Потока операций к «противоположному» объекту. Объект является противоположным в том случае, если от него направлен Исходящий поток операций, ведущий к ряду других Потоков операций, последний из которых является Входящим потоком операций для исходного объекта.
Многоэкземплярность (Multiple Instances)	Атрибуты Задач и Подпроцессов указывают на то, будут ли они повторяться или будут выполнены единожды. Три горизонтальные полоски в центре нижней части фигуры указывают на последовательную многоэкземплярность (см. фигуру справа вверху). Три вертикальные полоски в центре нижней части фигуры указывают на параллельную многоэкземплярность (см. фигуру справа ниже).
Перерыв в Процессе (что-то, способное приостановить Процесс и не подающееся управлению) (Process Break)	Перерыв в Процессе представляет собой участок Процесса, указывающий, на каком его отрезке произойдет ожидаемая задержка. Для отображения действительного хода Процесса используется Промежуточное действие (см. фигуру справа вверху). Необходимо отметить, что Артефакт Перерыва в Процессе по желанию разработчика модели или программы моделирования может быть отнесен к Событиям, что подчеркнет расположение задержки внутри потока.
Транзакция (Transaction)	Транзакция представляет собой Подпроцесс, поддерживаемый особым протоколом, гарантирующим то, что между всеми участвующими сторонами заключено соглашение о том, что действие следует либо завершить, либо отклонить. Графические элементы действия указывают на то, является ли действие соглашением. Граница, выполненная двойной линией, указывает на то, что данный Подпроцесс является Транзакцией.
Вложенный/Встроенный Подпроцесс (Nested/Embedded Sub- Process (Inline Block))	Вложенный (или встроенный) Подпроцесс представляет собой действие, имеющее тот же набор данных, что и родительский Процесс. Данный тип Подпроцесса является противоположным независимому Подпроцессу, который может быть использован заново и на который ссылается родительский Процесс. При использовании Потока операций данные должны передаваться основному, а не вложенному Подпроцессу.	На диаграмме данный вид Подпроцесса не имеет никаких особых маркеров
Группа (блок, содержащий группу объектов одной категории) (Group)	Группа предназначена для группировки графических элементов, принадлежащих одной и той же категории. Такая группировка не оказывает влияния на Поток операций. На диаграмме бизнес-процесса название категории, к которой принадлежат сгруппированные элементы, отображается в качестве названия группы. Такого рода группировка может использоваться в целях составления документации или при проведении анализа. Графически Группы отображаются так же, как и Категории объектов.
Соединитель страниц (Off-Page Connector)	На диаграмме данный графический элемент отображается там, где на предыдущей странице заканчивается Поток операций, а затем — где он возобновляется на следующей странице. В качестве соединителя страниц может использоваться Промежуточное событие «Связь». Предназначен в основном для печати.
Ассоциация (Association)	Ассоциация служит для установления связи между информацией или Артефактами (объектами, не относящимися к Элементам потока) и элементами потока. Текстовые объекты, а также графические объекты, не относящиеся к элементам потока, могут соотноситься с элементами потока. При необходимости Ассоциация может указывать направление потока (например, потока данных).
Текстовая аннотация (связана с Ассоциацией) (Text Annotation)	Текстовые аннотации являются механизмом, позволяющим разработчику модели бизнес-процесса вводить дополнительную информацию для тех, кто работает с BPMN диаграммами.
Пул (Pool)	Пул представляет собой Участника Взаимодействия. Пул также может выступать в качестве Зоны ответственности или графического контейнера, отвечающего за разделение определенного набора действий, относящихся к другим Пулам, что обычно встречается в ситуациях типа «бизнес для бизнеса» (B2B). Внутри Пула МОЖЕТ находиться дополнительная информация по выполняемому Процессу. В случае, если такой информации в Пуле не содержится, то он МОЖЕТ представлять собой «черный ящик».
Дорожка (Lane)	Дорожка используется для отображения распределения ролей и может быть как вертикальной, так и горизонтальной (также может использоваться для разделения внутреннего пространства Пула). Служит для упорядочивания и категоризации Действий.

Примените знания нотации BPMN 2.0 на практике
в Low-code BPM-системе ELMA365

<<предыдущая содержание следующая>>

Данные материалы предназначены исключительно для ознакомления в личных целях.Любое воспроизведение, копирование, а так же коммерческое и некоммерческое использование материалов должно согласовываться с авторами материалов (elma@elewise.ru). Допускается использование материалов сайта без уведомления авторов, но с явным указанием источника.