Как составить диаграмму бизнес процесса

Введение

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

Главное назначение и практическое применение

Нотация BPMN (Business Process Modeling Notation) нужна для подробного описания логики выполнения бизнес-процесса, в том числе для отражения деталей процессов, таких как: события, исполнители каждого из действий, используемые и создаваемые документы и другие объекты, использующиеся в качестве входных данных для тех или иных действий или создающиеся в результате их выполнения.

BPMN позволяет описать бизнес-логику выполнения действий в виде наглядной диаграммы, а также запустить отрисованный бизнес-процесс на исполнение. Для этого используются специализированные системы BPMS (Business Process Management System), поддерживающие эту нотацию.

BPMS-системы могут автоматически перевести схему бизнес-процесса в исполняемый код и создать веб-приложение, которое будет обрабатывать данные, введённые пользователями и сторонними сервисами. Это соответствует концепции Low Code/No Code (создание программного обеспечения без разработки кода) и отлично подходит для автоматизации офисных процессов.

Технически такая возможность реализуется за счёт перевода BPMN-диаграмм в документы формата BPEL (Business Process Execution Language). BPEL-документы представляют собой инструкции исполнения бизнес-процессов для веб-сервисов.

Таким образом, BPMN используется в следующих случаях:

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

2. Когда требуется запустить схему бизнес-процесса на исполнение в BPMS-системах

Краткая история появления нотации

BPMN считается довольно молодой нотацией: её 1-я версия вышла в 2009 году под эгидой профессионального консорциума OMG. Сегодня эта нотация является стандартом де-факто в ИТ-сфере и используется для описания бизнес-процессов. Текущая версия BPMN 2.0 вышла в 2011 году и используется до сих пор. В 2014 году в дополнение к BPMN группа OMG выпустила нотацию описания бизнес-правил и принятия решений (Decision Model and Notation, DMN).

DMN упрощает построение BPMN-диаграмм в случаях сложной бизнес-логики и многоуровневых её ветвлениях.

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

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

Уровни моделирования

В зависимости от целей построения BPMN-диаграмм, различают 3 уровня моделирования:

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

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

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

Алфавит нотации

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

Поток управления — это последовательность шагов бизнес-процесса, в которой он исполняется.

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

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

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

События

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

Триггер определяет тип и смысл события. Например, триггер в виде конверта означает, что пришли какие-то данные, причём совсем не обязательно в виде сообщения электронной почты. Триггер в виде часов связан со временем. Если событие имеет триггер, значит, поток управления двинется дальше только тогда, когда сработает триггер этого события. Например, получены данные, наступил определённый временной интервал и так далее.

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

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

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

Эфемерной сущностью BPMN, которая показывает смысл концепции потока, называют токен. Подобно потоку воды токен «бежит» от стартового события диаграммы к финишному, разделяясь на несколько экземпляров с помощью логических операторов. Последовательность и вариативность выполнения действий называется бизнес-логикой и показывается с помощью логических операторов или развилок, шлюзов. Например, на диаграмме ниже представлено 2 логических оператора: исключающее ИЛИ (XOR) и включающее ИЛИ (OR).

Процесс утреннего пробуждения

Как можно видеть на диаграмме, после стартового события выполняется первое действие («Проверить время звонка»). Следующий за ним логический оператор исключающего ИЛИ, подобно шлюзу, пропускает дальше поток управления только по одной ветке: «да» или «нет». Причём ветка «нет» здесь помечена как поток по умолчанию, который выполнится, если все остальные условия не будут верны.

После выполнения действия оператор включающего ИЛИ (OR) пропускает поток на действие «Выпить кофе» или на действие «Узнать новости» или по обоим веткам. Исключения здесь нет, ручеёк потока управления распараллеливается на две ветки, чтобы потом объединиться снова в одну и один раз выполнить действие «приготовиться к делам». После выполнения этого действия процесс заканчивается конечным событием.

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

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

Диаграмма BPMN может содержать один или несколько пулов, каждый из которых может содержать одну или несколько дорожек.

Процесс утоления голода

В следующем примере процесс «утоления голода» состоит из двух дорожек («Ребёнок» и «Мама»), общение между которыми выполняется через поток управления.

Стартовым событием является простое событие «Возникло чувство голода» на дорожке Ребёнок, а конечным — простое событие «Чувство голода удовлетворено» на этой же самой дорожке.

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

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

Типы событий

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

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

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

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

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

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

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

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

Типы действий

Подобно событиям, действия в BPMN также могут быть разных типов:

• Выполняемые вручную без использования какого-либо ПО, например, съесть пиццу.

• Выполняемые пользователем с помощью ПО, к примеру, заказать пиццу.

• Выполняемые скриптом или сервисом, например, изменить статус заказа пиццы.

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

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

Логические операторы

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

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

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

Наконец, логическое И (AND) означает активацию всех входящих или исходящих в этот оператор потоков управления, реализуя логическое умножение переменных, т. е. операцию конъюнкции.

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

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

Следующий рисунок показывает использование эксклюзивного шлюза по событиям, который запускает движение потока только по той ветке, где событие произойдёт раньше. Например, получено согласие от клиента ИЛИ прошло 5 дней (без новостей от клиента).

Все остальные шлюзы, которые есть в BPMN, приведены в Приложении В.

Артефакты

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

Вы можете найти полный перечень артефактов в Приложении Г.

Правила построения диаграмм

Рассмотрим пример бизнес-процесса обработки заявки:

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

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

После действия «Направить клиенту коммерческое предложение (КП)» на диаграмме используется логический оператор ИЛИ (событийный XOR), после которого возможен один из двух вариантов:

1. Если прошло 5 дней, что показано событием с триггером таймер, и ответа от клиента нет, заявке присваивается статус «Отказ» в CRM-системе и наступает финишное событие «Заявка закрыта».

2. Если же ответ от клиента получен и 5 дней ещё не прошло, процесс движется дальше в зависимости от данных в этом ответе.

Таким образом либо заявке присваивается статус «Отказ» или выполняется свернутая задача «Сформировать проект договора», детали которой показаны на отдельной диаграмме.

В результате этой задачи создаётся документ «Проект договора» и наступает финишное событие «Заявка успешно обработана».

Поток по умолчанию

Если в диаграмме используются операторы обычного XOR, проверяющего условия по данным, и OR (неисключающего ИЛИ) рекомендуется помечать поток по умолчанию, который активируется, если другие условия не сработали. Поток по умолчанию допустимо не подписывать, если подписаны остальные потоки и диаграмма остаётся понятной. В примере ниже «‎Нецелевой» — поток по умолчанию.

Альтернативный способ показать условия

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

Задачи и события

Говоря про вариативность BPMN, следует отметить небольшое различие между событиями-сообщениями и задачами-сообщениями. По сути это одно и тоже, но к задачам-сообщениям можно прикреплять обработчики событий (например, таймер) и модификаторы (например, цикл по объектам), а к самим событиям — нет.

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

Пример этой же диаграммы с событиями получения и отправки сообщений:

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

Рекомендации по использованию BPMN

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

Принимая во внимание три уровня моделирования BPMN и избыточный алфавит этой нотации, можно сделать вывод, что при проектировании диаграмм «‎для людей» (без запуска на выполнение в BPMS-системах) следует намеренно ограничить количество используемых элементов:

• Использовать только пользовательские и ручные задачи — без сценариев, сервисов и бизнес-правил, отправки и получения сообщений.

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

• Использовать только XOR и AND, без событийных шлюзов и OR, так как разница между исключающим и не исключающим ИЛИ понятна не всем пользователям.

• Использовать события с типом простое, таймер, сообщение и останов.

Для упрощения восприятия диаграммы стоит придерживаться правил наименования:

• Внешних контрагентов показывать как закрытые, они же — свёрнутые пулы (пулы, в которых нет действий).

• Называть закрытые пулы ролями или бизнес-единицами, а открытые — процессами.

• Называть дорожки также, как роль, должность или структурное подразделение.

• Называть действия (задачи) в стиле Глагол-Существительное, например, «‎Проверить счёт», «Подтвердить заявку», «Оформить договор».

• Называть события как свершившийся факт в прошедшем времени, к примеру, «Поступила заявка», «Прошло 3 дня».

• Подписывать исходящие из XOR стрелки, например, «Да» и «Нет», а также отмечать поток по умолчанию.

Также рекомендуется:

• Показывать успешное и неуспешное завершение процесса разными финишными событиями.

• Не выводить поток управления за пределы подпроцесса.

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

Наконец, при разработке любой диаграммы нужно помнить о главном правиле аналитика: независимо от нотации, ваша схема должна быть МАКСИМАЛЬНО простой и понятной читателю БЕЗ знания тонкостей процессного моделирования!

В целом алгоритм разработки BPMN-диаграммы можно представить как набор следующих 7 шагов:

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

2. Описать «счастливый» путь (happy path), который ведёт к созданию полезного результата (продукта).

3. Добавить условия и альтернативные потоки.

4. Добавить неуспешные завершения.

5. Добавить артефакты (объекты и хранилища данных).

6. Раскрыть на новых связанных диаграммах свёрнутые подпроцессы.

7. Добавить промежуточные событийные потоки к внешним пулам.

Пример построения диаграммы по текстовому описанию

Рассмотрим пример процессов работы с клиентской заявкой, представленной двумя пулами: «Обработка заявки» и «Заключение договора».

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

Процесс начинается с момента, когда клиент оставил заявку на сайте (то есть поступление заявки является триггером процесса, его стартовым событием). На основании заявки, в которой указаны подробности заказа, менеджер формирует коммерческое предложение (КП). Далее менеджер озвучивает КП по телефону или направляет на email, или же делает и то, и другое — в зависимости от пожеланий клиента и указанных в заявке контактных данных.

Узнав подробности коммерческого предложения, клиент принимает решение о продолжении сотрудничества или отказе от него. Если клиент не согласился на условия КП, на этом процесс работы с ним заканчивается, а заявке присваивается статус «Отказ».

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

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

Инструменты для разработки бизнес-процессов в нотации BPMN

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

• ШТОРМ — веб-редактор от команды Дениса Котова, пожалуй, главного евангелиста BPMN в России, с автопроверкой диаграмм и возможностями командной работы в одном пространстве;

• Online BPMN — простой и удобный веб-редактор, поддерживает интеграцию с BPMS-системой;

• Cavemo — веб-редактор, аналогичный предыдущему, имеет офлайн-версию

• простые веб-«рисовалки‎» Lucidchart, Draw.io, Visual Paradigm

Также алфавит нотации BPMN поддерживается и в MS Visio, ARIS Express и других редакторах диаграмм общего назначения.

Заключение

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

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

---

• Кандидат технических наук (Системный анализ, управление и обработка информации, 2013)

• Сертифицированный бизнес-аналитик (IIBA CBAP, 2020)

• Сертифицированный специалист Business Studio и СЭД Directum

Профессиональные интересы: системный анализ, бизнес-анализ, разработка и поддержка СМК, ССП (KPI), анализ и формализация бизнес-процессов (UML, IDEF, BPMN), Data Science, технологии Big Data, разработка технической документации (ТЗ по ГОСТам серии 19, 34, руководства пользователя и администратора, описание программных продуктов), управление продуктами и проектами.

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

---

Составляющие блок-схем

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

• Действие;
• Условие;
• Документ;
• Подпроцесс;
• Линии.

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

Как описать бизнес-процесс

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

• Составить список покупок;
• Найти кошелек;
• Взять кошелек;
• Открыть кошелек;
• Хватает ли в кошельке денег?
• Если нет, то возвращаемся к Списку покупок;
• Если Хватает, то берем пакет;
• Смотрим, есть ли на улице дождь;
• Если дождь есть, берем зонт и затем выходим на улицу;
• Если нет, выходим на улицу;
• Идем в магазин (это ведь тоже может быть целый подпроцесс);
• Далее выполняем процесс № 2 (Купить продукты);
• … тут еще можно расписать возвращение домой, раскладывание продуктов по шкафам и холодильнику, приготовление ужина и т.д. …
• Конец.

Так будет выглядеть описание бизнес-процесса для нашей задачи:

Как видите, рисовать и описывать блок-схему (диаграмму) достаточно просто.

Тут я хочу предостеречь вас. Одного рассказа (описания) или одной диаграммы с бизнес-процессом недостаточно. Надо, чтобы в вашем тексте (а это ведь будет скорее всего техзадание, пользовательская история, функциональные требования) были: 

• и диаграмма;
• и текст.

Почему? Просто потому, что ваши читатели разные, кто-то воспринимает текст, а кто-то понимает только картинку. Поэтому любите их и делайте хорошо, а нехорошо не делайте.

Иллюстрация: Оля Ежак для SKillbox Media

Рассказывает просто о сложных вещах из мира бизнеса и управления. До редактуры — пять лет в банке и три — в оценке имущества. Разбирается в Excel, финансах и корпоративной жизни.

Бизнес-аналитик с опытом работы более четырёх лет, магистр в области информационной бизнес-аналитики. Сейчас участвует в проектах, связанных с нефтедобычей, геологоразведкой, логистикой. Принимала участие во внедрении «1С:ERP» как основной бизнес-аналитик. Проверяющий куратор курсов Skillbox «Профессия Бизнес-аналитик», «Профессия Операционный менеджер».

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

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

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

В статье для Skillbox Media расскажем:

• что такое бизнес-процессы и для чего ими управлять;
• какие есть способы описания бизнес-процессов;
• что такое нотация BPMN и в чём её главные преимущества;
• из каких элементов состоит BPMN;
• как построить модель бизнес-процесса с помощью BPMN пошагово;
• как применяют нотацию BPMN в бизнес-аналитике;
• как узнать больше об управлении бизнес-процессами.

---

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

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

Чтобы всё работало, процессами нужно управлять. От гибкости и управляемости бизнес-процессов зависит, насколько успешным будет бизнес. Есть разные подходы к управлению — все они включают три основных элемента:

• анализ бизнес-процессов;
• выявление проблем;
• оптимизация бизнес-процессов.

В Skillbox Media есть статья, где подробно рассказано об управлении бизнес-процессами.

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

Три самых распространённых способа описания бизнес-процессов:

• Текстовый — подготовка письменных инструкций, регламентов, стандартов и других нормативных документов.
• Табличный — описание процессов в формате таблиц.
• Схематичный — графическое изображение процессов.

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

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

Нотации описывают:

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

Есть несколько вариантов нотаций — их выбирают в зависимости от типов бизнес-процессов и потребностей бизнеса. Вот некоторые примеры нотаций:

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

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

BPMN — аббревиатура от Business Process Model and Notation. Это система условных обозначений и их описания для моделирования бизнес-процессов.

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

Первая версия BPMN создана в 2004 году рабочей группой IBM. В 2010 году — дополнена и выпущена под названием BPMN 2.0. В неё добавили новые типы событий и диаграмм, устранили ошибки первой версии.

Вот главные преимущества нотации BPMN перед другими нотациями:

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

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

Ниже на иллюстрации приведён пример процесса — поиска и приёма на работу нового сотрудника.

Разберём основные элементы нотации. Их будет достаточно для большинства схем.

Процесс (задача, подпроцесс). Задача — действие или операция, у которых нет дальнейшей декомпозиции в рамках процесса. Подпроцесс — декомпозированный процесс, в который включено несколько задач. На диаграмме он обозначается блоком со знаком +.

Примеры задач в иллюстрации выше — «Заявка на подбор нового сотрудника», «Проведение собеседования». Часто задачи формулируют через глагол: «Провести собеседование», «Подобрать сотрудника».

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

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

В нашем примере стартовые события — «Потребность в расширении штата» и «Текущий сотрудник написал заявление на увольнение».

Шлюзы. Показывают слияния потоков управления в рамках процесса. Среди них выделяют:

• Параллельный шлюз — означает, что два процесса исполняются одновременно. Читается как «И».

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

• Эксклюзивный шлюз — используют, чтобы обозначить ветвление потока управления на несколько альтернативных потоков, когда процесс зависит от выполнения условия. Читается как «ИЛИ».

  В этом случае процесс идёт чётко по одному из потоков.

• Неэксклюзивный шлюз — применяют, чтобы показать ветвление потока управления на несколько других, когда процесс зависит от выполнения условий. Читается как «И/ИЛИ».

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

Объект данных. Показывает, какие объекты сопровождают выполнение процесса. Например, бумажный документ, электронный документ, информацию и так далее.

В нашем примере объекты данных — «Заявка на подбор», «Лист оценки кандидата», «Предложение о работе».

Потоки. Это стрелки, которые показывают движение по процессам и порядок их выполнения. Есть несколько видов потоков:

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

  Пример — связь между задачами «Поиск подходящих кандидатов» и «Отправка релевантных резюме». Это две задачи, которые последовательно идут друг за другом.

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

• Ассоциация — показывает связи объектов данных и баз данных с процессами.

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

Пулы (дорожки). Показывают участников бизнес-процессов. Например, должности, подразделения, роли, внешние субъекты. Дорожка не может соответствовать системе или другим объектам — только людям.

Например, в нашей иллюстрации дорожки соответствуют кандидату, HR-менеджеру, руководителю отдела.

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

Существует много инструментов для разработки процессов в BPMN. Мы рекомендуем бесплатный онлайн-сервис Diagrams.net. В нём можно создавать схемы, модели, диаграммы и обмениваться ими в браузере.

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

Вот пошаговый план того, как построить бизнес-процессы в нотации BPMN:

1. Изучите процесс: для чего он нужен и какие задачи решает.

2. Определите, является он основным, вспомогательным или процессом управления.

Основной процесс — приносящий прибыль или влияющий на прибыль компании. Например, производство или продажи. Таким процессам нужно уделять особое внимание.

Вспомогательный процесс — процесс, который не генерирует доход, но обеспечивает качественное выполнение основных процессов. Например, бухгалтерский учёт.

Процесс управления — процесс, влияющий на существование и развитие компании. Например, управление командами компании.

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

4. Выявите всех участников процесса: должности, роли, отделы, в некоторых случаях — Ф. И. О. ответственных сотрудников. Но в схемах процесса лучше избегать построения дорожек, завязанных на Ф. И. О., — иначе нужно будет постоянно следить за актуальностью данных.

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

6. Отметьте все внутренние события бизнес-процесса. Дополнительные детали можно при необходимости уточнить у владельцев процесса.

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

Задачи бизнес-аналитика, для которых требуется BPMN, делят на два этапа:

• Построение схем «как есть» (as is) — описание текущей последовательности работ бизнес-процесса.
• Построение схем «как будет» (to be) — описание целевого процесса с фиксацией требуемых изменений: этапов модернизации, автоматизации.

Разберём на примере. Допустим, в компании N было 70 сотрудников, которые работали в одном офисе. Всю необходимую документацию они распечатывали, подписывали от руки и самостоятельно относили получателю — например, бухгалтеру, отделу кадров или секретарю.

Потом компания выросла в 2,5 раза, появились удалённые сотрудники. Руководство приняло решение внедрить систему электронного документооборота (СЭД). Перед внедрением такой системы бизнес-аналитику потребуется выполнить три основные задачи:

• Разобраться и описать, как сейчас сотрудники знакомятся с документами и подписывают их. При этом учесть два типа сотрудников — работающих в офисе и удалённо.
• Выявить возможные узкие места и особенности процесса в данной компании. Эти особенности должны быть учтены при разработке или покупке готовой СЭД.
• Проанализировать, как бизнес-процесс «ложится» на новую систему: в каких местах необходима доработка ПО, в каких — организационные изменения внутри компании.

Что даёт описание текущего процесса и моделирование целевого процесса документооборота? Снизится риск упустить ключевые функции СЭД и получить на выходе систему, которая не будет решать задачи компании.

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

• Бизнес-процессы — все операции, которые помогают решать задачи бизнеса и получать доход. Чтобы всё работало по плану, процессами нужно управлять: описывать их, анализировать и оптимизировать.
• Эффективнее всего описывать бизнес-процессы графически — в виде интуитивно понятных схем. Для этого используют различные нотации — системы условных обозначений. Они нужны для того, чтобы любой человек понимал, что изображено на схеме.
• Одна из универсальных и самых наглядных нотаций — нотация BPMN (Business Process Model and Notation). Она в графическом виде отражает последовательность работ бизнес-процессов и логику их выполнения.

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

Другие материалы Skillbox Media для менеджеров

Научитесь: Профессия Бизнес-аналитик
Узнать больше

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

Что такое BPMN

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

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

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

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

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

Основные элементы BPMN

BPMN содержит 4 типа элементов для диаграмм бизнес-процессов:

1. Объекты потока: события, действия, шлюзы.
2. Объекты подключения: поток операций, поток сообщений, ассоциация.
3. Пулы и дорожки.
4. Артефакты: объект данных, группа, аннотация.

Процесс

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

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

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

• Частные бизнес-процессы. Процессы, протекающие внутри конкретной компании, которые не пересекают организационные пулы или границы.
• Абстрактные бизнес-процессы. Находятся на пересечении частного процесса и другого участника/процесса. Такие процессы указывают последовательность сообщений, необходимых для работы с частным процессом. Они не отображают сути самого внутреннего процесса.
• Совместные бизнес-процессы. Отображают взаимодействие между двумя и более объектами.

Событие

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

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

Шлюзы

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

• Параллельный шлюз. Указывает на одновременное исполнение двух процессов. Читается как «И».
• Эксклюзивный шлюз. Применяется для разделения потока на несколько других потоков, когда на процесс влияют определенные условия. Читается как «ИЛИ». При этом процесс проходит только по одному из потоков.
• Неэксклюзивный шлюз. Используется при ветвлении потока на несколько других с влиянием условий на процесс. Читается как «И/ИЛИ». Движение процесса может проходить по одному либо двум потокам. Применяется на практике редко.

Артефакт

Артефакты — это любая дополнительная информация, которая предоставляет необходимые сведения о шаге или части процесса. Существует три основных типа артефактов:

1. Объект данных — указывает, какие данные нужны для выполнения этапа бизнес-процесса.
2. Группа — показывает группы последовательных действий, но это не меняет поток или направление шагов, которым необходимо следовать.
3. Аннотация — дает более подробную информацию о части схемы, если она сложная.

Потоки

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

1. Поток управления. Показывает порядок выполнения задач. Он представлен в виде прямой линии со стрелкой. Он может отображать условный поток или предопределенный поток.
2. Поток сообщений. Представляет сообщения, которые передаются между пулами или организационными границами, такими как отделы. Он не должен связывать события или действия в пуле и представлен пунктирной линией с кружком в начале и стрелкой в ​​конце.
3. Ассоциация. Представленная пунктирной линией, она связывает артефакт или текст с событием, действием или шлюзом.

Пулы (дорожки)

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

Зачем использовать BPMN

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

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

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

Как построить модель бизнес-процесса в нотации BPMN

Бизнес-аналитик использует BPMN в 2 этапа:

1. При построении схем «как есть» — для описания последовательности работ в текущем времени.
2. При построении схем «как будет» — для описания дальнейшего развития бизнес-процесса с учетом прохождения автоматизации, модернизации и т. д.

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

Чтобы внедрить такую систему, ответственному аналитику понадобится выполнить три важные задачи:

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

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

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

Пример построения диаграммы по текстовому описанию

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

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

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

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

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

Инструменты для разработки бизнес-процессов в нотации BPMN

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

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

Наименование	BPMN 2.0	Удобство	Стоимость
Visio 2010	Отлично	Отлично	Платное
Enterprise architect	Плохо	Плохо	Платное
ELMA BPM	Плохо	Хорошо	Платное
BPM 2.0 modeler for Visio	Отлично	Отлично	Платное
Bizagi Process Modeler	Отлично	Хорошо	Бесплатное
Modelio	Плохо	Хорошо	Бесплатное
ARIS Express	Отлично	Отлично	Бесплатное

Рекомендации по использованию BPMN

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

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

Объем процесса

Вы должны четко определить объем процесса, указав «Кто», «Что», «Когда», «Где» и «Почему». Процесс зафиксирует «Как». Должно быть ясно, что представляет каждый экземпляр вашего процесса. Экземпляры процесса идентифицируемы, поэтому вы можете обратиться к каждому из них и при желании подсчитать их.

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

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

Макеты диаграмм

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

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

• Сводная диаграмма со всеми подпроцессами и действиями вызова свернута и не показывает никаких объектов данных.
• Подробная диаграмма со всеми подпроцессами и действиями вызова показывает объекты данных и аннотации.

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

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

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

Разделение и структура процесса

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

Начальные и конечные события

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

Шлюзы

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

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

Выводы

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

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

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