Методология моделирования бизнес процессов bpmn

Время на прочтение
10 мин

Количество просмотров 99K

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

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

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

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

BPMN: основные понятия

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

Можно сказать, что BPMN является частью двух основных компонентов:

• BPM (моделирование бизнес-процессов) — это среда, в которой вы непосредственно участвуете в моделировании. В одиночку или в команде.

• BPMS (система моделирования бизнес-процессов) — это инструменты для выполнения создаваемых вами моделей. Это может быть Bizagi, Comundo, ELMA и т.д.

Язык описания бизнес-процессов

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

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

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

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

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

Элементы нотации BPMN

Язык описания бизнес-процессов основан на следующих базовых объектах:

• Event – Событие;

• Activity – Действия;

• Gateway – Шлюзы или Развилки;

• Flow – Поток;

• Date – Данные;

• Artefact – Артефакты;

• Swimline – «плавательные дорожки»;

• Pool (Пул) — набор.

EVENT (СОБЫТИЕ)

Event — это событие, которое произошло в описании процесса. Эти события могут быть начальными, конечными или промежуточными.

ACTIVITY (ДЕЙСТВИЯ)

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

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

Обычно действия делятся следующим образом:

Задача – единица работы. Если задача помечена символом +, то задача является подпроцессом и может быть детализирована.

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

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

GATEWAY (ШЛЮЗ, РАЗВИЛКА)

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

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

Наиболее используемые развилки

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

Оператор ИЛИ. При ветвлении активируется одна или более ветвей. При слиянии все выполняющиеся входящие ветви должны быть завершены.

POOL (ПУЛ)

Пул — это объект, описывающий один процесс на диаграмме. Его может не быть на карте, но он всегда есть. На одной диаграмме может быть несколько Пулов. Пул может быть расширен для просмотра деталей.

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

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

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

DATE OBJECT (ДАННЫЕ, ОБЪЕКТЫ ДАННЫХ)

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

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

MESSAGE (СООБЩЕНИЕ)MESSAGE (СООБЩЕНИЕ)

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

ARTEFACT (АРТЕФАКТЫ)

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

Существует два типа артефактов:

• Группа объектов;

• Текстовая аннотация.

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

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

Исполняемые и неисполняемые бизнес-процессы

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

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

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

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

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

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

Подходит ли BPMN для малого и среднего бизнеса?

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

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

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

Минусы и важные особенности BPMN

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

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

• Высокий начальный уровень. Как и в случае с любым многофункциональным инструментом, для изучения требуется больше времени по сравнению с другими нотациями (IDEF0, IDEF3).

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

Пример практического применения BPMN

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

Применение диаграмм BPMN на практике

• Делайте диаграммы как можно разветвленными. Чем больше элементов на вашей диаграмме, тем труднее ее будет читать вам и вашим клиентам.

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

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

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

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

• Не бойтесь ошибаться! Если вы сделаете ошибку в исполняемой методологии, это очень быстро обнаружится при запуске (отладке) процесса. Если вы создаете просто наглядную схему, то мелкие ошибки не так важны, главное, чтобы эта схема помогла вам и людям, для которых вы ее делаете (заказчикам, техническим специалистам), понять все нюансы вашей идеи. И в любом случае они учатся на ошибках, а корректировки бизнес-модели можно вносить быстро и легко.

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

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

BPMN 2.0. События начала 

У каждого процесса должно быть, как минимум, одно событие начала 

Событие начала, это уже свершившееся действие, результат действия или условие, при котором начинается выполнение процесса. Можно сказать, что событие начала, это спусковой̆ крючок, который стартует выполнение процесса. Например: событие Получено обращение клиента является событием начала процесса Обслуживание клиентов. 

  

У каждого процесса должно быть, как минимум, одно событие начала. Если вы не можете определить событие начала, то есть два варианта: 

1. Границы процесса определены не верно
2. Это не процесс, а группа процессов, что, опять же, говорит о том, что процесс и его границы, определены не верно. 

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

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

• Получено задание руководителя на подготовку отчета 

• Последний рабочий день месяца

• Последний день перед отпуском 

 

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

Множественное событие начала 

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

Параллельное множественное событие начала 

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

Разные события начала 

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

 

Размещение событий начала в пулах 

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

 

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

 

Связь событий между уровнями декомпозиции 

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

 

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

 

Множественное событие начала процесса может быть декомпозировано на уровне ниже 

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

 

Событие начала в подпроцессе не должно иметь типа 

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

 

Правильное наименование события начала 

Одна из распространенных ошибок — называть событие начала наименованием входа, объекта, поступающего в процесс. Например — заявка клиента. Это неверно. Заявка клиента, это документ, объект. А вот событие начала, да и любое событие, должно отражать свершившийся факт законченного действия. Вместо “Заявка клиента”, правильно назвать “Получена заявка клиента”. В названии события обязательно должен быть указан объект и действие, событие, которое с объектом произошло. Наименование события должно иметь форму деепричастного оборота. 

 

Если событие начала инициировано ролью 

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

 

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

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

1 — Добавить номер, или наименование связанного процесса, в название события. 

 

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

 

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

 

4 — Использовать ссылку на процесс или событие окончания. 

 

BPMN 2.0. Промежуточные события 

Событие — условие развития процесса 

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

  

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

 

Событие, это всегда результат какого-то процесса или операции 

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

 

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

 

События определяют сценарии процесса 

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

 

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

 

Не прерывающие событие 

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

 

Несколько событий подряд 

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

 

Несколько условий, для развития процесса 

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

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

 

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

Событие, как условие времени 

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

 

События на границах операций / процессов 

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

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

 

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

 

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

 

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

 

BPMN 2.0. События окончания

Событие окончания — условие завершения процесса 

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

 

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

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

Множественное событие окончания 

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

Можно конкретизировать множественное событие окончания, предварительно объединив условия-промежуточные события, через шлюз.

 

Событие окончания может быть событием начала другого процесса 

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

Расположение событий окончания 

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

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

 

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

 

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

 

Нет такого события окончания, как “Процесс завершен” 

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

BPMN 2.0. Все события

Событие, это завершенное действие, а не объект 

Еще раз повторю — событие, это завершенное действие, в названии которого есть объект и действие, которое выполнено с этим объектом. Не “Приказ”, а “Получен приказ”. 

Связь документов и событий

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

 

Парные события нужно называть одинаково 

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

 

Называйте события состояния так, чтобы было понятно, какое состояние оно отражает 

Событие типа Состояние, отражает изменение некого состояния. Например, “Превышен кредитный лимит”. Соответственно, называть такие события нужно, чтобы было понятно, какое состояние оно отражает. Нельзя назвать событие просто “Кредитный лимит”, потому что становится непонятно, что с этим лимитом произошло.

 

BPMN 2.0. Шлюзы 

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

 

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

 

То есть шлюзы бывают исходящие и включающие. Или, проще говоря — ветвления и объединения. 

Шлюз, это логическая конструкция 

Существует 3 логические конструкции, которые используются в шлюзах: 

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

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

В примере ниже, может идти дождь, или снег, или туман, а может и дождь со снегом, а может все вместе. Соответственно, если идет и снег, и дождь, нужно выполнить сценарии для этих действий. То есть придется взять и зонт, и санки))) 

 

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

 

Комплексный шлюз

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

1 — В кармане пачка сигарет, 

2 — И лампа не горит, И врут календари. 

 

В следующем примере тоже два варианта: 

1 — В кармане пачка сигарет И есть билет на самолет; 

2 — Группа крови на рукаве. Обе комбинации приводят к одному сценарию. 

 

Шлюз, это не принятие решения 

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

 

Условия развития событий

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

 

Ветвление без шлюза 

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

 

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

Наименование шлюза 

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

 

Шлюз без названия 

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

Ветвление, а затем объединение не имеет смысла 

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

 

Такие конструкции не имеют смысла. И вот почему: 

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

 

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

 

·      Если хотите показать, что нужно выполнить действия, но порядок и состав не важен, замените на процесс Ad Hoc. В процессе Ad hoc не важно в каком порядке и, даже, в каком составе будут выполнены операции. Вы можете добавить сахар, сливки, корицу в кофе в любом составе и порядке. 

 

Заменяйте сложны ветвления бизнес-правилами 

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

Пример сложного ветвления, лишь при трех условиях 

То же сложное ветвление, но представленное в виде бизнес-правила 

Суть объединяющего шлюза 

Суть в том, что объединяющий шлюз показывает — чтобы процесс мог идти дальше, должно быть выполнено несколько операций, или условий. Или должно быть выполнено несколько операций и выполнено несколько условий. Объединяющий шлюз также работает по логическим принципам: исключающее ИЛИ, ИЛИ, И. 

 

Комплексный шлюз. Объединение

Объединяющий шлюз И 

Наименование объединяющих шлюзов 

Нет необходимости называть объединяющие шлюзы. Можно давать текстовые аннотации к ним, там, где они логически не совсем очевидны. 

BPMN 2.0. Пулы / дорожки 

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

  

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

Название пула должно соответствовать роли 

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

Пулы, дорожки и организационная иерархия 

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

 

Иерархия пулов и дорожек 

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

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

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

 

Переход процесса от одного пула к другому 

Пулы могут соединяться между собой только информационными потоками. 

 

Информационные потоки между пулами 

Дорожки операции в дорожках соединяются рабочими потоками

Рабочий поток между дорожками   

Лучшая связь между элементами разным пулов выглядит как связь между операциями и событиями. То есть действие в одном пуле, порождает событие в другом пуле. Хотя может быть и прямая связь “операция — операция” 

 

Лучший способ отразить переход процесса между пулами  

Пулы могут обмениваться документами. 

 

Обмен документами между пулами

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

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

Связи документов с элементами BPMN 

В нотации BPMN, документ может быть связан с: 

• Операциями и процессами, через направленную ассоциацию 

• Событиями, через ненаправленную ассоциацию

• Пулами, через направленную ассоциацию

• Базами данных, через простое соединение 

 

Связи объектов данных с другими элементами 

Направление ассоциации имеет значение 

Если стрелка ассоциации идет от документа к операции, это означает, что документ используется для выполнения операции. Если стрелка ассоциации идет от операции к документу, это означает, что документ появляется в результате выполнения операции. 

 

Направление связи документа и операции имеет значение

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

 

Направленные ассоциации с базами данных 

Отражение состояний объекта данных 

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

 

Отражение состояния документа с помощью наименования 

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

Копии объектов данных 

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

 

М- оригинал. А — копия

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

 

Копии можно использовать для оптимизации диаграммы 

Ссылки на процессы, которые являются источниками документов 

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

1 — Если ПО позволяет, то можно создать физическую ссылку на процесс. В Visual Paradigm для этого используется функция Trace. 

 

Связь документов и процессов-источников

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

 

Использование наименование документа, для отражения процесса-источника документа

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

 

Отображение процессов-источников документов, с помощью отдельного элемента 

Связь документа и базы данных 

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

Связи документов и баз данных

Базы данных для отражения ИТ системы 

Значок базы данных можно использовать для отражения взаимодействия операций и процессов с ИТ системами.

 

Использование значка БД в качестве ИТ системы 

Прикрепляйте документы к объектам данных 

Если ПО для моделирования позволяет это делать. Это очень хорошая практика, потому что позволяет сразу ознакомиться с документами, которые используются в процессе. Если речь об электронном документе, то будет совсем отлично, если в описании объекта данных, вы перечислите поля данных, которые существуют в электронном документе. 

 

BPMN 2.0. Операции / процессы 

Операция — элементарное действие, которое выполняется в процессе. Элементарное — действие, которое нельзя декомпозировать и раскрыть в качестве процесса. Процесс — совокупность операций и подпроцессов. 

Наименование операций

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

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

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

Используйте подпроцессы, для разделения процесса на этапы 

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

 

Разделение процесса на этапы, с помощью подпроцессов 

Используйте процедуры вместо цепочек операций

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

 

Сворачивайте последовательные операции в процедуры 

Заменяйте сложные участки с ветвлениями бизнес-правилами 

Вместо разветвленной цепочки условий, лучше использовать операции типа Бизнес-правило. Только не забудьте описать или прикрепить описание правила. Использование процедур и правил существенно упрощает моделирование, восприятие и использование модели. 

Цикличные операции / процессы 

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

 

Операция со стандартным циклом   

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

 

Множественный цикл

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

 

Преобразовывайте циклические участки процесса в подпроцессы. В данном примере подпроцесс имеет развернутый вид.   

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

 

Компенсация вместо циклической конструкции 

Ручная, автоматическая и пользовательская операция 

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

 

Ручная, пользовательская и автоматическая операция   

BPMN 2.0. Потоки 

Рабочий поток 

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

 

Рабочий поток

Поток работ отражает порядок выполнения операций и процессов 

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

 

Рабочий и информационный поток в диаграмме 

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

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

 

Правила наименования 

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

Располагайте потоки работ горизонтально 

Лучше всего, когда потоки работ идут слева направо, горизонтально. Не стоит располагать элементы процесса таким образом, чтобы поток работ сначала шел слева направо, а потом справа налево.

Направление потоков всегда идет слева направо

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

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

Они не могут соединять объекты внутри одного пула. 

 

Потоки сообщений между пулами 

Информационный поток не содержит в себе документы, лишь информацию 

Поэтому, документы нужно отображать отдельно.

 

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

Неочевидные информационное потоки должны иметь название. 

Очевидный информационный поток, это поток, который исходит из операции или процесса, в наименовании которого понятно, что и куда передается. К примеру, если информационный поток исходит из операции “Отправить отчет”, то такой поток является очевидным. Если поток идет из операции “Подготовка к инвентаризации”, то оно является неочевидным, потому что непонятно, что именно отправляется или получается с этим потоком 

BPMN 2.0. Композиция диаграмм 

Оставляйте достаточно свободного пространства 

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

 

Пространство между элементами диаграммы должно быть достаточным 

Выравнивание элементов диаграммы 

Все элементы диаграммы должны быть выровнены, относительно друг друга. По горизонтали и вертикали.

 

Выравнивание элементов диаграммы относительно друг друга 

Однотипные элементы должны иметь один размер 

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

 

Ограничьте количество элементов на диаграмме 

Не стоит перегружать диаграмму. Чтобы избежать перегрузки, ограничьте количество элементов, которое будет расположено на диаграмме. Лучше разбейте сложные процессы на подпроцессы. Существует общая рекомендация, которая утверждает — диаграмма должна размещаться на печатном листе формата А4. Не всегда это возможно, но при композиции диаграммы всегда нужно учитывать, как и в каком виде ее дальше будут читать. 

 

Диаграмма явно перегружена

  

Оптимально для восприятия

Сохраняйте основную ось процесса — поток по умолчанию 

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

 

Поток по умолчанию — центральная ось. Остальное, это ответвления от него 

Проверяйте грамматику и пунктуацию 

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

BPMN 2.0. Частные случаи 

Когда пул — черный ящик

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

 

Роль в процессе может быть представлена в виде пула — черного ящика   

Кстати, очень удобная конструкция. Позволяет описать процесс, не заходя на территорию, которая не входит, или неподвластна процессу.

Взаимодействие пользователя с ИТ системой

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

 

Взаимодействие пользователя и ИТ системы 

Сбор результатов параллельных потоков

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

 

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

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

Иллюстрация: Оля Ежак для 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 описываются все сценарии взаимодействия пользователей и системы.

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

В YuSMP Group мы отдаем BPMN-диаграммы продуктов после окончания дискавери-фазы. Эта нотация входит в список обязательных артефактов, которые получает клиент.

Что такое BPMN

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

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

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

Почему мы выбираем BPMN

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

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

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

Как выглядит и из чего состоит BPMN

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

На иллюстрации: «Да/Нет».

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

Что нужно запомнить о BPMN

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

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

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

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

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

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

Является ли нотация BPMN лучшей для поставленных перед ней задач? Хороший ответ, актуальный до сих пор, дал еще в семидесятых годах XX века Чарльз Бокс «Все модели неверны, некоторые полезны». BPMN точно полезна, а некоторые ограничения, которые нотация имеет, по мнению экспертов не столь важны на практике:

Моделируя что-либо, мы удаляем некоторые аспекты реального мира, чтобы их визуализировать. И все же ИТ-профессионалы продолжают искать одну истинную нотацию моделирования и набор семантики, чтобы управлять сразу всем. Они предполагают, что должно быть возможно перевести все аспекты и их взаимосвязи на визуальный язык. Я думаю, что большинству людей бизнеса это не нужно. Они используют модели для общения друг с другом … и да, в ходу круги и стрелки, прямоугольники и облака, и … лишь очень немногие заинтересованы в том, чтобы отразить взаимосвязь всех аспектов друг с другом. Дерек Миерс (Derek Miers) – Отраслевой аналитик и консультант. Более 25 лет специализируется в сферах управления бизнес-процессами, цифровой трансформации, бизнес-архитектуры и технологических инноваций. В настоящее время работает в Gartner время на позиции директора по исследованиям в сфере Enterprise Architecture (EA)

Первая версия нотации 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-системы.

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

Хотите узнать больше о платформе Comindware и оценить насколько она подойдёт для вашей компании? Закажите бесплатную демо-презентацию.

Заказать демо

Елена Гайдукова, маркетолог-аналитик. Работает в сфере BPM и автоматизации процессов с 2014 года. В настоящее время является бренд-менеджером решений на базе Comindware Business Application Platform.