Графическое моделирование бизнес процессов в нотации epc. Моделирование бизнеса — IDEF, UML, ARIS. Основные понятия и группы объектов в BPMN

«В какой нотации нам лучше строить свои бизнес-процессы? » — довольно частый и один из самых странных вопросов, которые мне приходилось слышать. Дело в том, что выбор нотации для бизнес-моделирования целиком и полностью зависит от целей и задач предприятия, которое решило перейти к процессному управлению.

Ещё раз об IDEF0

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

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

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

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

BPMN – новый взгляд на процессы

BPMN – относительно новая нотация, первая версия которой появилась в 2005 году. Нотация ориентирована на детальное описание потоков работ, и наилучшим образом подходит для моделирования процессов на нижнем уровне. Нотация BPMN обладает одной ключевой особенностью — все диаграммы, построенные с соблюдением спецификации BPMN могут быть «выполнены» системой в режиме реального времени.

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

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

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

FlowChart – назад к основам

На самом деле нотации с таким названием не существует, имеется множество вариаций на тему обычной блок-схемы, например, Basic FlowChart, Сross Functional Flowchart и т.д.. Все эти нотации позволяют описывать потоки работ и распределять ответственность за выполняемые функции внутри процесса. Множество программных продуктов используют разновидности этих нотаций для описания процессов нижнего уровня в дополнение к описанию процессов верхнего уровня при помощи IDEF0.

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

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

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

eEPC – мы пойдём своим путём

Авторами нотации eEPC является известная немецкая фирма IDS Scheer AG. Как и нотации на базе FlowChart, eEPC предназначена для описания процессов нижнего уровня, вот только в основе неё лежат не функции персонала, а события, которые в свою очередь уже инициируют выполнение какого-либо действия со стороны персонала. Из-за данной особенности стандартные процессы получаются почти в два раза больше по сравнению с их аналогами, описанными в нотации FlowChart.

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

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

Разумеется, данная заметка не презентует на полноту изложения и не раскрывает особенности использования каждой нотации в отдельности, зато надеюсь, что после прочтения данной статьи, вопросов в стиле «Что нам выбрать BPMN или IDEF0? » станет меньше.

8.8. Методология BPMN

Модель и нотация бизнес-процессов (BPMN, Business Process Model and Notation) – методология моделирования, анализа и реорганизации бизнес-процессов. Разработана Business Process Management Initiative (BPMI), с 2005 г. поддерживается и развивается Object Management Group (OMG) . В отличие от других методологий бизнес-моделирования, имеющих статус «фирменного» () или «национального» () стандарта, BPMN получила «международный» статус – Международная организация по стандартизации опубликовала стандарт «ISO/IEC 19510:2013. Information technology - Object Management Group. Business Process Model and Notation».

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

По заявлению разработчиков стандарта BPMN, он вобрал в себя лучшие идеи, что имеются в следующих нотациях и методологиях моделирования:

o EDOC (Enterprise Distributed Object Computing, корпоративная распределенная обработка объектов) – Business Processes (бизнес-процессы);

EbXML (Electronic Business eXtensible Markup Language, расширяемый язык разметки для электронного бизнеса) BPSS (Business Process Specification Schema, схемы спецификации бизнес-процессов);

ADF (Activity-Decision Flow, поток «деятельность-результат») Diagram;

LOVEM (Line of Visibility Engineering Methodology, визуальная методология проектирования);

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

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

Элементы (символы) графической нотации BPMN по назначению объединены в категории:

Объекты потока (Flow Objects);

Данные (Data);

Зоны ответственности (Swimlanes);

Соединяющие элементы (Connecting Objects);

Артефакты (Artifacts).

В следующей таблице приведены символы нотации BPMN и их базовое изображение.

Таблица 8.3. Условные обозначения на BPMN-диаграммах

№ п/п	Символ	Наименование	Примечания
1. СИМВОЛЫ ОБЪЕКТОВ ПОТОКА
1.1		Событие (Event)	Факт (ситуация, набор условий или обстоятельств), который активирует или оказывает влияние на дальнейшее развитие одного или более процессов. Событие инициируют действия или являются их результатами. В отличие от функции, выполнение которой занимает определенный промежуток времени, событие относится к конкретной точке во времени.
1.2		Действие, деятельность (Activity)	Действие или набор действий, выполняемых исполнителем в ходе процесса. Помимо наименования действия вверху и внизу символа могут указываться имена участников.
1.3		Шлюз, логический оператор (Gateway)	Используется для обозначения слияния и/или ветвления потока событий и действий.
1.4		Обмен сообщениями (Conversation)	Описание действия, характеризующего обмен информацией между участниками (пулами) взаимодействия.
2. СИМВОЛЫ ДАННЫХ
2.1		Объект данных (Data Objects)	Товарно-материальные ценности (ТМЦ) или информация, используемые или получаемые в результате действий.
2.2		Хранилища данных (Data Stores)	База данных или ее фрагмент, содержащий информацию для выполнения действий.
2.3		Сообщение (Message)	Отражает факт передачи информации между участниками процесса.
3. СИМВОЛЫ ЗОНЫ ОТВЕТСТВЕННОСТИ
3.1		Пул, участник (Pool, Participant)	Структурное подразделение, которому поручено выполнение действия (фирма, организация, отдел, служба).
3.2		Дорожка (Lane)	Должность исполнителя или роль субъекта, которому поручено выполнение действия. Составная часть организационной единицы.
4. СИМВОЛЫ СОЕДИНЯЮЩИХ ЭЛЕМЕНТОВ (ЛИНИЙ)
4.1		Поток операций, поток управления (Sequence Flow)	Задает последовательность (до-после) возникновения событий и выполнения действий.
4.2		Поток сообщений (Message Flow)	Отражает информационный обмен между участниками процесса. Обычно соединяет действия и/или пулы двух участников процесса.
4.3		Ассоциация (Association)	Отражает связь между данными (артефактами) и объектами потока.
4.4		Ссылка на обмен сообщениями (Conversation Link)	Указывает на обмен сообщениями между участниками взаимодействия.
5. СИМВОЛЫ АРТЕФАКТОВ (СПЕЦИАЛЬНЫЕ СИМВОЛЫ)
5.1		Группа (Group)	Используется для группировки графических элементов, принадлежащих одной и той же категории.
5.2		Комментарий, текстовая аннотация (Text Annotation)	Примечание (дополнительная информация), связанная с отображенным элементом.

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

Ниже приводится описание специфики отображения символов и их семантическая интерпретация.

1. События.

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

Все события классифицируются по следующим признакам:

По времени наступления:

o стартовое событие – инициирует начало процесса (диаграммы). Из стартового события поток управления может только исходить, а поток сообщений - как входить, так и исходить. На диаграмме процесса, как правило, отображается только одно стартовое событие, но оно может отсутствовать или их может быть несколько при отображении процесса с пулами, дорожками или развернутыми подпроцессами. Контур события отображается одинарной тонкой линией;

o конечное событие – является результатом выполнения процесса. В конечное событие поток управления может только входить, а поток сообщений - как входить, так и исходить. В конечное событие может только входить поток (стрелка). На диаграмме конечное событие, как и стартовое, может быть одно, несколько (даже при отсутствии пулов и дорожек) или ни одного. Контур события отображается одинарной жирной линией;

o промежуточное событие – все остальные события, возникающие в ходе выполнения процесса. В промежуточное событие обязательно должен входить и выходить один поток. Исключение составляет граничные (Boundary) события, возникающие и обрабатываемые непосредственно либо в самом начале действия либо в его конце. Такие события отображаются на границе (контуре) действия и у них может быть только либо входящий либо исходящий поток. Контур события отображается двойной тонкой линией;

По возможности прерывания выполнения действия (подпроцесса):

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

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

По типу результата действия:

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

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

По причине возникновения (триггеру) – см. табл. 8.4:

Таблица 8.4. Условные обозначения событий на BPMN-диаграммах

Причина (триггер) события	Стартовое событие (Start event)			Промежуточное событие (Intermediate event)				Конечное событие (End event)	Примечания
	высокого уровня (Top-Level)	прерывающее подпроцесс (Sub-Process Interrupting)	непрерывающее подпроцесс (Sub-Process Non-Interrupting)	инициатор обработки (Catching)	прерывающее, возникающее на границе действия (Boundary Interrupting)	непрерывающее, возникающее на границе действия (Boundary Non-Interrupting)	результат обработки (Throwing)
Неопределенное (None)									Нетипизированное событие. Используется, чаще всего, для отображения начала или окончания процесса.
Сообщение (Message)
Таймер (Timer)									Моделирует события, происходящие по расписанию (в определенные моменты или периоды времени). Также позволяют моделировать таймауты (перерывы в ходе выполнения процесса).
Ошибка (Error)									Отражает факт возникновения и/или обработки ошибки в процессе. Ошибки могут иметь различные типы.
Прерывание, эскалация (Escalation)									Отражает факт возникновения и/или обработки некоторой ситуации, требующей немедленной реакции. Более общая ситуация, чем ошибка, т.к. может привести к положительному завершению процесса.
Отмена (Cancel)
Компенсация (Compensation)									Инициирует вспомогательные действия, компенсирующие неудачное завершение (прерывание) процесса.
Условие (Conditional)									Показывает получение и отправку сообщений в ходе выполнения процесса.
Связь (Link)									Отражает факт неудачного завершения (прерывания) процесса.
Сигнал (Signal)									Отражает факт рассылки или приема сигналов несколькими процессами. Один сигнал может обрабатываться несколькими получателями. Таким образом, события-сигналы позволяют реализовать широковещательную рассылку сообщений.
Завершение (Terminate)									Отражает факт немедленного завершения всего процесса.
Множественное (Multiple)									Отражает факт возникновения одного события из некоторого множества.
Параллельно-множественное (Parallel Multiple)									Отражает факт возникновения всех событий из некоторого множества.

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

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

На рис. 8.10 отображена диаграмма с несколькими конечными и граничными событиями, а также различные типы событий по возможности прерывания выполнения действия (прерывающие и непрерывающее).

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

2. Действие.

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

Различают три основных вида действий и их разновидности :

Задача (Task) – элементарное (неделимое, атомарное) действие. Специфика (разновидность) задачи может быть отображена иконкой (маркером) в левом верхнем углу символа действия:

o - сервисная (Service). Задача предназначена для оказания услуги, которая может являться как веб-сервисом, так и автоматизированным приложением;

o - отправка сообщения (Send). Задача считается выполненной, если сообщение послано хотя бы один раз;

o - получение сообщения (Receive). Задача считается выполненной, если сообщение получено хотя бы один раз;

o - пользовательская (User). Характерная задача, выполняемая исполнителем при содействии других людей или программного обеспечения;

o - ручное исполнение (Manual). Характерная задача, выполняемая исполнителем без каких-либо средств автоматизации;

o - бизнес-правило (Business-Rule). Задача, технология выполнения которой зависит от текущих обстоятельств и выбирается на основе заданного бизнес-правила;

o - сценарий (Script). Задача, порядок выполнения операций которой описан на языке, распознаваемом исполнителем. Обычно используется для задач, выполняемых автоматическими средствами;

Подпроцесс (Sub-Process) – составное действие, включающее в себя другие действия, шлюзы, события и потоки операций. Части подпроцесса могут непосредственно отображены на диаграмме внутри символа действия или вынесены на отдельную диаграмму декомпозиции. Во втором случае на родительской диаграмме в центре нижнего края действия (подпроцесса) отображается символ + . Кроме стандартных подпроцессов, имеется еще две специфические его разновидности:

o - событийный подпроцесс (Event Sub-Process). Запускается каждый раз, когда происходит одно из стартовых событий. На диаграмме событийный подпроцесс не связан с другими действиями потоками операций. Контур подпроцесса отображается точками;

o - транзакция (Transaction). Действие, состоящее из составных операций, удачное завершение (получение конкретного положительного результата) которого возможно при удачном завершении всех его составляющих. В случае возникновения проблем при выполнении подпроцесса (невозможности выполнения одной из операций или высокой вероятности ее некорректного выполнения) результаты предыдущих операций отменяются (событие отмена) или компенсируются (событие компенсация). Контур подпроцесса отображается двойной сплошной линией;

Вызов (Call). Позволяет включать в состав диаграммы повторно используемые задачи и подпроцессы. На диаграмме выделяется жирным контуром.

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

Цикл (Loop). Действие выполняется в цикле с пред- (while) или пост- (repeat-until) условием;

- ||| или ≡ - многоэкземплярность (Multi-Instance). Параллельное или последовательное выполнение нескольких экземпляров однотипных действий. При последовательном выполнении действие можно рассматривать как цикл с параметром (for);

Компенсация (Compensation). Действие выполняется взамен стандартного при невозможности его удачного завершения;

- ~ - настраиваемый подпроцесс (Ad-Hoc). Указывается только для подпроцессов. Конкретный состав и последовательность входящих в него действий определяется исполнителем в процессе его выполнения.

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

3. Шлюз.

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

- , – эксклюзивный (Exclusive, XOR – исключающее ИЛИ). Предназначен для разделения потока операций на несколько альтернативных маршрутов, т.е. в ходе выполнения процесса может быть активирован только один из предложенных маршрутов. Условия пропуска по исходящему маршруту задается рядом с соответствующей линией в виде логического выражения;

- – неэксклюзивный (Inclusive, OR – логическое ИЛИ). Предназначен для разделения потока операций на несколько маршрутов, каждый из которых активируется при условии истинности связанного с ним логического выражения. Таким образом, при выполнении процесса может быть выбрано сразу несколько маршрутов, в т.ч. и ни одного в случае ложности всех выражений;

- – комплексный (Complex). Аналогичен неэксклюзивному шлюзу. Отличие заключается в том, что с ним связано одно выражение, которое определяет, какие из потоков операций будут активированы;

- – параллельный (Parallel, AND – логическое И). Предназначен для слияния/ветвления одновременно (параллельно) выполняемых потоков операций;

- – эксклюзивный, основанный на событиях (Exclusive Event-Based). Предназначен для разделения потока операций на несколько альтернативных маршрутов. Единственный маршрут, по которому будет продолжен процесс, выбирается не на основе логического выражения, а в зависимости от произошедших событий, которые указываются по соответствующему маршруту;

- – эксклюзивный, основанный на событиях, запускающий процесс (Exclusive Event-Based Gateway to start a Process). Аналогичен предыдущему, но используется в качестве начального символа процесса (подпроцесса). Не имеет входящих потоков;

- – параллельный, основанный на событиях, запускающий процесс (Parallel Event-Based Gateway to start a Process). Аналогичен предыдущему, но возможна активация сразу нескольких маршрутов в случае срабатывания событий, с которыми они связаны. Возможно асинхронное выполнение маршрутов (связанных потоков операций и действий). Т.е. после активации и начала выполнения одного из маршрутов, другие маршруты тоже могут быть активированы и выполнены, пока не наступил момент завершения процесса (подпроцесса). Не имеет входящих потоков.

На рис. 8.11 показан пример диаграммы с двумя различными типами шлюзов (эксклюзивным и основанным на событиях).

Рис. 8.11. Пример использование различных типов шлюзов

4. Объект данных.

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

- – входные данные (Data Inputs). Исходные ТМЦ или информация для выполнения действий. Отображается у верхнего края символа;

- – выходные данные (Data Outputs). Результат действия. Отображается у верхнего края символа;

- ||| – набор данных (Data Collection). Коллекция или массив однотипных данных. Отображается у нижнего края символа.

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

5. Потоки операций.

В дополнение к стандартному изображению потока операций, на диаграмме могут быть указаны специфические потоки:

- – условный поток операций (Conditional Sequence Flow). Используется при ветвлении потоков. Обычно отображается исходящим из действия, чтобы не отображать на диаграмме шлюз. Условия активации потока задается рядом в виде логического выражения;

- – поток операций по умолчанию (Default Sequence Flow). Используется при ветвлении потоков. Может исходить из действия или шлюза. Не связан ни с каким логическим выражением. Поток по умолчанию активируется, если активация других потоков в соответствии с их логическими выражениями или событиями невозможна.

На рис. 8.12 показан пример диаграммы со специфическими потоками управления (условным и по умолчанию).

Рис. 8.12. Пример использование специфических потоков управления

Все многообразие процессов и способов взаимодействия между их участниками в BPMN поделено на типы (sub-model). Каждому из типов соответствует своя семантика и набор отображаемых элементов.

Таблица 8.5. Разновидности диаграмм (типы процессов) BPMN

Наименование диаграммы (процесса)			Назначение		Примерный вид
Диаграмма процесса (Process Diagram)	Частный (внутренний) бизнес-процесс (Private (internal) Business Process)	неисполняемый (Non-executable)	Процесс, выполняемый одним участником без указания на диаграмме других участников взаимодействия. Степень детализации (абстракции) участник процесса может быть произвольным (организация, отдел, сотрудник). Допускается использование на диаграмме пула, а внутри него дорожек, но потоки операций и сообщений не должны выходить за рамки пула.	Используется для высокоуровневого моделирования процесса. Отображен на диаграмме в общем виде, т.е. с такой степенью детализации, что его выполнение в реальных условиях по схеме, отображенной на диаграмме, как правило, невозможно из-за отсутствия описания возможных нюансов его исполнения. В частности, на диаграмме обычно отсутствуют шлюзы и условные выражения.
		исполняемый (Executable)		Используется для детализированного (обстоятельного) моделирования с описания всех возможных нюансов выполнения процесса.
	Публичный (открытый) процесс (Public Process)		Используется для отображения взаимодействия между частным процессом и другим процессом или участниками, отображенным в виде свернутых пулов.
Диаграмма хореографии (Choreography Diagram)			Используется для отображения частного процесса в виде действий, подразумевающих обмен сообщениями. Вверху и внизу символа действия указываются участники обмена сообщениями, с которыми непосредственно связаны отсылаемые/получаемые сообщения. Инициатор конкретного взаимодействия и его сообщение на диаграмме отображаются без заливки, принимающая сторона (обработчик запроса) и его сообщение (ответ) - с заливкой.
Диаграмма взаимодействия (Collaboration Diagram)	процессов (Process)		Используется для отображения состава и последовательности выполнения двух и более процессов в виде пулов с указанием взаимодействия между их составляющими через потоки сообщений.
	посредством обмена сообщениями (A view of Conversations)		Используется для отображения взаимодействия между участниками процесса через наборы потоков сообщений. Набор потоков сообщений представляется в виде символа обмена сообщениями, связанного ссылками с участниками информационного взаимодействия.

На следующих рисунках показаны примеры диаграмм разного типа из стандарта BPMN 2.0, построенные для одного и того же процесса.

Рис. 8.13. Диаграмма внутреннего процесса

Рис. 8.14. Диаграмма открытого процесса

Рис. 8.15. Диаграмма взаимодействия процессов

Рис. 8.16. Диаграмма хореографии

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

1. Несмотря на тот факт, что события – необязательные элементы на диаграммах, рекомендуется отображать начальные и конечные события. У одного процесса (пула, дорожки, развернутого подпроцесса) должно быть только одно начальное событие, но может быть несколько конечных событий.

2. На диаграмме не должны присутствовать элементы без единой связи.

3. В отличие от EPC-диаграмм, допускается последовательное следование нескольких событий или процессов подряд.

4. Каждый шлюз слияния должен обладать минимум двумя входящими связями, шлюз ветвления - минимум двумя исходящими.

5. Ветвление на альтернативные потоки по логическим выражениям («исключающее ИЛИ» или логическое «ИЛИ») можно отобразить через соответствующий шлюз (эксклюзивный, неэксклюзивный или комплексный) или с использованием специфических потоков операций.

Рис. 8.17. Примеры ветвления на альтернативные потоки по логическим выражениям

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

Рис. 8.18. Примеры ветвления на альтернативные потоки в зависимости от произошедших событий

7. Шлюз, разветвляющий ветки, и шлюз, объединяющий эти ветки, должны совпадать. Допускается также ситуация, когда шлюз ветвления «И», шлюз объединения – «ИЛИ».

Примеры допустимых и недопустимых ситуаций приведены на следующем рисунке.

а) допустимые ситуации

б) недопустимые ситуации

Рис. 8.19. Примеры допустимого и недопустимого использования шлюзов

8. Количество пересечений линий следует минимизировать. При этом считается, что пересекающиеся линии не имеют логической связи друг с другом. Другими словами, потоки в местах пересечений не меняют своего направления.

8.10. Примеры построения BPMN-диаграмм для расчета допускаемых скоростей

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

Процессным подходом к организации бизнеса мир занимается уже давно и достаточно эффективно, и стандарт Business Process Model and Notation (BPMN, нотация) является процедурой продуманной с правильным описанием бизнес-процессов. Компании постоянно совершенствуют разные специализации данного стандарта и тем самым добиваются весьма существенного повышения всех качественных показателей своей работы. Нотация BPMN понятна не только для экспертов той предметной области, в которой она создавалась, её логическими выкладками может оперировать любой работник.

Моделирование и стандартизация

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

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

Специалисты

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

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

Символы (элементы) BPMN

Поддерживает и развивает BPMN организация OMG. Это не мем интернетных завсегдатаев, обозначающий "о майн гот", а весьма знаменитая фирма Object Management Group, в которой участвуют более восьмисот компаний, разрабатывающих стандарты, подобные BPMN-нотации. Всеми полезными изменениями в новых версиях мы обязаны разработчикам OMG. Именно эта организация выбрала ключевым направлением продвижение нотации UML BPMN, с помощью которой моделируются объектно-ориентированные системы. А потому при разработке диаграмм помимо концепций и понятий (поток управления, действие, объект данных и тому подобное) в BPMN много понятий, характерных для подхода объектно-ориентированного: сообщение, обмен и поток сообщений.

Символы графической нотации разобраны по назначению и объединяются в категории. Objects - объекты потока, Data - данные, Swimlanes - зоны ответственности, Connecting Objects - соединяющие объекты, Artifacts - артефакты. Поток управления, объект данных и символы объектов потока дополнительно разделяются на подгруппы по семантическому признаку, чтобы отобразить специфику происходящих событий, особенности ветвления потоков, выполнение действий и так далее. Указывают специфику за счёт дополнительных графических изображений - маркеры, иконки, помещённые внутри главного символа. Также символы событий бывают с разным видом контура и фоновым цветом.

События по времени

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

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

События: прерывание подпроцесса и тип результата

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

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

Действия

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

Task - задача. Элементарное действие, то есть неделимое. Разновидность или специфика задачи отображается маркером или иконкой в верхнем углу слева на символе действия. Задача может быть Service (сервисная), для оказания услуги, являющейся автоматизированным приложением или веб-сервисом. Send - отправка сообщения. Если хотя бы единожды сообщение отправлено, задача может считаться выполненной. Receive - получение сообщения (тот же принцип: если единожды получено сообщение, задача выполнена). Задача User - пользователя, считается характерной, выполняется исполнителем при помощи программного обеспечения и содействии других сотрудников. Задача, требующая ручного исполнения, - Manual, которая исполняется без помощи автоматизации. Business-Rule - бизнес-правило, по технологии выполнение этой задачи зависит от обстоятельств, выбрать способ помогает заданность бизнес-правила. Script - сценарий, где выполнение операций строго по порядку, описанному на распознаваемом исполнителем языке. Обычно этот вид задач выполняется автоматическими средствами.

Подпроцессы

Sub-Process - подпроцесс. Он включает в себя шлюзы в нотации BPMN, потоки операций, события и много других действий. Таким образом, подпроцесс является составным действием, части которого непосредственно отображаются внутри символа на диаграмме или же выносятся на отдельную декомпозиционную диаграмму. В последнем случае на главной диаграмме в центре подпроцесса (нижний край действия) должен отображаться знак +. Есть стандартные подпроцессы, но их недостаточно, поэтому и появились две его специфические разновидности. Это Event Sub-Process - событийный подпроцесс, который запускается всегда при появлении стартового события. Диаграмма показывает его никак не связанным с остальными действиями и потоками операций. Контур такого подпроцесса изображён точками.

Вторая разновидность - Transaction (транзакция), это состоящее из разных операций действие с удачным завершением, то есть получением положительного результата. Получить конкретный результат можно только при условии удачного завершения абсолютно всех составляющих. Если же возникают проблемы по ходу выполнения подпроцесса, результаты всех предыдущих операций будут отменены (отмена события). Такими помехами могут стать невозможность выполнения той или иной операции или некорректное выполнение её. Чтобы не отменять предыдущие события, можно попробовать неудавшуюся операцию компенсировать (компенсация события). Контур такого подпроцесса отображён двойной сплошной линией. Для включения в диаграмму всех задач или подпроцессов, используемых повторно, существует Call - вызов, который на диаграмме обозначен жирным контуром.

Шлюзы

Шлюзы в нотации BPMN предназначены для того, чтобы указывать специфику потока операций и их пропуска по параллельным или альтернативным ветвям. Шлюз может обходиться без исходящих или входящих потоков, но всегда имеет как минимум два собственных либо входящих потока, либо исходящих. Маркер внутри его символа задаёт тип шлюза. Это может быть Exclusive, XOR - эксклюзивный с исключающим "или", предназначенный для разделения потока на альтернативные маршруты. По ходу выполнения процесса активирован может быть только один из предлагаемых маршрутов. Условия пропуска содержатся рядом с обозначающей линией. Inclusive, OR - неэксклюзивный с логическим "или" шлюз, предназначенный для разделения потока на маршруты, где активируется каждый, если соблюдено условие истинности логического выражения, связанного с ним. В этом процессе можно выполнять несколько маршрутов, но если хоть в одном отсутствует истинность, то выбор невозможен.

Аналог неэксклюзивного шлюза - Complex (комплексный). Отличие в том, что определяющее активизацию того или иного потока операций выражение только одно. Parallel, AND - параллельный с логическим "и" шлюз нужен для ветвления или слияния параллельно выполняемых операций. Exclusive Event-Based - шлюз эксклюзивный, но основанный на событиях, разделяющих поток операций на альтернативные маршруты. Exclusive Event-Based Gateway to start a Process - тоже эксклюзивный шлюз, события, на которых он основан, запускают весь процесс. Это начальный символ процесса или подпроцесса, входящих потоков не имеет. Таким же образом работает и Parallel Event-Based Gateway to start a Process - шлюз параллельный, также основанный на запускающих процесс событиях. Однако при его помощи можно активировать несколько процессов одновременно, если события, связанные с ними, сработают. Входящих потоков, естественно, не имеет. На картинках ясно видна нотация BPMN в примерах построения диаграмм с двумя видами шлюзов.

Данные и потоки

Объект данных содержится и используется в диаграммах специфически, что демонстрирует применение дополнительных маркеров. Data Inputs - входные данные, то есть исходная информация для того, чтобы начать выполнение действий. Изображается на верхнем крае символа. Data Collection - набор данных, то есть целый массив или коллекция данных одного типа. Отображено снизу символа. Объект данных и действия объединены связью с помощью ассоциации.

Стандартное изображение потока операций может быть дополнено в диаграмме указанием специфических потоков. Conditional Sequence Flow - обозначение условного потока операций при ветвлении его. Отображён исходящим из действия (если нет желания использовать в диаграмме шлюз). Default Sequence Flow - поток операций, совершающийся по умолчанию, чаще всего исходит из шлюза или действия, с логическими выражениями не связан.

Примеры и выводы

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

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

BPMN (Business Process Management Notation) – это язык моделирования бизнес-процессов, который является промежуточным звеном между формализацией/визуализацией и воплощением бизнес-процесса.

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

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

Как максимум, позволяет впоследствии провести автоматизацию бизнес-процессов в соответствии с имеющейся схемой.

История возникновения BPMN

Первая версия нотации BPMN вышла в мае 2004 года (BPMN 1.0). Следующая версия появилась в январе 2011 года (BPMN 2.0). Наконец, в январе 2013 года компания OMG выпустила ту версию, которая в основном используется и сегодня – BPMN 2.0.2.

Основные графические элементы BPMN

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

Элементы нотации BPMN – это элементы графической схемы, но также и элементы самого бизнес-процесса.

Нотация опирается на следующие базовые графические элементы:

• Пул и Дорожки
• Действия
• Шлюзы или Развилки
• События
• Потоки
• Артефакты

В BPMN 2.0 элементы представлены в виде специальных значков. Создатели данной системы стремились к тому, чтобы набор значков был исчерпывающим и обеспечивал возможность наглядного отображения максимального разнообразия схем бизнес-процессов. В итоге значков очень много и с полным списком можно ознакомиться в документации по BPMN, которая переведена на русский язык членами Ассоциации BPM-профессионалов России. Здесь мы остановимся только на базовых элементах, без которых не обойдётся ни одна схема бизнес-процесса. Этого достаточно для общего знакомства с BPMN и понимания основных принципов нотации.

BPMN элементы “Пул” и “Дорожка”

Весь бизнес-процесс состоит из пулов: совокупности операций + лиц, которые эти операции выполняют.

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

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

BPMN элемент “Действие”

Под “действием” понимается единица работы, выполняемой в ходе исполнения бизнес-процесса. Действия могут быть как элементарными (задача/task), так и составными (подпроцесс/sub-process).

Есть несколько типов элементарных действий, которые отличаются условиями выполнения:

• Многократное выполнение действия в рамках одного процесса. Например, одно и то же действие может выполняться параллельно для каждого товара в заказе клиента.
• Циклическое действие выполняется многократно, пока заданное условие верно.

BPMN предполагает следующие графические отображения для основных типов действий:

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

Здесь стоит отметить, что современные BPM-системы зачастую предлагают более широкий набор типов действий, чем предлагает BPMN. Например, в инструменте для моделирования бизнес-процессов в Comindware Business Application Platform вы найдёте графические элементы для нескольких типов элементарных действий, а также встроенных кейсов:

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

BPMN элементы “Развилка” или “Шлюз”

Под шлюзами понимаются элементы, определяющие ветвление и слияние потоков работ.

BPMN описывает 7 типов развилок. В качестве основных выделяют 2 типа:

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

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

Пример использования шлюза исключающего «или» для создания альтернативных потоков процесса:

• Этап 7. Звонок клиенту с целью оценить качество обслуживания.
• 1. Если клиент доволен, фиксация положительной оценки, закрытие бизнес-процесса.
• 2. Если клиент недоволен, выяснение причины.

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

Фактически, шлюзы являются одними из самых ответственных и сложных этапов бизнес-процессов. От того, насколько грамотно будут прописаны все условия и следствия по принципу “Если… то”, во многом зависит эффективность работы всей системы.

BPMN элемент “Событие”

“Событие” является одним из главных элементов BPMN и служит для описания того, что должно случиться (в отличие от задачи, когда что-то должно быть сделано). Событием может быть, например, подписание договора, или разговор с клиентом.

Графические элементы событий в BPMN классифицируют двумя способами:

1. В зависимости от положения события на схеме процесса:

	Начальное событие (инициирующее бизнес-процесс)
	Промежуточное событие
	Конечное событие (заканчивающее бизнес-процесс).

В случае с доставкой товара начальным событием будет, очевидно, заявка клиента. Либо же – звонок менеджера клиенту с предложением совершить покупку. Конечным событием в такой цепочке станет факт доставки, подтверждённый подписью клиента.

1. По типу события классификация следующая:

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

Очень часто начальные и конечные события являются событиями-сообщениями.

BPMN элементы “Потоки”

Поток – это последовательность действий, которая обозначается стрелкой. Элемент “поток” показывает какое действие после какого необходимо совершить.

	Поток управления	На стандартный поток управления не воздействуют условия и он не проходит через шлюзы, т.е. является неконтролируемым.
	Условный поток управления	Используется для того, чтобы показать, что дальнейшее выполнение процесса будет происходить по определённому потоку только в том случае, если выполнятся заданное условие. Ромбик у основания стрелки добавляется, если условный поток управления является исходящим от процесса. Ромбик не добавляется, если условный поток управления является исходящим от шлюза.
	Поток управления по умолчанию	Используется тогда, когда необходимо показать, что дальнейшее выполнение процесса будет происходить по определённому потоку только если не выполняется ни одно из заданных условий.
	Поток сообщений	Используется для отображения межпроцессного взаимодействия – отображает передачу сообщений или объектов из одного процесса в другой процесс или внешнюю ссылку.
	Ассоциация	Применяется для визуализации связи между элементами потока и объектами, не являющимися элементами потока (артефактами).

BPMN элементы “Артефакт”

Под артефактами в BPMN понимают объекты, которые не влияют на исполнение бизнес-процесса напрямую. Это могут быть документы, данные, информация.

Основные виды артефактов:

	Группа объектов	Используется для группировки графических элементов, принадлежащих одной и той же категории и позволяет повысить простоту восприятия диаграммы.
	Текстовая аннотация	Применяется для уточнений к диаграмме – комментариев и пояснений, которые увеличат читабельность диаграммы.
	Объект данных	Используется для отображения информации о данных, которые обрабатывается в ходе процесса.

Преимущества BPMN

BPMN-описание бизнес процесса имеет несколько преимуществ.

Первое – простота трансляции диаграмм в исполняемые модели с помощью языка формального описания бизнес-процессов.

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

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

Елена Гайдукова, маркетолог-аналитик, бренд-менеджер решений на базе , специалист по партнёрским отношениям.

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

Например, популярная сейчас нотация BPMN по-настоящему раскроет свои преимущества только в связке с BPM-системой, которая может «понимать» и «исполнять» нарисованную схему бизнес-процесса в реальном времени. То есть при помощи этой нотации можно автоматизировать и контролировать выполнение процесса. Если же вы просто нарисуете процесс в нотации BPMN в Visio и сохраните его как картинку, то при этом вы потеряете практически все преимущества данной нотации перед любой другой.

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

Ниже приведён пример системы бизнес-моделирования, которая на бумаге поддерживает нотацию ARIS eEPC, но, на самом деле, ответственность закрепляется в карточке на функцию, а графические блоки используются «для красоты».

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

Процессы верхнего уровня

Самые распространённые нотации для построения процессов верхнего уровня на сегодняшний день это IDEF0 (методология функционального моделирования) и ARIS VAD (цепочка создания ценности).

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

В чём же отличие нашей схемы от IDEF0? В первую очередь в том, что в IDEF0 есть требования к тому к какой стороне блока какая стрелка должна подходить:

• стрелка входа приходит всегда в левую кромку активности
• стрелка управления - в верхнюю кромку
• стрелка механизма - нижняя кромка
• стрелка выхода - правая кромка

Является ли это важным отличием, которое даёт преимущества данной нотации перед нашим подходом? С нашей точки зрения – нет, но при желании, вы можете привести схему взаимодействий в Fox Manager в чёткое соответствие с требованиями этой нотации (сверху – оригинальная схема в IDEF0, снизу – её аналог в Fox Manager).

Как видите, при желании, вы можете моделировать схемы IDEF0 и в Fox Manager.

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

Что касается нотации ARIS VAD – то тут всё ещё проще: достаточно выстроить процессы по цепочке создания ценности и при желании показать ответственных и взаимодействия.

На картинке приведён пример такой схемы в нашей программе (сверху – оригинальная диаграмма ARIS VAD, снизу – её аналог в Fox Manager). Конечно, можно придраться в форме блоков, стрелок или подсветке, но в целом, не возникает сомнений, что в нашей программе, при желании, можно строить диаграммы в соответствии с требованиями нотации ARIS VAD.

Процессы нижнего уровня

В программе Fox Manage мы используем простую, наглядную и очень гибкую нотацию для моделирования процессов нижнего уровня. Ознакомиться с её возможностями можно из видеоролика.

Существует множество нотаций для моделирования бизнес-процессов нижнего уровня: Basic Flowchart, Cross Functional Flowchart, EPC и другие. Большинство из них имеют незначительные отличия друг от друга.

Например, если в программе Fox Manager на диаграмме свернуть блоки ответственных, документов и ресурсов, то мы получим аналог нотации Basic Flowchart (справа – оригинальный процесс, слева – аналог в Fox Manager).

Если же все блоки на диаграмме развернуть – то мы получим аналог процесса в нотации EPC . Самое замечательное то, что при использовании нотации Fox Manager блоки можно сворачивать и разворачивать динамически, и при этом не нужно создавать новую версию процесса в другой нотации. На картинке справа изображен оригинальный процесс, а слева – аналог в Fox Manager.

Да, конечно, имеются и различия, например, в качестве отображения события мы использовали контрольную функцию, также у нас нет отдельных блоков «Логические И» и «Логическое ИЛИ», но их можно легко заменить другим блоком (ромбиком) с буквой «Х» или «V» внутри.

Поддержка нотации Cross Functional Flowchart была добавлена в программу в одном из наших бесплатных обновлений . Данная нотация отличается от уже рассмотренных выше нотаций тем, что на ней можно показывать ответственных дорожками, а не рядом с блоком. К сожалению, у этого способа есть свои недостатки, когда ответственных очень много – то процесс становится ненаглядным и трудночитаемым. Также возникают проблемы, когда необходимо распределить ответственность за функцию сразу двум и более должностям. Ниже приведён пример такого процесса в Fox Manager.

Что касается нотации BPMN , то мы считаем, что её возможности слишком избыточны для целей описания, анализа и регламентации бизнес-процессов. В этой нотации представлено около 100 различных блоков и их подвидов, которые используются при автоматизации процессов, но они бесполезны для систем бизнес-моделирования, которые не умеют «исполнять» процессы в реальном времени, а берут из них информацию для формирования регламентирующих документов.

Конечно, наверное, можно сократить набор элементов этой нотации до необходимого минимума и попытаться приспособить её для целей регламентации, но при этом мы потеряем её главное преимущество – возможность исполнения процессов BPM-движком. При этом, если оставить только 5-10 необходимых блоков, то, скорее всего, внешний вид таких процессов будет очень походить на уже рассмотренные нами нотации.

Вывод

Мы считаем, что в программе Fox Manager подобраны оптимальные нотации для моделирования бизнес-процессов, которые одновременно легки для восприятия и обладают и высоким функционалом.

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

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

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

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

Но мы отдаём себе отчёт в том, что некоторые бизнес-аналитики не доверяют новым разработкам и предпочитают пользоваться старыми, знакомыми им нотациями. Цель данной статьи – показать гибкость программы Fox Manager и возможность настройки внешнего вида схем под требования большинства имеющихся на рынке нотаций. Стройте модели бизнес-процессов так, как удобно именно вам!