Как описать бизнес процесс в формате нотации bpmn

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

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

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

Расширение нотации BPMN для более эффективного описания бизнес-процессов

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

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

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

Исходные данные для анализа

Исходные данные для анализа таковы. В ряде компаний (нефтедобыча, производство, ритейл и проч.) проводилось обучение временных рабочих групп (ВРГ) численностью 25-30 человек. Некоторые участники занимались «описанием» процессов при помощи «диаграмм с ромбиками» (в Business Studio — это нотация «Процедура») или сталкивались с нотацией eEPC. Но большинство специалистов созданием графических схем не занимались.

Обучение проводилось в течение 2 дней на основе методического пособия «Моделирование в нотации BPMN. Пособие для начинающих. Часть I» (, 2018 год). В первый день слушателей последовательно знакомили с основами нотации BPMN. Они выполняли ряд связанных между собой заданий, моделируя процесс в среде Business Studio и двигаясь от простого к сложному.

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

Нотации описания бизнес-процессов. Часть 4. Нотация BPMN | Naked BPM

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

Требования и правила моделирования устанавливались в «Соглашении по моделированию» компании.

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

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

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

Типовые ошибки моделирования, допускаемые начинающими

Проблема мышки

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

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

Оборванные

Следующая проблема — это оборванные . У неопытных и довольно безответственных рисовальщиков документы появляются «из воздуха», «зависают» на выходе операций процесса и никуда не попадают. Часто начинающие вообще не показывают на схеме потоки документов/информации.

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

Обсуждая входы/выходы можно отметить два аспекта. Технически на схеме в нотации BPMN в среде Business Studio можно показывать взаимодействие между разными процессами при помощи стрелки типа massage flow, связывая конкретную операцию процесса со свернутым пулом (другой процесс). Для последующей возможности вывода информации о входах/выходах в отчеты к этой стрелке должен быть привязан конкретный документ. Часто неопытные пользователи забывают это делать. Но сама по себе стрелка massage flow без привязанного к ней документа с точки зрения комплексной модели в Business Studio не несет конкретной информации.

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

Бывает обратная ситуация — на модели верхнего уровня входы/выходы есть, а при переходе на уровень вниз на процессы, описанные в нотации BPMN, эти входы/выходы теряются. Иногда на моделях нижнего уровня в нотации BPMN показывают информационные связи с процессами уровня + 2 выше. Как следствие — низкое качество модели компании в целом.

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

На мой взгляд, наличие потока документов на схеме процесса в нотации BPMN в Business Studio необходимо и практически полезно для целей анализа, регламентации и автоматизации.

На рисунке 1 приведен фрагмент схемы процесса с «оборванным» входом для операции «Проверить корректность заполнения заявки». Для операции «Проверить возможность выполнения заявки по режиму» входы/выходы вообще отсутствуют.

Рис. 1. Оборванные и отсутствующие (фрагмент схемы).

Некорректная логика процесса

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

Рис. 2. Пример логической ошибки (фрагмент схемы процесса). Нет входов/выходов.

Непонимание межпроцессного взаимодействия

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

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

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

отправляют сообщение в другой процесс (свернутый пул на схеме в Business Studio), который не должен запускаться (инициироваться) — с ним просто есть взаимодействие по (причем, чаще всего, опосредованное — через базу данных или компании);
отправляют сообщение в свернутый пул под названием «Все процессы», «Поставщик» или, что хуже всего, «Отдел …» (в Business Studio можно создать свернутый пул из так называемой «Внешней ссылки»);
отправляют сообщение в процесс, который находится в дереве на 2-3 уровня выше описываемого и сформирован в нотации IDEF0 — отправка «на деревню дедушке»;
показав отправку сообщения на схеме описываемого процесса, не открывают другой процесс и не дают себе труд продумать, куда попадает отправленное сообщение и как оно повлияет на выполнение другого процесса.

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

Рис. 3. Некорректное использование событий отправки/получения сообщений Нет входов/выходов.

Использование таймеров

используется как по ходу процесса, так и в виде граничного события. Как пример типичной ошибки начинающих приведу следующую формулировку : «Не позднее числа месяца». Когда должен сработать таймер — непонятно. Другой пример — «Ежедневно» (см. рис. 4).

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

Рис. 4. Некорректное использование (фрагмент схемы).
Нет входов/выходов.

Описание процесса для одного объекта, которых в реальности множество

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

Процесс в процессе (рекурсия)

Довольно часто можно наблюдать такую картину. Берем для анализа процесс под ‘ названием. Начинаем смотреть его детальную схему в BPMN. Видим кучу действий с бумажками (служебки, распоряжения, отчеты, поручения и проч.). среди всей этой волокиты видим операцию, название которой в точности повторяет название процесса в целом . И это называется описать процесс!

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

Красота схемы

Здесь все печально. Только 10-15% сотрудников стремятся сделать схемы красивыми. Для остальных это третьестепенная задача. Но некрасивую схему не хочется брать в руки, а тем более анализировать. Визуальная красота схемы — залог ее проработанности, что снижает трудоемкость последующих согласований и внесения изменений.

Накопление опыта и исправление ошибок

По ходу выполнения проекта сотрудники накапливают опыт моделирования процессов. Степень проработки и качество моделей процессов становятся существенно выше. При интенсивной работе ВРГ (2-3 модели процессов в неделю), через 1-1,5 месяца можно говорить о приемлемом уровне качества описания моделей процессов.

Хотел бы отметить, что для освоения навыков моделирования процессов на операционном уровне (в нотации BPMN) очень полезно показать сотрудникам имитацию выполнения процесса в Business Studio. Еще лучше, если после этого они сами попробуют запустить на имитацию отрисованный ими процесс, причем сначала пошагово, чтобы почувствовать себя той самой «мышкой» (токеном). Это упражнение дает хорошее понимание сути моделирования процессов Work Flow.

Выводы

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

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

«мышка» или идеология исполняемых процессов;
информационное взаимодействие внутри процесса и между процессами («стыковка по входам/выходам»);
корректное использование событий сообщений и синхронизация процессов между собой по событиям;
соблюдение уровней при описании межпроцессного взаимодействия (процесс BPMN может отправить сообщение только в процесс BPMN);
корректное использование ;
четкое отслеживание множественных объектов для обработки;
визуальная наглядность схемы («Красота схемы»).

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

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

Важно отметить, что осознанность и мотивация на качественный результат у участников ВРГ — так же критически важные аспекты моделирования .

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

Опубликовано по материалам портала http://www.finexpert.ru/

11.2018

Источник: www.interface.ru

Зачем нужна BPMN – нотация?

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

Пример бизнес-процесса, который описан в системе BPMS с использованием нотации:

Элементы BPMN

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

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

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

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

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

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

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

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

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

Описание процесса

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

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

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

Подробней о нотации можно прочесть перейдя по ссылке — BPMN

Источник: itblog21.ru

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

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

Событийно-процессные нотации бизнес-моделирования: основы диаграмм BPMN, EPC и UML activity

Описать логику выполнения процесса — одна из самых частых задач в профессиональной деятельности системных и бизнес-аналитиков. Она решается с помощью событийно-процессных нотаций моделирования, к которым относятся UML-диаграмма деятельности (UML activity), BPMN (Business Process Model and Notation) и EPC (Event-Process Chain). Хотя построенные по правилам этих нотаций диаграммы немного отличаются внешне, все они по сути представляют собой направленный или ориентированный граф, вершинами которого являются шаги бизнес-процесса, (действия, задачи или функции), а ребрами — стрелки потока управления. Поток управления движется непрерывно от стартовой точки (начало бизнес-процесса) до его окончания (финишной точки), соединяя шаги процесса последовательно или через логические операторы (шлюзы, развилки), не допуская «висячих» вершин. Помимо функций/задач в EPC/BPMN поток управления также соединяет события.

Событийно-процессная диаграмма начинается стартовым событием и заканчивается финишным. Можно сказать, что они ограничивают бизнес-процесс, т.е. определяют его границы (о том, что это такое и зачем это нужно, читайте здесь). В UML activity начало и конец процесса обозначаются черными кругами, в BPMN они могут уточняться типом события (сообщение, таймер и пр.), а в EPC — подробной формулировкой (наступило 1-е число отчетного месяца). Поскольку событие — это уже свершившийся факт, это следует отражать в его названии. Например, «позвонить клиенту» — это НЕ событие, а «сделан звонок клиенту» — это событие.

Шаги бизнес-процесса, их участники и артефакты

Процесс состоит из набора шагов (действия в UML activity, функции в EPC и задачи в BPMN), каждый из которых следует представлять в отдельном блоке с названием в виде глагола или отглагольного существительного. Например, «разработка ТЗ» или «разработать ТЗ».

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

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

Немного булевой алгебры: логические операторы и шлюзы

Поскольку диаграммы UML activity, EPC и BPMN позволяют описать логику выполнения бизнес-процесса, в отличие от просто структуры, которую лучше всего показывать в IDEF0, неудивительно что в событийно-процессных нотациях появляются логические операторы. В бизнес-логике их 3: логическое И (AND), логическое ИЛИ (OR) и исключающее ИЛИ (XOR).

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

Например, если условия коммерческого предложения не подошли клиенту, он может сообщить о желании их изменить ИЛИ отказаться от заключения договора. В этом случае один исход исключает другой, поэтому используется оператор XOR — исключающее ИЛИ. А если один поток не противоречит другому, например, позвонить по телефону или написать письмо, или сделать и то, и другое, подойдет оператор OR. Наконец, если запускаются/сливаются несколько потоков управления, каждый из которых должен дождаться остальных, используется AND.

Операторы бизнес-логики: AND, OR, XOR
Примечательно, что в UML activity есть только блок «Решение», эквивалентный исключающему ИЛИ (XOR) и блоки слияния/разделения потоков управления, эквивалентные логическому И (AND), а оператор OR отсутствует. В BPMN и EPC есть все 3 логических оператора, причем в BPMN они различаются по типу (управляемый данными, управляемый событиями и пр.). Причем в BPMN и EPC следует строго соблюдать правило соединения потоков управления через шлюзы, т.е. в 1 блок задачи/функции входит только 1 стрелка потока управления и выходит тоже только 1. Для слияния и разветвления потоков используются AND, OR, XOR. Обычно оператор, разделивший потоки управления, должен их соединить. Это легко проверить, посчитав на диаграмме количество логических операторов одного типа — оно должно быть четным, если одна из веток не прерывается окончанием процесса.

Как описать бизнес-процесс в BPMN, EPC, UML activity: практический пример

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

— Старт процесса начинается с момента, когда клиент оставил заявку на сайте.

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

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

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

— Менеджер формирует проект договора и отправляет его на согласование клиенту.

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

— В случае возражений к проекту договора клиент вносит в него изменения и направляет менеджеру.

— Менеджер формирует новый проект договора и снова отправляет клиенту на согласование, т.е. идет возврат к шагу 5.

Диаграмма BPMN для этого примера выглядит довольно просто и понятно.

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

Пример EPC-диаграммы (кликабельно, нажмите для увеличения)
А ограниченный алфавит нотации UML activity обусловливает аскетичный вид следующей диаграммы. Например, из-за отсутствия неисключающего ИЛИ (OR) вместо него пришлось использовать AND, что на самом деле не совсем соответствует реальности. AND предполагает выполнение обоих действий (позвонить и отправить письмо), хотя в действительности может быть достаточно одного из них.

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

А подробно освоить все эти нотации моделирования бизнес-процессов вам помогут мои авторские курсы в Школе прикладного бизнес-анализа на базе нашего лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

Источник: medium.com