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

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

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

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

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

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

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

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

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

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

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

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

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