BPMN Примеры

Рекомендации по созданию диаграмм процессов BPMN 2.0.

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

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

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

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

Мы присоединились к OMG в 2009 году как влиятельный член. С тех пор мы участвуем в разработке BPMN 2.0.

Сценарий моделированияo

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

Это очень простой пример, который покажет нам, где применять BPMN, а где нет.

Решение как диаграмма BPMN 2.0

Роли двигателя Создать счет Запрос счета Вычислить скидку Создать счет Счет создан

Объяснение

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

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

Поэтому имеет смысл разделить процессы и бизнес-правила.

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

Создать счет Сделать 2% скидку добавить 1% скидки Кто покупатель? Запрос счета Сумма заявки? Тип покупателя? Создать счет Счет создан Сделать 3% скидку Сделать 4% скидку Кто покупатель? добавить 1% скидки добавить 1% скидки 1000 - 1500 500 - 999 >2000 < 500 Тип A Тип A Тип A обычный обычный обычный

Сценарий моделирования

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

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

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

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

Решение с сигнальным событием

Creditworthiness Check Посмотреть запросы Посмотреть запущеные события ними) запуск экземпляров одного и того же клиента? и того же клиента? Првоерить кредит Проверка выполнена Проверка выполнена Запись в базуданных нет да

Объяснение

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

Решение с событием Message

Проверка кредитоспособности Проверить запросы Проверить запущенные процессы тот же клиент) запущенные экземпляры одного клиента? проверить кредит кредит подтвержден ожидать события покупателя? проверить на ожидание случаев (из тот же клиент) запуск экземпляра завершен проинформировать ожидание экземпляра База Данных База Данных нет нет да да

Объяснение

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

Решение с таймером и циклом

Creditworthiness Check Проверить запросы проверить запущенные процессы (одного пользователя) запущенные экземпляры одного клиента? perform credit check подождать немного времени проверить кредит База Данных нет да

Объяснение

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


Сценарий моделирования

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

Случаи использования

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

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

Решение как диаграмма BPMN 2.0

1й согласователь Согласование запрошено Оценить запрос прочитать и прокомментировать Задача завершена Процеесы в двигателе Подтвердить запрос подтвердить или согласовать (1я линия) Подтвердили? Запрос отклонен (1я линия) отклонить или подтвердить (2я линия) Подтвердили? Запрос отклонен (2я линия) Запрос подтвержден 2й согласователь подтвердить запрос оценить запрос прочитать и прокомментировать задача завершена нет да да нет

Объяснение

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

В пуле двигателей используются пользовательские задачи. Эти пользовательские задачи соответствуют задачам, которые показаны в списке задач 1-го и 2-го утвердителей.

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

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

Вариации

Утверждение в качестве сбитых пулов

1й согласователь 2й согласователь Движок процесса подтвердить запрос отклонить или подтвердить (1я линия) Подтвердили? Запрос отклонен (1я линия) отклонить или подтвердить (2я линия) Подтвердили? Запрос отклонен (2я линия) Запрос подтвержден нет да да нет

Определение приемника с помощью LDAP

1й согласователь подтвердить запрос оценить запрос прочитать и прокомментировать задача завершена LDAP Движок процесса подтвердить запрос отклонить или подтвердить (1я линия) Подтвердили? Запрос отклонен (1я линия) отклонить или подтвердить (2я линия) Подтвердили? Запрос отклонен (2я линия) Запрос подтвержден determine 1st and 2nd approver 2й согласователь подтвердить запрос оценить запрос прочитать и прокомментировать задача завершена нет да да нет

Сценарий моделирования

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

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

Решение как диаграмма BPMN 2.0

Адвокат Консультация Консультация запрос Предоставить совет Зарегистрировать время Запрос отработал Счетчик клиента Клиент Учет месячного дохода 1й день в месяце Определить оплачиваемые часы создать и отправить счет получить деньги Счет исполнен 14 дней Отправить напоминание Только один в месяц Несколько за месяц

Объяснение

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

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

Конечно, эти два пула не полностью независимы друг от друга. Зачем? Они работают над одними и теми же данными - листом времени клиента. Наша способность моделировать такое связанное с данным соединение очень ограничена в BPMN. Это связано с тем, что BPMN ориентирован скорее на поток управления, чем на поток данных.

Однако мы можем использовать элемент хранилища данных для моделирования этого соединения на уровне данных.

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

Адвокат Консультация Консультация запрос Предоставить совет Зарегистрировать время 1 в следующем месяце определить оплачиваемые часы создать и отправить счет Получить деньги Счет исполнен 14 дней Отправить напоминание Клиент

Объяснение, почему это неправильно

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


Сценарий моделирования

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

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

Пользоваель зашел Пользоваель зашел Движок процесса Задание для пользователя Нужна доп. информация? Запрос информации (от пользователя) ... нет да

Решение 2. Запросить информацию у технической службы

Пользоваель зашел Some Technical Service Движок процесса Задание для пользователя Нужна доп. информация? Отправить запрос Информация получена ... нет да

Ситуация

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

Решение как диаграмма BPMN 2.0

ERP Система Рынок Импортирова заказы в ERP Каждые 10 минут Собрать все заказы с рынка Процесс заказа Новый одиночный заказ Проверить данные заказа данные корректны? Импорт заказа в ERP систему Один заказ в процессе Дата заказа некорректна Все заказы в процессе отдельные Заказ нет да

Объяснение

В этом примере показан очень общий сценарий моделирования. Иногда мы называем это проблемой 1-к-n. Один экземпляр процесса (Import of Orders) приводит к множеству отдельных экземпляров процесса другого процесса (ERP-системы). Типичными конструкциями являются несколько экземпляров или циклов, которые запускают другие процессы, используя сообщения (потоки сообщений).


Сценарий моделирования

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

Решение 1: Услуга передачи сообщений и переназначение

Пользоваель зашел Движок процесса определить правопреемник задача пользователя ... правопреемник недоступен

Заметка

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

Решение 2: Правила передачи сообщений и правила переназначения

Пользоваель зашел Движок процесса определить правопреемник задача пользователя ... правопреемник недоступен

Заметка

Это имеет смысл, если движок вызывает механизм правил для определения нового правопреемника.

Решение 3. Событие границы сообщения и неявное переназначение

Пользоваель зашел Движок процесса задача пользователя ... правопреемник недоступен

Заметка

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


Сценарий моделирования

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

Решение 1. Два шлюза на основе событий

Пицца разыскивается Заказать пиццу Пицца доставлен Есть пиццу Пицца съедена 30 минут Жаловаться в сервис доставки Пицца доставлен 20 минут Заказ отменен Заказ отменен

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

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

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

Шлюз, основанный на событиях, не является интуитивным символом BPMN стандарта BPMN, необходим опыт.

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

Решение 2: Принять задание с включенными таймерами

Пицца разыскивается Заказать пиццу Есть пиццу Пицца съедена Жаловаться в сервис доставки Заказ отменен Заказ отменен Ждать пиццу Жаловаться на заказ 50 минут 30 минут

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

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

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

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

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

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

Пицца разыскивается Заказать пиццу Пицца доставлен Есть пиццу Съесть пиццу Время вышло! Жаловаться на доставку Заказ отменен Заказ отменен Выполнено задание? Таймер показал больше да нет

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

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

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

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

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


Рекомендации

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

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

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

Приведенные ниже примеры иллюстрируют проблему абстрактным примером.

Хороший пример обработки потоков

Процесс запущен выполнить первуюу задачу Обязательное действие? выполнить задачу два Процесс завершен выполнять задачу три ok? да План A План B нет

Встречный пример

Процесс запущен Задание первое Обязательное действие? perform task two Процесс завершен Задание третье Ок? да План A План Б нет

Рекомендации

Самое главное: каждый символ BPMN должен иметь ярлык.

События должны быть помечены с использованием причастия «объект + прошлое». Начальные события всегда должны маркироваться указанием триггера процесса. Конечные события должны быть помечены конечным состоянием процесса.

Сам процесс (пул) также должен всегда маркироваться. Этот ярлык должен указывать имя процесса и роль, которая его выполняет.

Задачи должны быть помечены с помощью объекта + глагол. Это заставляет модельного человека сосредоточиться на том, что действительно сделано во время задания.

Шлюзы X-OR должны быть помечены вопросом. Потоки исходящей последовательности должны быть помечены возможными ответами на эти вопросы (условия).

Хороший пример именования

Проверить дату заказаa Сервис Заказа Заказ получен Проверить заказ Проверить заказ Дата заказа корректна Дата заказа корректна? Дата заказа некорректна да нет

Общая версия

Имя процесса Роль, выполняющая процесс Триггер oпроцесса Объект + глагол Объект + Причастие Первое конечное состояние после окончания процесса Вопросы? Второе конечное состояние после окончания процесса ответ 1 ответ 2

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

Заказ сделан Старт Проверить Записать статус в БД Конец Ошибка Ок

Рекомендации

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

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

Хороший пример симметричной модели

Готовить салат Появился голод Выбрать рецепт Какое блюдо? Готовить макароны Есть еду Голод утален Готовить стейк Какие компоненты? Выбрать: - Салат - Макароны - Стейк Стейк Макароны Салат Теплая еда

Встречный пример

Готовить салат Голод появился Выбрать рецепт Какое блюдо? Готовить макароны Съесть еду Голод утален приготовить стейкk Какие компоненты? Выбрать: - Салат - Макароны - Стейк Стейк Макароны Салат теплая еда

Хороший пример симметричной модели 2

Свежий товар Заказ доставлен использован старый товар Сумма заказа более 25.000 €? Процесс заказа Организовать доставку Package goods Доставить заказ Процесс заказа да нет

Встречный пример 2

Свежая продукция Закад доставлен старый товар на складе Сумма заказа больше 25.000 €? Заказать Сделать доставку Товар Доставка заказаr Процесс заказа да нет

Рекомендации

Мы рекомендуем всегда использовать одинаковые размеры задач.

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

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

Некоторые считают, что большие задачи занимают больше времени, чем меньшие задачи - по данным BPMN это неверно.

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

Хороший пример равных размеров задач

1й согласователь подтвердить запрос оценить запрос прочитать и прокомментировать задача завершена

Встречный пример

1й согласователь Подтвердите запрос Сделан запрос документ и комментарий удалены задача завершена