BPMN Tutorial
Cawemo - это бесплатный онлайн-инструмент для проектирования, обсуждения и обмена BPMN-диаграммами с вашей командой.
Бизнес-модель и нотация бизнес-процессов (BPMN) это глобальный стандарт моделирования процессов и одна из важнейших составляющих успешного Business-IT-Alignment (Выравнивание Бизнеса с ИТ-бизнесом).
Все больше организаций используют BPMN, и во все большем числе университетов BPMN преподается в качестве предмета. Причины кроются именно в этом:
- Стандарт BPMN принадлежит не определенному предприятию, а учреждению (OMG), которое уже создано на основе других мировых стандартов, например, UML. Стандарт поддерживается многими программными продуктами; вы в меньшей степени зависимы от продуктов какого-либо конкретного производителя.
- Простота Принцип работы BPMN довольно прост, поэтому работать с этой нотацией можно очень быстро.
- Сила выражения При необходимости можно достаточно точно описать, как процесс функционирует с помощью BPMN. Однако это сложнее, чем просто грубое описание процесса. Такой способ точного моделирования возможен, но не является обязательным.
- Внедрение в ИТ BPMN был разработан в первую очередь для поддержки технической реализации процессов ("Автоматизация процессов"). Чем важнее IT в компании, тем полезнее становится использование BPMN.
Начнем наше учебное пособие по BPMN с довольно простой процессной диаграммы:
- Замечен голод — Начальное событие. События запуска показывают, какое событие приводит к началу процесса. Стартовые события всегда фиксируют события.
- Приобрести продукты питания — Задача. Задачи - это сердце процесса. В конце концов, что-то должно произойти, чтобы привести к желаемому результату. В BPMN задача технически входит в категорию деятельности, которая также включает в себя подпроцесс.
- Блюдо готово — Промежуточное событие. Промежуточные события представляют собой статус, который достигается в процессе и который моделируется однозначно. Они используются нечасто, но промежуточные события могут быть полезны, например, если вы рассматриваете достижение определенного статуса как веху и хотите измерить время, пока эта веха не будет достигнута. Промежуточные простые события всегда События инициаторы.
- Голод удвлетворен — Конечное событие. Конечные события отмечают состояние, достигнутое в конце пути процесса. Конечные события всегда События инициаторы.
Эта диаграмма показывает простой процесс, вызванный тем, что кто-то голоден. В результате кто-то должен купить продукты и приготовить еду. После этого кто-нибудь съест еду и утолит свой голод.
При именовании задач мы стараемся придерживаться объектно-ориентированного принципа проектирования с использованием шаблона [глагол] + [объект]. Мы бы сказали "приобретать продукты", а не "сначала позаботиться о покупке продуктов".
События относятся к тому, что уже произошло независимо от процесса (если они ловят события) или в результате процесса (если они бросают события). По этой причине мы используем [объект] и делаем [глагол] пассивным звуком, поэтому мы пишем «замечен голод».
BPMN не требует моделирования стартовых и конечных событий для процесса - их можно пропустить, но если вы моделируете стартовое событие, то вы должны моделировать конечное событие для каждого пути. То же самое относится и к конечным событиям, которые требуют стартовых событий.
Мы всегда создаем наши модели с начальными и конечными событиями по двум причинам: во-первых, таким образом можно определить триггер процесса, а во-вторых, можно описать конечное состояние каждого конца пути. Мы лишь иногда отказываемся от этой практики с подпроцессами. Подробнее об этом позже.
FAQ: Обязательно ли рисовать диаграммы BPMN по горизонтали? Что, если я предпочитаю рисовать их вертикально?
Вы всегда можете рисовать свои диаграммы сверху вниз, а не слева направо - стандарт BPMN 2.0 не запрещает это. Однако мы этого не рекомендуем: Это очень редкое явление, и опыт показывает, что люди склонны лучше понимать процесс, если он описывается так же, как и написанный текст (слева направо, по крайней мере, в западном мире).
Примеры этого учебного пособия по BPMN основаны на материалах, представленных нами для документа "BPMN 2.0 на примере" - учебного пособия по BPMN, предоставленного OMG (Скачать в формате PDF).
На этой диаграмме вы можете увидеть подготовительные шаги, которые розничный торговец оборудованием должен выполнить до того, как заказанный товар действительно может быть отправлен клиенту:
Простое стартовое событие "товар на борт" указывает на то, что эта подготовка должна быть сделана уже сейчас.
Сразу после инстанцирования процесса, как показывает параллельная развилка, параллельно выполняются две вещи: В то время как клерк должен решить, является ли это обычной почтовой или специальной посылкой (мы не определяем критерии, как это решить внутри модели процесса), работник склада уже может начать упаковывать товар.
Задача этого клерка, за которой следует Развилка «или/или» "способ доставки", является хорошим примером пояснения рекомендуемого использования для Развилки «или/или»: Развилка не несет ответственности за принятие решения о том, является ли это специальной или почтовой отправкой.
Вместо этого, это решение принимается в предыдущей деятельности. Развилка работает только как маршрутизатор, основанный на результатах предыдущей задачи, и предоставляет альтернативные пути. Задача представляет собой реальную единицу работы, в то время как развилка маршрутизирует только поток последовательностей.
Эта развилка называется " эксклюзивной ", потому что можно пройти только через одну из следующих двух ветвей: если нам нужна специальная отправка, клерк запрашивает котировки у разных перевозчиков, затем назначает перевозчика и подготавливает документы. Однако, если с обычной почтовой отправкой все в порядке, клерк должен проверить, нет ли необходимости в дополнительной страховке.
Если требуется дополнительная страховка, менеджер по логистике должен ее оформить. В любом случае, клерк должен заполнить почтовую этикетку для отправления.
Для этого сценария полезно показать развилку с включенной страховкой, потому что мы можем показать, что одна ветка всегда берется, а другая только в том случае, если требуется дополнительная страховка, но если она берется, то это может произойти параллельно с первой веткой.
Из-за такой параллельности нам нужен синхронизирующиая Развилка «и/или» прямо за 'Заполните почтовую метку' и 'Возьмите дополнительную страховку'.
В этом сценарии, Развилка «и/или» всегда будет ждать завершения "Заполнить почтовую метку", поскольку это всегда начинается.
Если требуется дополнительная страховка, инклюзивный шлюз будет также ждать " Взять дополнительную страховку", чтобы закончить.
Более того, нам также нужен синхронизирующая Развилка «и» перед последней задачей 'добавить бумажную работу и переместить груз в зону комплектации', потому что мы хотим убедиться, что все было выполнено до того, как последняя задача была выполнена.
В этом примере мы использовали только один пул и разные дорожки для людей, вовлеченных в этот процесс, что автоматически означает, что мы отбросили общение между этими людьми: Мы просто предполагаем, что они каким-то образом общаются друг с другом.
Если бы у нас был процессный механизм, управляющий этим процессом, этот механизм назначал бы пользовательские задачи и, следовательно, отвечал бы за коммуникацию между этими людьми.
Если бы у нас не было такого процессного механизма, но мы бы хотели смоделировать общение между людьми, вовлеченными в этот процесс, нам пришлось бы использовать схему взаимодействия, описанную в следующей главе.
Этот пример посвящен сотрудничеству между бизнесом и бизнесом.
Так как мы хотим явно смоделировать взаимодействие между заказчиком пиццы и поставщиком, мы классифицировали их как "участников", тем самым предоставив им специальные пулы:
Если мы пройдем по диаграмме, то начнем с покупателя пиццы, который заметил рычание своего желудка. Поэтому клиент выбирает пиццу и заказывает ее.
Давайте посмотрим поближе на процесс продавца.
Он запускается по заказу клиента, как показано в событии-сообщении, и поток сообщений, идущий от 'заказа пиццы' к этому событию. После того, как пицца была испечена, курьер доставит ее и получит оплату.
Покупатель ждет доставки пиццы.
Развилка по событиям указывает на то, что клиент на самом деле ждет двух различных событий, которые могут произойти дальше: Либо пицца доставляется, как указано в сообщении о событии, либо доставка не производится в течение 60 минут, т.е. через час клиент пропускает ожидание и звонит продавцу с просьбой доставить пиццу.
Теперь мы предполагаем, что клерк обещает, что пицца будет доставлена в ближайшее время, а клиент снова ждет пиццу, попросив еще раз через 60 минут, и так далее.
В данном примере мы используем Событие-сообщение не только для информационных объектов, таких как заказ пиццы, но и для физических объектов, таких как пицца.
Мы можем сделать это, потому что эти физические объекты на самом деле являются информационными объектами: Когда пицца прибывает к клиенту, он узнает об этом прибытии и, следовательно, знает, что пицца прибыла, что является именно целью События-сообщения в пуле клиента.
Конечно, мы можем использовать модель только таким образом, потому что этот пример не предназначен для выполнения процессным движком.
Обратите внимание, что в данном типе моделирования нет семантики по умолчанию, то есть можно не только смоделировать диаграммы сотрудничества, чтобы показать взаимодействие между деловыми партнерами, но и увеличить масштаб одной компании, смоделировав взаимодействие между различными отделами, командами или даже отдельными работниками и программными системами в диаграммах сотрудничества.
Это полностью зависит от цели модели и поэтому необходимо принять решение, будет ли полезна диаграмма сотрудничества с разными пулами, или нужно придерживаться одного пула с разными полосами, как это было показано в предыдущей главе.