BPMN Примеры
Рекомендации по созданию диаграмм процессов BPMN 2.0.
Бесплатный BPMN инструмент
Cawemo - это бесплатный онлайн-инструмент для разработки, обсуждения и обмена диаграммами BPMN с вашей командой.
Бесплатный BPMN инструментОбзор
Мы преподавали BPMN тысячам людей, и мы применяем обозначения в нашей ежедневной проектной работе с 2007 года. Ниже вы можете найти множество примеров BPMN общих проблем моделирования. Независимо от вашего конкретного проекта или вашей отрасли, есть много общих вопросов об использовании BPMN. По нашему опыту, большинство приведенных ниже примеров BPMN полезны для любого пользователя BPMN.
Мы присоединились к OMG в 2009 году как влиятельный член. С тех пор мы участвуем в разработке BPMN 2.0.
BPMN Примеры
Бизнес-правила и BPMN
Сценарий моделированияo
Предположим, мы хотим моделировать процесс в BPMN, и процесс вызывает некоторые бизнес-правила. Мы будем использовать пример создания счета. Чтобы создать счет, необходимо рассчитать скидку. Сумма заказа и тип клиента являются соответствующими критериями для расчета скидки.
Это очень простой пример, который покажет нам, где применять BPMN, а где нет.
Решение как диаграмма BPMN 2.0
Объяснение
Во время моделирования мы фокусируемся на потоке процесса. В этом примере процесс имеет два шага. Скидка рассчитывается до создания счета. Результат - очень простой процесс.
Не имеет смысла моделировать расчет самой скидки в модели BPMN (см. Пример ниже). Для дерева решений правил, для каждого дополнительного критерия, мощности будут расти экспоненциально. Это не то, что мы хотим в модели BPMN.
Поэтому имеет смысл разделить процессы и бизнес-правила.
Неправильный способ моделирования
Зависимые экземпляры
Сценарий моделирования
Предположим, мы хотим моделировать процесс с совпадающими экземплярами. Мы используем простой пример. Если выполняется одна кредитная проверка клиента, мы не хотим, чтобы еще одна кредитная проверка для одного и того же клиента была выполнена одновременно.
Причиной может быть то, что общее количество проведенных кредитных проверок влияет на результат проверки.
Предположим, что мы выполняем кредитную проверку для клиента, и мы получаем второй запрос для одного и того же клиента одновременно.
Что общего у всех решений, так это то, что каждый новый экземпляр должен проверять совпадение экземпляров на уровне данных перед началом фактической проверки кредита.
Решение с сигнальным событием
Объяснение
Событие сигнала - это самый простой и компактный способ моделирования взаимодействия между различными экземплярами. Проблема сигнала заключается в том, что он функционирует как широковещательный и не адресует какой-либо конкретный экземпляр. Итак, строго говоря, клиент игнорируется, и все ожидающие экземпляры ловят его.
Решение с событием Message
Объяснение
Это решение немного сложнее, так как вам нужно определить получателя (один экземпляр) сообщения. Это вызывает второй запрос данных до конца экземпляра. Однако это правильный способ решить проблему, возникающую в решении сигнального события.
Решение с таймером и циклом
Объяснение
В этом примере нам не нужна связь между экземплярами. Сам экземпляр проверяет периодичность, если он может перейти к проверке кредита. Недостатком является то, что это может вызвать задержки и накладные расходы из-за цикла.
Принцип четырех глаз
Сценарий моделирования
Мы хотим моделировать следующую ситуацию с использованием BPMN 2.0. Для запроса (например, оплаты) необходимы два разрешения двух разных людей. Механизм процесса должен гарантировать, что оба утверждения будут выполнены до утверждения запроса. Ручные шаги, выполняемые двумя утверждающими, также должны быть смоделированы на диаграмме BPMN. Решение об одобрении выполняется с использованием портала с списком задач.
Случаи использования
Варианты использования для этого шаблона многочисленны. Вот некоторые примеры:
- Утверждение оплаты
- Утверждение счета
- Утверждение контракта
- ...
Решение как диаграмма BPMN 2.0
Объяснение
Мы используем отдельные пулы для Process Engine, для первого утверждающего и для второго утверждающего. Таким образом, мы можем четко определить, кто контролирует какой процесс.
В пуле двигателей используются пользовательские задачи. Эти пользовательские задачи соответствуют задачам, которые показаны в списке задач 1-го и 2-го утвердителей.
Взаимодействие между задачами пользователя в двигателе и между ручным процессом утвердителей моделируется с использованием потоков сообщений. Эти потоки сообщений инкапсулируют шаги документации, которые должен выполнить утвердитель, чтобы выполнить пользовательскую задачу.
Сам список задач не моделируется, чтобы уменьшить сложность.
Вариации
Утверждение в качестве сбитых пулов
Определение приемника с помощью LDAP
Ежемесячное выставление счетов
Сценарий моделирования
В этом примере объясняется очень распространенная борьба со структурированием диаграмм BPMN 2.0. Допустим, есть адвокат, который предлагает юридические консультации своим клиентам. Услуга работает следующим образом: клиенты могут обращаться за юридической консультацией, когда им это нужно. Адвокат предоставляет запрошенный совет и ставит оплачиваемые часы на лист времени клиента. Когда месяц закончился, бухгалтер-юрист определяет оплачиваемые часы на основе расписания и создает счет-фактуру.
Этот пример иллюстрирует очень общий сценарий моделирования. Это не те шаги процессов, которые сложны, это структура диаграммы.
Решение как диаграмма BPMN 2.0
Объяснение
Наиболее важным аспектом диаграммы является ее структура.
Процесс предоставления юридических консультаций выполняется много раз в месяц. Процесс ежемесячного выставления счетов выполняется только один раз в месяц. Поэтому эти два процесса должны быть смоделированы как отдельные пулы.
Конечно, эти два пула не полностью независимы друг от друга. Зачем? Они работают над одними и теми же данными - листом времени клиента. Наша способность моделировать такое связанное с данным соединение очень ограничена в BPMN. Это связано с тем, что BPMN ориентирован скорее на поток управления, чем на поток данных.
Однако мы можем использовать элемент хранилища данных для моделирования этого соединения на уровне данных.
Неправильный способ моделирования
Объяснение, почему это неправильно
В этом примере оба процесса смешиваются в один. Это - в лучшем случае - очень неявный способ его моделирования. Это означало бы, что при каждом предоставленном юридическом консультировании счет-фактура отправляется раз в месяц. Этот способ моделирования в большинстве случаев является неправильным.
Дополнительная информация, необходимая после задачи пользователя
Сценарий моделирования
Предположим, мы хотим моделировать следующий сценарий: мы хотим выполнить пользовательскую задачу, которая выполняется пользователем на портале. После завершения пользовательской задачи может потребоваться дополнительная информация. В этом случае процессор процесса отправляет запрос информации другому пользователю (решение 1) или технической службе (решение 2).
Решение 1. Запросить информацию от другого пользователя
Решение 2. Запросить информацию у технической службы
Обработка партии заказов с рынка
Ситуация
Мы хотим моделировать следующий сценарий с использованием BPMN 2.0: предположим, что компания получает заказы от разных каналов распространения. Один из этих каналов - это рынок. В определенные промежутки времени заказы с рынка принимаются в виде партии. Каждый заказ в этой партии должен быть проверен перед ввозом в систему ERP.
Решение как диаграмма BPMN 2.0
Объяснение
В этом примере показан очень общий сценарий моделирования. Иногда мы называем это проблемой 1-к-n. Один экземпляр процесса (Import of Orders) приводит к множеству отдельных экземпляров процесса другого процесса (ERP-системы). Типичными конструкциями являются несколько экземпляров или циклов, которые запускают другие процессы, используя сообщения (потоки сообщений).
Переназначение пользовательских задач
Сценарий моделирования
Предположим, что нам нужно убедиться, что определенная пользовательская задача определенно выполнена. Поэтому задачи пользователя должны быть переназначены, как только текущий правопреемник недоступен, например, из-за отпуска или болезни.
Решение 1: Услуга передачи сообщений и переназначение
Заметка
Это имеет смысл, если движок вызывает службу для определения нового правопреемника.
Решение 2: Правила передачи сообщений и правила переназначения
Заметка
Это имеет смысл, если движок вызывает механизм правил для определения нового правопреемника.
Решение 3. Событие границы сообщения и неявное переназначение
Заметка
Это имеет смысл, если движок определяет самого нового цессионария, например, используя выражение.
Двухэтапная эскалация
Сценарий моделирования
Мы будем использовать следующий пример, чтобы проиллюстрировать, как моделировать двухэтапную эскалацию с использованием BPMN 2.0. Когда мы хотим пиццу, мы заказываем ее. Иногда доставка пиццы поднимается, и доставка занимает больше 20 минут. Затем мы жалуемся на службу доставки. После этого мы даем им еще 30 минут, чтобы доставить пиццу. Если они не сделают это своевременно, мы откажемся и отменим наш заказ.
Решение 1. Два шлюза на основе событий
Преимущества этого решения
Это решение очень четко показывает, как выполняется двухэтапная эскалация. Таймеры моделируются отдельно, а затем их соответствующие действия по эскалации.
Недостатки этого решения
Шлюз, основанный на событиях, не является интуитивным символом BPMN стандарта BPMN, необходим опыт.
Использование двух шлюзов, основанных на событиях, делает модель более крупной и приводит к дублированию сообщения о событии «Пицца».
Решение 2: Принять задание с включенными таймерами
Преимущества этого решения
Эта модель меньше, чем первое решение и, вероятно, способ, которым большинство разработчиков решат проблему на движке. Поскольку мы используем неперерывное присоединенное событие таймера, это решение является более гибким, когда речь идет о многочисленных жалобах (например, мы хотим жаловаться каждые 5 минут до истечения 50 минут).
Недостатки этого решения
Задача получения обычно не интуитивно понятна для «деловых парней», которые предпочли бы использовать события приема сообщений для такого состояния ожидания.
То, как работает прерывающий и не прерывающий таймер, требует глубокого понимания приложенных событий.
Решение 3. Один шлюз на основе событий с общим таймером
Преимущества этого решения
Эта модель представляет собой компактное и общее решение проблемы. Если речь идет о n-ступенчатой эскалации, вам понадобится этот общий подход, чтобы избежать огромных диаграмм.
Недостатки этого решения
Общее решение менее очевидно, чем другие решения. Мы не видим фактическую продолжительность таймеров, так как для обоих длительностей используется один таймер.
Для быстрого понимания двухэтапной эскалации этот метод моделирования не подходит.
BPMN Modeling Styles
Avoid Crossing Flows
Рекомендации
Этот пример BPMN - это создание хорошего макета моделей процессов. Чем лучше макет, тем выше степень понимания. Это то, чего мы хотим достичь, когда мы создаем модели процессов.
Старайтесь избегать пересечения потоков как можно больше. Это повысит понимание моделей процессов BPMN - как для опытных, так и для неопытных пользователей BPMN.
Конечно, не всегда можно полностью избежать этой проблемы. Имейте в виду, что всегда имеет смысл инвестировать некоторое дополнительное время в оптимизацию компоновки таким образом, чтобы исключить большинство пересекающихся потоков.
Приведенные ниже примеры иллюстрируют проблему абстрактным примером.
Хороший пример обработки потоков
Встречный пример
Соглашения об именах
Рекомендации
Самое главное: каждый символ BPMN должен иметь ярлык.
События должны быть помечены с использованием причастия «объект + прошлое». Начальные события всегда должны маркироваться указанием триггера процесса. Конечные события должны быть помечены конечным состоянием процесса.
Сам процесс (пул) также должен всегда маркироваться. Этот ярлык должен указывать имя процесса и роль, которая его выполняет.
Задачи должны быть помечены с помощью объекта + глагол. Это заставляет модельного человека сосредоточиться на том, что действительно сделано во время задания.
Шлюзы X-OR должны быть помечены вопросом. Потоки исходящей последовательности должны быть помечены возможными ответами на эти вопросы (условия).
Хороший пример наименования
Общая версия
Пример счетчика
Symmetric Modeling
Рекомендации
Этот пример BPMN - это создание хорошего макета моделей процессов. Чем лучше макет, тем выше степень понимания. Это то, чего мы хотим достичь, когда мы создаем модели процессов.
Мы определили, что симметричные структуры повышают понимание моделей процессов BPMN - как для опытных, так и для неопытных пользователей BPMN.
Хороший пример симметричной модели
Встречный пример
Хороший пример симметричной модели 2
Встречный пример 2
Рекомендоанная длина процесса
Рекомендации
Мы рекомендуем всегда использовать одинаковые размеры задач.
Причина проста. Люди склонны интерпретировать размеры задач, хотя они не имеют семантики в стандарте BPMN.
Некоторые считают, что более крупные задачи важнее небольших задач - согласно BPMN, это неправильно.
Некоторые считают, что большие задачи занимают больше времени, чем меньшие задачи - по данным BPMN это неверно.
Вы можете легко избежать этой путаницы, используя одинаковые размеры задач.