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