Шлюзы в BPMN (gateways) это такие развилки, которые либо распараллеливают процесс на несколько потоков, либо собирают несколько потоков процесса в один.
Бизнес процесс — это последовательность действий, которая должна привести к созданию продукта или услуги. И нотация BPMN служит для моделирования именно таких процессов. Но! Иногда проще понять принцип работы того или иного инструмента на простых примерах, которые не имеют отношения к бизнесу, но зато всем знакомы. Чем я и воспользуюсь в данной статье.
Виды шлюзов BPMN
5 основных шлюзов
 | Исключаю щий шлюз (эксклюзивный, Exclusive Gateway), « или/или » — выбор только одного пути; |
 | Параллельный шлюз (Parallel Gateway), « и » — выбор всех путей; |
 | Неисключающий шлюз (неэсклюзивный, Inclusive Gateway), « и/или » — выбор одного или нескольких; |
 | Событийный шлюз (Event Gateway) — выбор первого события, которое случится; |
 | Сложный шлюз (Complex Gateway) – прочие варианты. |
2 дополнительных шлюза
Эти шлюзы используются как стартовые элементы
Схема бизнес процесса Как нарисовать схему процесса в BPMN за 2 минуты?
 | Эксклюзивный событийный шлюз (Exclusive Event-Based Gateway) — выбор одного из нескольких стартовых событий; |
 | Параллельный событийный шлюз (Parallel Event-Based Gateway) — ожидание нескольких стартовых событий. |
Подробное описание шлюзов в BPMN с примерами
1. Шлюз «ИЛИ/ИЛИ» (исключающий, Exclusive Gateway)
Графически данный шлюз отображается так или так 
1.1 Расходящаяся развилка /шлюз «или/или»
На данном шлюзе можно выбрать только один путь, по которому процесс пойдет дальше.
Когда токен поступает в расходящийся шлюз «или/или», он проходит дальше по одному из выбранных путей.
Тот путь, который отмечен штрихом называется путь «по умолчанию» (на картинке выше — «Прямо»). Этот путь будет выбран в том случае, если никакое из условий на потоках не сработало. Он может показывать «благополучный» вариант (happy path), который надо выбрать в любом случае. Или, наоборот, дополнительный исключающий путь, который обрабатывает все нестандартные ситуации.
В приведенном выше примере, если путник пойдет, например, назад, то некая невидимая сила направит его прямо.
Если бы автор процесса захотел, чтобы нестандартное действие путника приводило к его телепортации домой, то нужно было бы добавить 4-й поток управления. Затем выбрать его потоком «по умолчанию» и направить к задаче «Телепортироваться домой».
Что такое токен? Представьте, что когда процесс начинается, то в стартовом событии появляется токен. Он будет путешествовать по процессу и показывать, где мы сейчас в нем находимся. Когда этот токен будет проходить через шлюзы, то в соответствии с заданными правилами, он будет выбирать, куда ему (или им, если количество токенов увеличится) нужно двигаться дальше. Подробнее см. видео
1.2 Сходящаяся развилка/ шлюз «или/или»
Когда в сходящийся шлюз поступает токен, он пропускает дальше тоже только один токен.
Сходящийся шлюз «или/или» позволяет избежать дублирования задач, которые будут общими для разбежавшихся веток процесса. На примере выше: если выбрал направление прямо или налево, то потом надо «Найти яблочного вора».
1.3 Сходящийся и одновременно расходящийся шлюз «или/или»
Сразу отмечу, что крайне не рекомендуется использовать одни и те же шлюзы в BPMN для обоих действий (сведение и разведение потоков). Это затрудняет чтение схемы и в некоторых случаях может приводить к нарушениям в логике.
Рассмотрим еще один пример, который проиллюстрирует эту проблему.
Предположим, что документ был определен как тип А. Когда токен поступит на шлюз №2, у нас не будет результата проверки, ведь она не выполнялась. Чтобы такая ситуация обработалась корректно, надо правильно отметить «поток по умолчанию». Но до этого момента нужно будет догадываться, что усложнит чтение и понимание схемы.
Как исправить эту ситуацию? Добавить еще один шлюз «или/или»:
Теперь шлюзы расставлены корректно, и схема читается без дополнительных усилий и траты времени на понимание хитрости с потоком по умолчанию.
Подробнее про исключающие шлюзы в BPMN с применением контекста можно прочитать в этой статье.
2. Шлюз «И» (параллельный, Parallel Gateway)
Графически данный шлюз отображается так
2.1 Расходящаяся развилка/ шлюз «И» (на схеме ниже — шлюз №1)
На данном шлюзе процесс распараллеливается и идет одновременно по всем исходящим потокам. Другими словами, один токен, вошедший в такой шлюз порождает вместо себя столько токенов, сколько потоков управления выходят из шлюза. На картинке ниже этих токенов генерируется два.
2.3 Сходящаяся развилка/ шлюз «И» (на схеме выше — шлюз №2)
Этот шлюз будет собирать токены, до тех пор, пока не соберет столько, сколько потоков в него входит. Затем данный шлюз сгенерирует один токен, который отправится дальше по процессу.
2.3 Сходящийся и одновременно расходящийся шлюз «и»
Если шлюз «и» является одновременно и собирающим, и разводящим потоки (что не рекомендуется делать по правилам хорошего стиля BPMN), то он будет действовать по сумме вышеописанных правил.
Рассмотрим такой шлюз на приведенной ниже схеме «Постановка спектакля». Сначала шлюз №2 дождется пока в него поступит количество токенов, равное количеству входящих потоков — 3. Затем, когда поступят все 3, он запустит по двум исходящим потокам по одному токену.
Какие ошибки возникают при совместном использовании шлюзов «или/или» и «и»?
Самая распространенная ошибка при совместном использовании исключающего и параллельного шлюза, это использовать их в паре:
В приведенном выше варианте шлюз №1 сгенерирует два токена, которые запустят выполнение задач 1 и 2. А после того как выполнится любая из задач 1 или 2, ее токен пройдет дальше на шлюз №2 «или/или», где будет сразу пропущен дальше, чтобы запустить выполнение задачи №3. Затем, когда выполнится оставшаяся задача, ее токен тоже пройдет дальше и снова инициирует выполнение задачи №3. Таким образом, задача №3 выполнится 2 раза.
А что если шлюзы поменять местами? Сначала будет выполнена только одна из задач, так как шлюз «или/или» выбирает только 1 поток управления, по которому он запустит токен. Затем шлюз №2 будет ждать второй токен, чтобы запустить процесс дальше. И так как второй токен не был сгенерирован, то задача №3 не будет выполнена никогда.
3. Шлюз «и/или» (неисключающий, inclusive Gateway)
Графически данный шлюз отображается так
3.1 Расходящаяся развилка/шлюз «и/или»
На данном шлюзе процесс может пойти по одному (обязательно) или нескольким потокам управления.
На схеме мы проверяем, какие существуют способы коммуникации и дальше пользуемся теми, которые доступны. То есть, если в базе указан телефон и e-mail, то мы свяжемся этими двумя способами.
3.2 Сходящаяся развилка/ шлюз «и/или»
Особенностью данного шлюза является то, что он «знает» сколько токенов ему нужно получить на вход, чтобы запустить процесс дальше. Если на расходящемся шлюзе сгенерируется два токена, то сходящийся дождется двух токенов и затем сгенерирует один исходящий.
А если в пути один из токенов завершит свое «существование», то сходящийся шлюз «и/или» ждать его не будет.
4. Событийный шлюз (Event-Based Gateway)
Графически событийный шлюз отображается так
На всех потоках, исходящих из этого шлюза, обязательно должны быть события (Message, Signal, Timer, Conditional). Когда токен поступает на такой шлюз, то для каждого исходящего потока управления создается свой токен. Они останавливаются на своих событиях и ждут, когда эти события случатся. Как только случается первое событие, все остальные токены автоматически «умирают».
«Кто первый встал — того и тапки! »
Также на потоках, исходящих из этого шлюза, могут располагаться Задачи, принимающие сообщение. Важно помнить, что согласно нотации на одном событийном шлюзе нельзя одновременно использовать и события с месседжем (кружочки со значком конверта), и задачи с месседжем (прямоугольники с конвертом). Пример:
5. Эксклюзивный событийный шлюз (Exclusive Event-Based Gateway).
Этот шлюз используется как стартовый элемент. Он похож на обычный событийный шлюз, но выглядит немного иначе (с одинарной круговой линией)
Часто в программах моделирования он встречается в виде стартового события (то есть без ромба вокруг):
В каком случае может использоваться данный шлюз/старт? Если у нас есть несколько стартовых событий, которые в дальнейшем приводят к выполнению одних и тех же задач в бизнес-процесса.
Однако, если вы просто отобразите два разных старта, то смысл будет тот же самый. Такой вариант получится нагляднее, и не нужно будет пояснять значение дополнительного элемента.
6. Параллельный событийный шлюз (Parallel Event-Based Gateway)
Параллельный событийный шлюз выглядит так:
Он редко встречается в программах моделирования, а если и встречается, то обычно в виде стартового события:
Когда в стартовом событии рождается токен, он всегда создает новый экземпляр процесса. И если стартовых событий несколько (или используется эксклюзивный событийный шлюз), то каждый раз, когда случается стартовое событие, создается новый экземпляр процесса. Можно провести такую аналогию: схема процесса — это класс, а экземпляр процесса — это конкретный объект класса. Или более бытовой пример: схема — это формочка для выпекания печенья, а экземпляры — сами печеньки
Параллельный событийный шлюз (или аналогичное стартовое событие) может пригодится в ситуации, когда нам надо в уже существующий экземпляр процесса «запустить » еще один токен, по другому событию. Например, необходимо передать документы курьеру, после того как их подготовят и после того как поступят деньги от клиента. То есть оба события должны наступить, но мы не знаем в каком порядке это случатся.
Допустим, клиент перечислил деньги. Создастся новый экземпляр процесса, в котором токен из события «Деньги перечислены » переместится в шлюз «и » и будет ждать там второго токена. Затем, когда мы подготовим документы, возможны два варианта. Либо будет создан второй экземпляр процесса (если это документы для другого клиента) . Либо в нашем первом экземпляре процесса токен из события «Документы готовы » тоже переместится к шлюзу «и ». Шлюз получит на вход 2 токена и сгенерирует новый токен, который побежит по процессу дальше. То есть начнет выполняться задача «Передать документы курьеру » .
Как параллельный событийный шлюз поймет, что нужно добавить токен в уже существующий экземпляр процесса, а не создать новый экземпляр? По контексту. Например, по номеру заявки который будет известен в каждом стартовом событии.
А вот как этот процесс мог бы выглядеть, если бы мы использовали Эксклюзивный событийный шлюз вместо параллельного:
7. Сложный шлюз (Complex Gateway)
Еще один редко используемый в BPMN шлюз. Отображается он так:
Этот шлюз используется в тех ситуациях, когда все остальные шлюзы не могут отобразить логику переходов. Его крайне не рекомендуется использовать, так как к нему либо нужны будут пояснения автор схемы.
Как можно изменить эту схему, чтобы она стала понятна без лишних комментариев? Например, так:
Заключение
Для большинства процессов согласовательного уровня рекомендуется использовать 2-3 вида шлюзов («или/или » , «и » , «и/или » ), так как в этом случае схемы легче читаются и понимаются. Однако, остальные шлюзы могут сильно выручить и упростить схему аналитического уровня, если правильно их применять. А при отрисовке схем исполнительного уровня следует помнить, что не все шлюзы в BPMN поддерживаются в различных BPMS и BPM движках. Например, в Camunda не поддерживаются эксклюзивный и параллельный событийные шлюзы. Чем отличаются BPMS и BPM движки, можно прочитать тут.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Источник: bpmn2.ru
BPMN (нотация): описание процесса
Процессным подходом к организации бизнеса мир занимается уже давно и достаточно эффективно, и стандарт Business Process Model and Notation (BPMN, нотация) является процедурой продуманной с правильным описанием бизнес-процессов. Компании постоянно совершенствуют разные специализации данного стандарта и тем самым добиваются весьма существенного повышения всех качественных показателей своей работы. Нотация BPMN понятна не только для экспертов той предметной области, в которой она создавалась, её логическими выкладками может оперировать любой работник.
Моделирование и стандартизация
Одновременно с простотой эта стандартизация является наиболее полной моделью описываемого бизнес-процесса, составленной в машиночитаемой форме. BPMN (если рассматривать её в версии нотации BPMN 2.0) выстраивает модели самых сложных процессов в бизнесе очень мощно и выразительно, причём в наиболее понятной системе. Самое важное то, что вместе с этим стандартом определяются графические модели и преобразуются в прекрасно структурированную и легко читаемую машиной форму, которая основана на XML. Язык BPMN-нотации абсолютно исполняем, то есть он позволяет моделировать процессы, в дальнейшем выполняемые посредством BPMS (автоматизированные системы управления бизнес-процессами). Такая стандартизация чрезвычайно полезна именно тем, что разработчики моделей могут пользоваться одними программными продуктами, а исполнители — другими, если ими поддерживается данный стандарт.
Для построения определённой модели может использоваться не одна версия (нотация BPMN 2.0 (PDF) и другие), иногда модель составляется из фрагментов разных нотаций, но способ их систематизации и прочтения один и тот же. Всё большее количество предпринимателей внедряют в своих компаниях опирающееся на данный стандарт выполнение бизнес-процессов.
Растёт с каждым днём востребованность специалистов, которые владеют этим языком моделирования. Всё большее количество людей занято изучением графических элементов нотации BPMN и правил построения моделей. Для этого существуют специальные курсы, где желающие познакомятся с назначением этого языка, с видами диаграмм, увидят возможности автоматического выполнения построенных моделей. Самое интересное — практический опыт в нотации BPMN 2.0 (на русском языке тоже есть), моделирование и проведение анализа, разработка бизнес-процесса.
Специалисты
Кто способен заниматься описанием бизнес-процессов? BPMN-нотация моделирования легко выполняется всеми, кто связан с автоматизацией, разработкой бизнес-процессов. Это бизнес-консультанты, бизнес-аналитики, руководители проектов, системные аналитики, архитекторы и разработчики компьютерных систем, методологи, работники служб качества.
Обычно эти люди умеют читать техническую документацию по-английски, участвовали в каких-либо проектах по анализу, по описанию BPMN-нотации, оптимизировали или автоматизировали бизнес-проекты или разрабатывали, сопровождали программное обеспечение. Эта методология имеет международный статус, а не фирменный, как многие другие стандарты, и даже не национальный. Именно поэтому с 2005 года анализируют и реорганизуют бизнес с помощью моделирования процессов в нотации BPMN.
Эта методика обеспечила доступной информацией практически всех пользователей — от самых крупных аналитиков, которые создают схемы, и разработчиков, внедряющих технологии выполнения бизнес-процессов по этим схемам, до руководителей компаний, то есть обычных пользователей, которые заняты управлением и отслеживанием выполнения построенной модели. Таким образом, нотации моделирования бизнес-процессов (BPMN) устраняют расхождение между созданием модели и её реализацией. Здесь собраны лучшие идеи, имеющиеся в других методологиях. Например, для лучшей гибкости и читабельности моделирование бизнес-процессов в нотации BPMN 2.0 ведётся в традициях блок-схем.
Символы (элементы) BPMN
Поддерживает и развивает BPMN организация OMG. Это не мем интернетных завсегдатаев, обозначающий «о майн гот», а весьма знаменитая фирма Object Management Group, в которой участвуют более восьмисот компаний, разрабатывающих стандарты, подобные BPMN-нотации. Всеми полезными изменениями в новых версиях мы обязаны разработчикам OMG. Именно эта организация выбрала ключевым направлением продвижение нотации UML BPMN, с помощью которой моделируются объектно-ориентированные системы. А потому при разработке диаграмм помимо концепций и понятий (поток управления, действие, объект данных и тому подобное) в BPMN много понятий, характерных для подхода объектно-ориентированного: сообщение, обмен и поток сообщений.
Символы графической нотации разобраны по назначению и объединяются в категории. Это: Flow Objects — объекты потока, Data — данные, Swimlanes — зоны ответственности, Connecting Objects — соединяющие объекты, Artifacts — артефакты. Поток управления, объект данных и символы объектов потока дополнительно разделяются на подгруппы по семантическому признаку, чтобы отобразить специфику происходящих событий, особенности ветвления потоков, выполнение действий и так далее. Указывают специфику за счёт дополнительных графических изображений — маркеры, иконки, помещённые внутри главного символа. Также символы событий бывают с разным видом контура и фоновым цветом.
События по времени
В ходе выполнения бизнес-процесса всегда происходят самые разные и многочисленные события, которые оказывают своё влияние, несмотря на то что чаще всего являются элементами необязательными и не отображены в диаграмме бизнес-процесса. Это получение и ответ на сообщение, смена статуса в документах и многое другое, что перечислять нет смысла — множество событий происходит буквально на каждом шагу.
Чтобы их классифицировать, определяются признаки каждого. Первая группа — по времени наступления. Это стартовое событие, которое покажет начало диаграммы. Отсюда поток управления может быть только исходящим, а поток сообщений — идти в обе стороны. Стартовое событие на диаграмме бизнес-процесса обычно одно, но можно его не отображать вообще.
Иногда их даже несколько, если отображение происходит с дорожками, пулами и развёрнутыми подпроцессами. Контур события изображается тонкой одинарной линией.
Конечное событие — результат выполнения бизнес-процесса. Сюда поток управления только входит, а поток сообщений всё так же движется и на вход, и на выход. Входящий поток изображается стрелкой. Диаграмма отображает только одно конечное событие или несколько — они обведены контуром в виде жирной одинарной линии.
Промежуточное событие — это любое из остальных, которые возникают во время выполнения бизнес-процесса. Сюда входит один поток и выходит тоже один. Только Boundary (граничное событие) возникает и обрабатывается сразу — либо в самом начале, либо в конце действия. Отображается оно на контуре (границе) действия, и содержит только один поток — либо входящий, либо выходящий. А обозначается такое событие тонкой двойной линией.
События: прерывание подпроцесса и тип результата
Поскольку события во время моделирования бизнес-процесса происходят самые разные, следующим блоком были классифицированы те, которые способны прервать выполнение действия. Первыми отмечены непрерывающие события — это промежуточное или стартовое, которое возникает по ходу выполнения, однако инициирует исходящий поток, связанный с ним, только когда действие завершается.
Контур такого события изображён штриховой линией. Далее — прерывающее событие, которое возникает до стандартного действия или после него. В исключительных ситуациях это событие требует остановки или прекращения действия, если отсутствует необходимая информация или показывается ошибка в ходе обработки, если появляется необходимость дополнительных действий и тому подобное. Здесь контур отображён сплошной линией.
Третий вид событий классифицирован согласно типу результата. Прежде всего здесь нужно говорить об инициаторе обработки. Это промежуточное или стартовое событие, которое возникает как результат выполнения действий и является итогом выполнения процесса — стандартного или нет. Событие-инициатор изображено незакрашенной иконкой.
Необходимо внести в этот раздел ещё одно событие, тоже говорящее о результативности, только здесь им является результат обработки. Это промежуточное или конечное событие, возникающее в ходе выполнения действий и являющееся одним из итоговых результатов выполнения процесса — стандартного или нет, отображено оно закрашенной иконкой.
Действия
Изображаемый в виде диаграммы процесс выглядит упорядоченным набором действий, которые выполняются для получения определённого результата. На вертикальной диаграмме нотации BPMN сверху вниз задаётся последовательность, показывающая выполнение процесса по времени. Также можно проследить её по направлению стрелок соединяющих элементов слева направо. У отображаемых действий есть три главных вида и много разновидностей, каждое из которых имеет собственную иконку или значок.
Task — задача. Элементарное действие, то есть неделимое. Разновидность или специфика задачи отображается маркером или иконкой в верхнем углу слева на символе действия. Задача может быть Service (сервисная), для оказания услуги, являющейся автоматизированным приложением или веб-сервисом. Send — отправка сообщения.
Если хотя бы единожды сообщение отправлено, задача может считаться выполненной. Receive — получение сообщения (тот же принцип: если единожды получено сообщение, задача выполнена). Задача User — пользователя, считается характерной, выполняется исполнителем при помощи программного обеспечения и содействии других сотрудников.
Задача, требующая ручного исполнения, — Manual, которая исполняется без помощи автоматизации. Business-Rule — бизнес-правило, по технологии выполнение этой задачи зависит от обстоятельств, выбрать способ помогает заданность бизнес-правила. Script — сценарий, где выполнение операций строго по порядку, описанному на распознаваемом исполнителем языке. Обычно этот вид задач выполняется автоматическими средствами.
Подпроцессы
Sub-Process — подпроцесс. Он включает в себя шлюзы в нотации BPMN, потоки операций, события и много других действий. Таким образом, подпроцесс является составным действием, части которого непосредственно отображаются внутри символа на диаграмме или же выносятся на отдельную декомпозиционную диаграмму.
В последнем случае на главной диаграмме в центре подпроцесса (нижний край действия) должен отображаться знак +. Есть стандартные подпроцессы, но их недостаточно, поэтому и появились две его специфические разновидности. Это Event Sub-Process — событийный подпроцесс, который запускается всегда при появлении стартового события. Диаграмма показывает его никак не связанным с остальными действиями и потоками операций. Контур такого подпроцесса изображён точками.
Вторая разновидность — Transaction (транзакция), это состоящее из разных операций действие с удачным завершением, то есть получением положительного результата. Получить конкретный результат можно только при условии удачного завершения абсолютно всех составляющих.
Если же возникают проблемы по ходу выполнения подпроцесса, результаты всех предыдущих операций будут отменены (отмена события). Такими помехами могут стать невозможность выполнения той или иной операции или некорректное выполнение её. Чтобы не отменять предыдущие события, можно попробовать неудавшуюся операцию компенсировать (компенсация события). Контур такого подпроцесса отображён двойной сплошной линией. Для включения в диаграмму всех задач или подпроцессов, используемых повторно, существует Call — вызов, который на диаграмме обозначен жирным контуром.
Шлюзы
Шлюзы в нотации BPMN предназначены для того, чтобы указывать специфику потока операций и их пропуска по параллельным или альтернативным ветвям. Шлюз может обходиться без исходящих или входящих потоков, но всегда имеет как минимум два собственных либо входящих потока, либо исходящих. Маркер внутри его символа задаёт тип шлюза.
Это может быть Exclusive, XOR — эксклюзивный с исключающим «или», предназначенный для разделения потока на альтернативные маршруты. По ходу выполнения процесса активирован может быть только один из предлагаемых маршрутов. Условия пропуска содержатся рядом с обозначающей линией. Inclusive, OR — неэксклюзивный с логическим «или» шлюз, предназначенный для разделения потока на маршруты, где активируется каждый, если соблюдено условие истинности логического выражения, связанного с ним. В этом процессе можно выполнять несколько маршрутов, но если хоть в одном отсутствует истинность, то выбор невозможен.
Аналог неэксклюзивного шлюза — Complex (комплексный). Отличие в том, что определяющее активизацию того или иного потока операций выражение только одно. Parallel, AND — параллельный с логическим «и» шлюз нужен для ветвления или слияния параллельно выполняемых операций. Exclusive Event-Based — шлюз эксклюзивный, но основанный на событиях, разделяющих поток операций на альтернативные маршруты.
Exclusive Event-Based Gateway to start a Process — тоже эксклюзивный шлюз, события, на которых он основан, запускают весь процесс. Это начальный символ процесса или подпроцесса, входящих потоков не имеет. Таким же образом работает и Parallel Event-Based Gateway to start a Process — шлюз параллельный, также основанный на запускающих процесс событиях.
Однако при его помощи можно активировать несколько процессов одновременно, если события, связанные с ними, сработают. Входящих потоков, естественно, не имеет. На картинках ясно видна нотация BPMN в примерах построения диаграмм с двумя видами шлюзов.
Данные и потоки
Объект данных содержится и используется в диаграммах специфически, что демонстрирует применение дополнительных маркеров. Data Inputs — входные данные, то есть исходная информация для того, чтобы начать выполнение действий. Изображается на верхнем крае символа. Data Collection — набор данных, то есть целый массив или коллекция данных одного типа. Отображено снизу символа.
Объект данных и действия объединены связью с помощью ассоциации.
Стандартное изображение потока операций может быть дополнено в диаграмме указанием специфических потоков. Conditional Sequence Flow — обозначение условного потока операций при ветвлении его. Отображён исходящим из действия (если нет желания использовать в диаграмме шлюз). Default Sequence Flow — поток операций, совершающийся по умолчанию, чаще всего исходит из шлюза или действия, с логическими выражениями не связан.
Примеры и выводы
Стартовое событие, как можно заключить из названия, указывает на точку начала того или иного процесса. Это отправная начальная точка, что значит отсутствие любого вида входящего потока. Стартовое событие в примерах нотации BPMN обозначается кругом, в котором центр свободен.
Таким событием может стать письмо или звонок от клиента, например, направленный в интернет-магазин или на сайт компании, которая моделирует данный бизнес-процесс. Далее поток операций идёт по линиям и обозначает выполнение процесса вплоть до красного кружка, который обозначает завершение, конечное событие. Их, кстати, может быть и несколько, и легко проследить, где именно поток операций пришёл к концу, завершив процесс. Никакой исходящий поток из красного кружка невозможен.
Если диаграмма составляется не в цвете, то конечное событие выделяется жирной линией в форме круга. Например, на практике это событие может быть выдачей заказанного товара, который прошёл весь путь от оформления через обработку до выдачи. По ходу всей этой работы диаграмма показывает действия, которые производились на пути от стартового до конечного события.
Действие обозначается прямоугольником с закруглёнными краями. Шлюзы — ромбами. Этот язык понятен пользователям, стоит лишь слегка ознакомиться с системой отображений, которая присутствует здесь в иллюстрациях.
Источник: fb.ru
Моделирование бизнес процессов. Нотация BPMN — базовые элементы
Нотация BPMN — лучший язык моделирования бизнес процессов. Эта нотация стала результатом анализа всего опыта моделирования и других нотаций, за всю историю.
BPMN не только собрала в себе все лучшее от других нотаций, но и создала нечто совершенно новое.
Моделирование бизнес процессов начинается с нотации. А нотация начинается с изучения ее элементов. Я начинаю серию статей, посвященных моделированию бизнес процессов в нотации BPMN. Сегодня поговорим об основных элементах нотации.
Элементы нотации выглядят одинаково во всех программах. Отличаться может может только цвет заливки фигур. Но сами фигуры, толщина и форма линий — универсальна. Так что вы не перепутаете событие начала и окончания, вне зависимости от программы моделирования. Кстати, в самой нотации, все графические элементы приведены в черно-белом формате.
Базовые элементы. Нотация BPMN 2.0
Нотация BPMN — пул
Пул символизирует собой сотрудника, выполняющего определенную роль в процессе. Если вы хотите показать, что цепочка операций выполняется конкретной ролью — поместите эти операции в пул. Такое представление, позволяет очень наглядно отобразить взаимодействие между ролями, сотрудниками в процессе. Пул — это зона ответственности роли. Почему роли?
Логика очень проста — каждый сотрудник выполняет несколько ролей. Совокупность ролей, это должность. Каждая роль требует определенных знаний и навыков. Так что если вы определите роли в процессах и определите из каких ролей складывается та или иная должность, то сможете с легкостью сформировать должностные инструкции.
Нотация BPMN — пул2
Операции в пуле
А еще, с помощью пула можно отображать программное обеспечение или какой-то инструмент. Например, станок. Такой взгляд на бизнес-процесс, порой необходим. Например, вы можете отобразить взаимодействие пользователя и программы.
Только нотация BPMN имеет пулы. На мой взгляд, это очень серьезное преимущество перед другими нотациями.
Нотация BPMN — Операция
Операция (задача, активность, действие), это один из основополагающих элементов модели. Операция, это элементарное действие, которое необходимо выполнить. Элементарное — значит, не требующее детализации, декомпозиции на данном уровне, в данной модели.
Нотация BPMN — Подпроцесс
Если операция включает в себя ряд действий, которые вы хотите описать, то она становится процессом. Процесс или подпроцесс, это тоже действие, но его можно раскрыть и посмотреть что там происходит внутри.
Нотация BPMN — декомпозиция процесса
Нотация BPMN — Событие
Событие — еще один основополагающий элемент модели бизнес-процесса. События определяют ход выполнения процесса. События это то, что просто произошло. Это обстоятельство, условие, исходя из которого мы действуем дальше. События это условие «если», в цепочке «если — то». Если на улице идет дождь, то нам надо взять зонт.
Дождь — это событие, условие, которое определяет поселяющие действия в процессе. События могут быть разными:
Событие времени — истечение какого-то времени (через час) или дата/время (в 10:00)
События состояния — идет дождь, позвонил друг, упал курс доллара и т.д.
Событие сообщение — например, пришло письмо.
И т.д. Подробнее о типах событий будет написано дальше.
Нотация BPMN — промежуточные события
Дата контакта с клиентом — пример промежуточного события
События делятся на 3 типа: события начала определяют условия старта процесса, промежуточные события определяют развитие процесса и событие окончания, отражает условие, при котором мы считаем, что процесс окончен. Моделирование бизнес-процессов, начинается с определения стартовых и финишных событий. Во многих нотациях существуют события. Но только нотация BPMN сделала их конкретными.
Нотация BPMN — ветвление
Ветвление или шлюз, это логическая развилка в процессе. Если стоит развилка, значит, процесс может развиваться по-разному, в зависимости от условий. Самая простая развилка дает 2 варианта развития событий. Например, развилка «на улице идет дождь?», имеет два варианта ответа — да или нет. Соответственно от ответа, условия, зависят дальнейшие действия в процессе.
В более сложных вариантах, из развилки может исходить множество вариантов, с событиями, которые и определяют направление процесса. А еще ветвления «собирают» в себя условия, когда они все должны быть выполнены, для перехода к следующей операции процесса. Подробнее о развилках я напишу дальше.
Нотация BPMN — поток операций
Стрелка как раз соединяет операции и процессы и показывает порядок выполнения действий в процессе. Помимо порядка выполнения, стрелка может также обозначать результат предыдущего процесса, который используется в следующем. Для этого необходимо сделать подпись к стрелке.
Нотация BPMN — поток сообщений
Поток сообщений, отображает обмен информацией между участниками (пулами). Дело в том, что операции участников не могут быть соединены между собой потоком операций. Что, в принципе, логично. Вместо этого, они обмениваются сообщениями. Так что если вы хотите показать, что процесс переходит от одного участника к другому, то соедините операции потоком сообщений.
Чтобы конкретизировать сообщение, можно сделать подпись к стрелке. Подробнее дальше.
Нотация BPMN — потоки сообщений
Нотация BPMN — объект данных
Объект данных, это информация, которую необходимо отобразить в процессе. Это может быть документ, или письмо, или звонок. Кстати, с точки зрения управления бизнес-процессами, любая информация в материальном виде, является документом — запрос, электронное письмо, СМС, бумажный документ и т.д. При соединении объекта данных с операцией, необходимо учитывать направление стрелки.
Если стрелка идет от данных к операции, значит, эти данные используются для выполнения операции. Если стрелка идет от операции к объекту данных, значит, данные появляются в результате выполнения операции. Моделирование бизнес процессов без объектов данных не имеет особого смысла.
Нотация BPMN — ассоциация
Этот тип соединения используется для отображения взаимосвязи информационных объектов и баз данных с операциями. В таком случае стрелка ассоциации будет иметь направление.
Нотация BPMN — ассоциацияЕсли же порядок считывания/записи данных не имеет значения, можно установить ассоциацию без направления. Такое средние используется для соединения текстовой нотации с другими элементами. Или, например, можно отобразить взаимосвязь события и документа. Завершающее событие процесса «Отчет сформирован», может быть соединено ассоциацией с документом «Отчет».
Нотация BPMN — документ
План холодных звонков. Появляется в результате одного процесса и используется в другом
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
