BPMN Документация

Начните с моделирования процессов с помощью BPMN

Бесплатный BPMN инструмент

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

Бесплатный BPMN инструмент

Модель бизнес-процесса и обозначение (BPMN) является глобальным стандартом для моделирования процессов и одним из наиболее важных компонентов успешного Бизнес-ИТ-проекта.

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

Стандартизация
BPMN не принадлежит определенному предприятию, а учреждению (OMG), который уже установлен в соответствии с другими мировыми стандартами, например UML. Стандарт поддерживается многими программными продуктами; вы менее зависимы от каких-либо продуктов конкретного поставщика.
Простота
Принцип BPMN довольно прост, поэтому вы можете очень быстро начать работу с этой нотацией.
Сила выражения
При необходимости вы можете точно описать, как работает процесс с BPMN. Однако это сложнее, чем грубо описывать процесс. Этот способ точного моделирования возможен, но не обязательно.
Внедрение в ИТ
BPMN был в основном разработан для поддержки технической реализации процессов («Автоматизация процессов»). Чем важнее ИТ в компании, тем полезнее использование BPMN.

Давайте начнем наш учебник BPMN с довольно простой диаграммы процесса:

Наведите указатель мыши на символы оранжевого цвета
Чувство голода Покупать продукты Готовить еду Еда приготовлена Кушать Голод удовлетворен

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

Наилучшая практика: соглашения об именах

При задании имен мы стараемся придерживаться принципа объектно-ориентированного проектирования использования шаблона [глагол] + [объект]. Мы бы сказали, например, «приобретать продукты», а не «сначала позаботиться о покупке продуктов».

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

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

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


Простой процесс

Примеры этого учебного курса BPMN основаны на вкладе, который мы внесли в документ «BPMN 2.0 на пример», учебник BPMN, предоставленный OMG (Скачать PDF).

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

Наведите указатель мыши на символы оранжевого цвета
Торговое оборудование Менеджер по логистике Добавить доп. страхование Менеджер Проверить тредуется ли доп.страховка Заполнить почтовую метку Решить, отправить обычно или спец.доставкой Отправить запрос от перевозчика Метод доставки Доставка товаров Выбрать перевозчика и подготовить документы Warehouse Worker Товары Доставить товары на место Товары доставлены Страховка включена Всегда Нужно доп. страхование Обычная доставка Спец.доставка

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


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

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

Наведите указатель мыши на символы оранжевого цвета
Заказчик пиццы Хочу пиццу Выбрать пиццу Заказать пиццу Пицца доставлена 60 минут Где пицца?! Оплатить пиццу Съесть пиццу Голод утален Пиццерия Повар Готовить пиццу Менеджер Заказ получен "Где моя пицца?" Успакоить клиента Доставка Получить оплату Доставить пиццу

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