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

2.1. Различия между описательными и исполняемыми моделями процессов

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

Если у вас нет цели прямо сейчас автоматизировать процессы в BPMS, то вы можете научиться проектировать аналитические или, говоря другими словами, описательные модели процессов в нотации BPMN в Business Studio (MS Visio, ARIS, iGrafx и проч.).

После выбора и изучения конкретной BPMS вы сможете доработать модели процессов так, чтобы они: а) стали исполняемыми; б) учитывали функциональные возможности и уровень поддержки нотации BPMN в конкретной BPM-системе.

Давайте сравним описательные и исполняемые модели процессов в следующей таблице.

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

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

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

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

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

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

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

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

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, конечно, недопустима. На схеме необходимо показать полноценную операцию согласования, выполняемую исполнителем.

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

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

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

Рис. 2.8. Непривязанные стрелки.

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

2

RPA – Robotic Process Automation.