Владимир Репин - Моделирование бизнес-процессов в нотации BPMN. Практикум в BPMS: Bizagi Digital Platform. Часть II

На описательных моделях не целесообразно показывать операции, которые потом, возможно, придется автоматизировать скриптами, с использованием RPA 2 2 RPA – Robotic Process Automation. и т. п. Это – нюансы настройки конкретной BPMS.

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

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

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

Рис. 2.1. Логические ошибки на схеме.

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

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

Рис. 2.2. Отсутствие шлюзов.

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

Рис. 2.3. Бессмысленный цикл вокруг одной операции процесса.

На рис. 2.4. показана «любимая» многими неопытными разработчиками схем конструкция – последовательное использование нескольких шлюзов исключающего «ИЛИ». Мало того, что в результате увеличивается размер схемы, самое плохое – это крайняя сложность восприятия логики процесса человеком. Как можно сделать по-другому? Просто создать один шлюз исключающего «ИЛИ» и показать все выходящие из него потоки. Для регламента, кстати, в Business Studio можно присвоить таким потокам (переходам) названия, а в их атрибутах указать критерии, на основании которых выбирается соответствующий переход. Тогда можно будет автоматически выгружать эту информацию в регламент.

Рис. 2.4. Сложные шлюзы исключающего «ИЛИ».

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

Рис. 2.5. Отсутствие связи Sequence flow между операциями процесса.

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

Рис. 2.6. Замена операции шлюзом.

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

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

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

Рис. 2.7. Замена операции событием.

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

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.