Нотация bpmn: задачи и особенности

Введение

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

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

Введение. Типовые задачи описания бизнес-процессов. Требования к описанию бизнес-процессов предприятий.

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

Наиболее часто в этом случае задают следующие вопросы (по степени важности для спрашивающих):

1. какое программное обеспечение использовать в проекте («ARIS лучше BPwin?», «ERwin лучше ARIS?» и т.п.);
2. как моделировать процессы с использованием продукта «Х»?;
3. как проводить анализ и выявлять проблемы при помощи продукта «Х»?;
4. какую методологию использовать для описания процессов?

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

1. целей проекта;
2. требований к информации, характеризующей бизнес-процессы и необходимой для анализа и принятия решений в рамках конкретного проекта;
3. возможностей CASE-систем по описанию процессов с учетом требований п.2.

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

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

1. какие процедуры (функции, работы) необходимо выполнить для получения заданного конечного результата;
2. в какой последовательности выполняются эти процедуры;
3. какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса;
4. кто выполняет процедуры процесса;
5. какие входящие документы/информацию использует каждая процедура процесса;
6. какие исходящие документы/информацию генерирует процедура процесса;
7. какие ресурсы необходимы для выполнения каждой процедуры процесса;
8. какая документация/условия регламентирует выполнение процедуры;
9. какие параметры характеризуют выполнение процедур и процесса в целом.

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

Стартовые события

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

В случае подпроцесса (как на диаграммах выше) стартовое событие – «отмашка» от процесса/подпроцесса уровнем выше: завершили один подпроцесс, переходим к другому.

Но в данном случае это не так – инициатором является внешнее событие:

• заказ сырья инициируется фактом снижения запасов ниже нормативного минимума
• прием инициируется фактом прихода груза от поставщика
• оплата инициируется платежным календарем (например, еженедельно)

Событие произошло – отрабатываем его; событие не произошло – ничего не делаем. Этот сценарий в BPMN соответствует запуску процесса, а не подпроцесса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Результат, который должен обеспечить БП, получение покупателем товара нужной ему номенклатуры. Выполнение этого БП происходит в несколько этапов:

1. Специалисту, задействованному в продажах, поступает заявка от клиента о потребности в определенном товаре.
2. Системой CRM создается соответствующая заявка от клиента – документ.
3. При наличии указанного в заявке товара менеджером создается расходная документация в программе по учету. В случае отсутствия товара менеджеру необходимо подать запрос в отдел закупок.
4. Отделом закупок формируется запрос поставщику на получение необходимой продукции.

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

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

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

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

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

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

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

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

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

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

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

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

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

НЕМНОГО ИСТОРИИ BPMN

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

Первая версия BPMN 1.0 была выпущена в мае 2004 года компанией Business Process Management Initiative. Эта версия обладала ограниченными возможностями и была, так сказать, «пробным вариантом», который нуждался в многочисленных доработках.

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

Еще один релиз появляется всего через год, версия BPMN 1.2 выходит в свет в январе 2009. Разработчик OMG остается прежним. Команда, которая занимается продуктом, после слияния практически не меняется.

В январе 2011 года компания OMG выпускает версию BPMN 2.0, а в декабре 2013 выходит последний на данный момент релиз – BPMN 2.0.2. Именно эта версия предлагается всем пользователям и сегодня, так как система получилась стабильной, возможности моделирования в ней очень широкие, а язык моделирования (набор обозначений) по большей части понятен всем бизнес-пользователям – как бизнесменам, бизнес-консультантам, так и техническим специалистам.

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

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

Я особенно хочу подчеркнуть этот момент, так как и сам столкнулся поначалу с непониманием, зачем те или иные вещи усложнять? Ведь для описания бизнес-процессов, например, при GAP-анализе (анализ разрывов) или для представления заказчику бизнес-модели в какой-то упрощенной форме, всего многообразия элементов BPMN вам не нужно. Но когда начинается автоматизация, когда бизнес-модель становится не просто удобной схемой, а может экспортироваться в другие программные продукты в качестве исполняемых данных, все становится на свои места. Последняя версия 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, делят на два этапа:

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

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

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

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

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

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

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

Пример исключающего ИЛИ

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

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

Пример логического И

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

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

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

Пример использования эксклюзивного шлюза по событиям

The history of BPMN

Business Process Model and Notation was originally developed under another name in 2000 by the Business Process Management Initiative — a non-profit organization founded by industry BPM leaders from companies like Ernst & Young and Versata.

The aim was to standardize how processes were visually represented, and that aim has been carried on since 2004 by Object Management Group — a NFP technology standards consortium, snappily abbreviated as OMG.

As businesses change — and IT becomes more vital — OMG keep BPMN updated, and able to handle new kinds of processes. At the time of writing, we’re on BPMN 2.0, which defines more symbols and map types to represent the real ways modern organizations get work done.

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

Как мы сказали выше, BPMN представляет собой систему условных обозначений для моделирования бизнес-процессов. Процессы в нотации представлены в виде графических последовательностей.Ниже на иллюстрации приведён пример процесса — поиска и приёма на работу нового сотрудника.Фрагмент описания бизнес-процесса в нотации BPMNРазберём основные элементы нотации. Их будет достаточно для большинства схем.Процесс (задача, подпроцесс). Задача — действие или операция, у которых нет дальнейшей декомпозиции в рамках процесса. Подпроцесс — декомпозированный процесс, в который включено несколько задач. На диаграмме он обозначается блоком со знаком +.Примеры задач в иллюстрации выше — «Заявка на подбор нового сотрудника», «Проведение собеседования». Часто задачи формулируют через глагол: «Провести собеседование», «Подобрать сотрудника».Событие. Показывает состояние, которое влияет на дальнейшее течение бизнес-процесса или контролирует его. Примеры событий — старт процесса, его завершение, смена статуса документа, получение сообщения.Любая схема должна начинаться со стартового события и завершаться конечным. Промежуточных событий в процессе может и не быть, поэтому это необязательный элемент.В нашем примере стартовые события — «Потребность в расширении штата» и «Текущий сотрудник написал заявление на увольнение».Шлюзы. Показывают слияния потоков управления в рамках процесса. Среди них выделяют:Объект данных. Показывает, какие объекты сопровождают выполнение процесса. Например, бумажный документ, электронный документ, информацию и так далее.В нашем примере объекты данных — «Заявка на подбор», «Лист оценки кандидата», «Предложение о работе».Потоки. Это стрелки, которые показывают движение по процессам и порядок их выполнения. Есть несколько видов потоков:Пулы (дорожки). Показывают участников бизнес-процессов. Например, должности, подразделения, роли, внешние субъекты. Дорожка не может соответствовать системе или другим объектам — только людям.Например, в нашей иллюстрации дорожки соответствуют кандидату, HR-менеджеру, руководителю отдела.Полный список элементов, которые используют в нотации, можно посмотреть здесь.Существует много инструментов для разработки процессов в BPMN. Мы рекомендуем бесплатный онлайн-сервис Diagrams.net. В нём можно создавать схемы, модели, диаграммы и обмениваться ими в браузере.

Нотация BPMN: что это такое и почему она популярна

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

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

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

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

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

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

Событие (Event) обозначает происходящее в бизнес-процессе.На иллюстрации: «Вход на сайт».

Развилки (Gateway) разъединяют и объединяют пути клиента.На иллюстрации: «Есть логин и пароль?».

Соединительные элементы (Flow) — это линии, ведущие от одного объекта к другому.

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

Действия (Activity) отображают работу, которая происходит в пределах конкретного процесса.На иллюстрации: «Запросить у владельца курса логин и пароль».

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

Артефакты (Artefact) обозначают информацию, имеющую отношение к модели, но не к отдельным элементам внутри процесса.В нашем фрагменте нет артефактов, но вот пример, как они могут выглядеть.

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

Diagram tools that support BPMN

It’d be mad to use a pen and paper for technical drawing like this, so take your pick from the range of BPMN tools available:

Draw.io

Draw.io is an amazing tool, especially considering that it’s 100% free. You can pay for features like integrations and compliance, but overall the core software is free, supports every BPMN symbol, and makes it easy to create great process maps.

Microsoft Visio [$15.50/month]

Microsoft’s behemoth of a process mapping tool — Visio — is the industry standard that all other mapping tools wish they could take down. Just because it’s the most widely used doesn’t mean it’s the best; it’s widely used because it’s packaged with Office 365 and other Microsoft packages. It doesn’t integrate, it’s incompatible on Mac, and it’s the most expensive.

It is, however, easy to use and is the subject of a lot of helpful guides around the web.

Lucid Chart [starting at $4.95/month]

While Visio is quite a rigid product, Lucidchart allows for real time collaborative editing, chat, and comments. That can make process development in BPMN a collaborative activity, encouraging teams to work together and helping keep the process accurate with less margin for error.

SmartDraw [$14.95/month]

SmartDraw was designed with power users in mind, but that doesn’t mean it’s hard for new users to pick up. It groups its symbols in a similar way to Draw.io, meaning that all your BPMN symbols will be in one place, easy to access.

Additionally, it includes a method of quickly drawing flows that link together:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Published by YuSMP Group in Блог, Статьи

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

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

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

• Когда начинается процесс. В нашем примере это момент получения заявки от клиента. Если компания использует CRM, точкой входа будет попадание заявки в систему.
• Когда процесс закончится. Это момент успешной реализации сделки: клиент оплатил счёт, а продавец и логист организовали доставку.

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

Задаём границы бизнес-процессаИнфографика: Майя Мальгина для Skillbox Media

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

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

Здесь лежит шаблон текстового описания процесса.

3. Выделяем основные этапы процесса. На основе описанного в предыдущем пункте процесса составляем блок-схему. В графическом редакторе рисуем каркас — основные этапы в пределах границ входа и выхода.

Рисуем каркас — основные этапы процессаИнфографика: Майя Мальгина для Skillbox Media

4. Добавляем детали. Наполняем каркас «мясом» — основными событиями по процессу и действиями исполнителя по алгоритму.

Добавляем детали — основные события процесса и действия исполнителяИнфографика: Майя Мальгина для Skillbox Media

5. Задаём роли. В процессе может быть несколько исполнительских ролей. Их может выполнять один или несколько сотрудников. Обычно роли обезличены, без уточнения фамилий, — только должности.

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

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

Фрагмент процессной модели бизнес-процесса: основные действия менеджера по продажамИнфографика: Майя Мальгина для Skillbox Media

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