Моделирование бизнес-процессов в нотации BPMN. Практикум в BPMS: Bizagi Digital Platform. Часть II - стр. 6
2.2. Логические ошибки и лишние элементы
(плохой стиль)
На рис. 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, конечно, недопустима. На схеме необходимо показать полноценную операцию согласования, выполняемую исполнителем.