BPMN ( англ. Business Process Model and Notation , нотация и модель бизнес-процессов ) — система условных обозначений ( нотация ) и их описания в XML для моделирования бизнес-процессов . Разработана Business Process Management Initiative (BPMI.org) и поддерживается Object Management Group , после слияния обеих организаций в 2005 году. Последняя версия BPMN — 2.0 (2.0.2), предыдущая версия — 1.2.

Описание

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

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

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

Область применения

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

• Модель данных
• Организационная структура

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

За счёт строгого требования к XML-описанию модели, описания процессов в BPMN могут быть использованы для создания программного обеспечения в специальных платформах BPMS . Использования BPMS для создания приложений на базе BPMN-описания процесса развивает роль BPMN как связующего звена между бизнес-пользователями и техническими разработчиками, поскольку создаваемое программное обеспечение сохраняет визуальную составляющую процесса и исполняет его строго в соответствии с требованием спецификации.

Элементы

Моделирование в BPMN осуществляется посредством диаграмм с небольшим числом графических элементов. Это помогает пользователям быстро понимать логику процесса. Выделяют четыре основные категории элементов:

• Объекты потока управления: события, действия и логические операторы (развилки)
• Соединяющие объекты: поток управления, поток сообщений и ассоциации
• Роли: пулы и дорожки
• Артефакты: данные, группы и текстовые аннотации.

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

Объекты потока управления

Объекты потока управления разделяются на три основных типа: события (events), действия (activities) и логические операторы (gateways).

События

изображаются окружностью и означают какое-либо происшествие в мире. События инициируют действия или являются их результатами. Согласно расположению в процессе события могут быть классифицированы на начальные ( англ. start ), промежуточные ( intermediate ) и завершающие ( end ). Начиная с BPMN 1.1 различают события обработки и генерации. Ниже представлена категоризация событий по типам.

• Простые события ( plain events ) это нетипизированные события, использующиеся, чаще всего, для того, чтобы показать начало или окончание процесса.
• События-сообщения ( message events ) показывают получение и отправку сообщений в ходе выполнения процесса.
• События-таймеры ( timer events ) моделируют события, регулярно происходящие во времени. Также позволяют моделировать моменты времени, периоды и тайм-ауты.
• События-ошибки ( error events ) позволяют смоделировать генерацию и обработку ошибок в процессе. Ошибки могут иметь различные типы.
• События-отмены ( cancel events ) инициируют или реагируют на отмену транзакции.
• События-компенсации ( compensation events ) инициируют компенсацию или выполняют действия по компенсации.
• События-условия ( conditional events ) позволяют интегрировать бизнес правила в процесс.
• События-сигналы ( signal events ) рассылают и принимают сигналы между несколькими процессами. Один сигнал может обрабатываться несколькими получателями. Таким образом, события-сигналы позволяют реализовать широковещательную рассылку сообщений.
• Составные события ( multiple events ) моделирует генерацию и моделирование одного события из множества.
• События-ссылки ( link events ) используются как межстраничные соединения. Пара соответствующих ссылок эквивалентна потоку управления.
• События-остановы ( terminate events ) приводят к немедленному завершению всего бизнес процесса (во всей диаграмме).

Действия

изображаются прямоугольниками со скругленными углами. Среди действий различают задания и подпроцессы. Графическое изображение свёрнутого подпроцесса снабжено знаком плюс у нижней границы прямоугольника.

• Задание ( task ) — это единица работы, элементарное действие в процессе.
• Множественные экземпляры ( multiple instances ) действия показывают, что одно действие выполняется многократно, по одному разу для каждого объекта. Например, для каждого объекта в заказе клиента выполняется один экземпляр действия. Экземпляры действия могут выполняться параллельно или последовательно.
• Циклическое действие ( loop activity ) выполняется, пока условие цикла верно. Условие цикла может проверяться до или после выполнения действия.
• Развёрнутый подпроцесс ( expanded subprocess ) является сложным действием и содержит внутри себя собственную диаграмму бизнес-процессов.
• Свёрнутый подпроцесс ( collapsed subprocess ) также является составным действием, но скрывает детали реализации процесса.
• Ad-hoc-подпроцесс ( ad-hoc subprocess ) содержит задания. Задания выполняются до тех пор, пока не выполнено условие завершения подпроцесса.

Логические операторы (развилки)

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

• Оператор исключающего «или» , управляемый данными ( англ. data-based exclusive gateway ). Если оператор используется для ветвления, то поток управления направляется лишь по одной исходящей ветви. Если оператор используется для синхронизации, то он ожидает завершения выполнения одной входящей ветви и активирует выходной поток.
• Оператор исключающего «или» , управляемый событиями ( event-based exclusive gateway ) направляет поток управления лишь по той исходящей ветви, на которой первой произошло событие. После оператора данного типа могут следовать только события или действия-обработчики сообщений.
• Оператор включающего «или» ( inclusive gateway ) активирует одну или более исходящих ветвей, в случае, когда осуществляется ветвление. Если оператор используется для синхронизации, то он ожидает завершения выполнения всех активированных ветвей и активирует выходной поток.
• Оператор « и » ( parallel gateway ), использующийся для ветвления, разделяет один поток управления на несколько параллельных. При этом все исходящие ветви активируются одновременно. Если оператор используется для синхронизации, то он ожидает завершения выполнения всех входящих ветвей и лишь затем активирует выходной поток.
• Сложный оператор ( complex gateway ) имеет несколько условий, в зависимости от выполнения которых активируются исходящие ветви. Оператор затрудняет понимание диаграммы, так как условия, определяющие семантику оператора, графически не выражены на диаграмме. Вследствие этого использование оператора нежелательно.

Соединяющие объекты

Объекты потока управления связаны друг с другом соединяющими объектами. Существует три вида соединяющих объектов: потоки управления, потоки сообщений и ассоциации.

Поток управления

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

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

Поток сообщений

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

Ассоциации

изображаются пунктирной линией, заканчивающейся стрелкой. Ассоциации используются для ассоциирования артефактов (данных или текстовых аннотаций) с объектами потока управления.

Роли

Роли — визуальный механизм организации различных действий в категории со сходной функциональностью. Существует два типа ролей:

Пулы

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

Дорожки

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

Артефакты

Артефакты позволяют разработчикам отображать дополнительную информацию в диаграмме. Это делает диаграмму более удобочитаемой и насыщенной информацией. Существуют три предопределённых вида артефактов:

Данные

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

Группа

изображается прямоугольником с закругленными углами, граница которого — штрихпунктирная линия. Группа позволяет объединять различные действия, но не влияет на поток управления в диаграмме.

Текстовые аннотации

используются для уточнения значения элементов диаграммы и повышения её информативности.

• 
  Данные
• 
  Группа
• 
  Текстовая аннотация

Использование BPMN

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

• Частные (внутренние) бизнес-процессы
• Абстрактные (открытые) бизнес-процессы
• Процессы взаимодействия (глобальные)

Частные (внутренние) бизнес-процессы

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

Абстрактные (открытые) бизнес-процессы

Служат для отображения взаимодействия между двумя частными бизнес-процессами (то есть между двумя участниками взаимодействия) В открытом бизнес-процессе показываются только те действия, которые участвуют в коммуникации с другими процессами. Все другие, «внутренние», действия частного бизнес-процесса не показываются в абстрактном процессе. Таким образом, абстрактный процесс показывает окружающим последовательность событий, с помощью которой можно взаимодействовать с данным бизнес-процессом. Абстрактные процессы помещаются в пулы и могут моделироваться как отдельно, так и внутри большей диаграммы бизнес-процессов для отображения потока сообщений между действиями абстрактного процесса с другими элементами. Если абстрактный процесс и соответствующий частный процесс находятся в одной диаграмме, то действия, отображённые в обоих процессах, могут быть связаны ассоциациями.

Процессы взаимодействия (глобальные)

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

Пример

Ниже рассматривается пример бизнес-процесса « Регистрация на рейс ». Сначала приводится словесное описание процесса, а потом один из вариантов его представления в BPMN 1.1. Данный пример не стремится быть максимально приближённым к реальному процессу, а ставит целью показать использование конструкций нотации BPMN.

Словесное описание бизнес-процесса

Когда пассажир прибывает в аэропорт, его приоритетной задачей является регистрация на рейс. Сотрудник на стойке регистрации приветствует клиента и берёт у него документы: билет на рейс и паспорт. Если документы клиента не в порядке (например, истёк срок действия паспорта), он не может быть зарегистрирован на рейс и процесс завершается. При этом клиент получает документы обратно.

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

В итоге, пассажир получает багажную квитанцию. Сотрудник желает пассажиру приятного полёта, и процесс завершается.

Модель бизнес-процесса в BPMN

На иллюстрации, представленной ниже, показана модель бизнес-процесса «Регистрация на рейс».

BPMN 2.0

The Business Process Model and Notation — это рабочее название BPMN версии 2.0. Концепция BPMN 2.0 подразумевает создание единой спецификации, описывающей нотацию, метамодель и формат обмена моделей, но с новым именем, которое сохранило бы бренд «BPMN». Финальный вариант нотации был опубликован в январе 2011 года.

Последняя версия стандарта — BPMN 2.0.2 (январь 2014).

См. также

• BPEL
• Событийная цепочка процессов

Ссылки

• версия 1.2 спецификации BPMN
• версия 1.1 спецификации BPMN
• страница OMG о BPMN
• от 10 июля 2012 на Wayback Machine постер на русском языке, показывающий использование конструкций BPMN 1.2, а также его на английском языке
• постер на русском языке, показывающий использование конструкций BPMN 2.0, а также его на английском языке