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

Так как мы будем имитировать один процесс, а не все, в которых участвует данный сотрудник, за счет использования параметра «Время ожидания» мы можем показать, что процесс ждет ресурс (начальника инициатора платежа) от до 30 минут до 4 часов.

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

Конкретный вид распределения выбран просто для тренировки в рамках создания модели.

На схеме процесса (рис.1.1) показаны параметры «Раб. Константа», «Ожид. Константа» и другие. Вам нужно настроить время выполнения и время ожидания для каждой операции процесса в соответствии с теми данными, которые приведены на этой схеме.

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

Рис. 1.7. Время ожидания.

1.4. Логика процесса

Далее настроим логику процесса, как показано на рис. 1.8. Для примера, выделите правой кнопкой и откройте свойства стрелки «Есть замечания по заявке», которая выходит из шлюза «Заявка согласована?» после операции «Согласовать заявку» (на дорожке «Начальник инициатора платежа»). В «Параметрах ФСА» нужно указать вероятность 0,2. Это означает, что с вероятностью 20% поток процесса пойдет по указанной стрелке. На рис. 1.1 красным цветом показаны вероятности для всех стрелок, расположенных после шлюзов типа исключающего логического «ИЛИ». Их нужно настроить.

Рис. 1.8. Настройка вероятности переходов.

В Business Studio можно использовать маршрутизацию при выполнении процесса по вероятности (простой вариант), либо по переменным на основе условий (более сложно). Тема настройки и использования переменных для маршрутизации процесса выходит за рамки данной книги, но вы можете найти информацию в руководстве по Business Studio.

1.5. Стоимость ресурсов

Далее нужно настроить стоимость рабочего времени сотрудников для того, чтобы система могла рассчитать стоимость выполнения одного экземпляра процесса. Выделите мышкой дорожку «Инициатор платежа» и по правой кнопке откройте «Свойства объекта». В «Параметрах ФСА» нажмите гиперссылку «Создать смену по умолчанию». Укажите количество экземпляров – 1, ставку в час – 150, валюту ставки – рубли.

Далее для Начальника инициатора платежа укажите для «Ставка в час» значение 250 рублей, для Экономиста ФЭО – 175 рублей, для Генерального директора – 1500 рублей.

Рис. 1.9. Настройка стоимости ресурсов.

1.6. Имитация процесса

Все готово для запуска имитации процесса. Найдите над моделью кнопку «Запуск имитации» (циферблат с зеленой стрелкой в правом верхнем углу иконки) и нажмите ее. Появится окно следующего вида (рис. 1.10). Нужно выбрать период имитации – один месяц. Шаг имитации – 1 минута. Валюта имитации – рубли. Далее нажмите кнопку «Запустить пошаговую имитацию».

Рис. 1.10. Запуск имитации.

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

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

Если нажать кнопку «Продолжить», то имитация будет выполняться автоматически – см. рис. 1.12.

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

Таким образом, в многократно ускоренном темпе система Business Studio имитирует реальное выполнение процесса. Когда имитация завершится, нажмите кнопку «Закрыть».

1.7. Анализ результатов имитации процесса

Результаты имитации представлены на рис. 1.13. Для примера, выберите закладку «Статистика по временным ресурсам», выберите Экономиста ФЭО и в открывшемся окне нажмите гиперссылку «График работы экземпляра».

Рис. 1.13. Результаты имитации процесса.

На рис. 1.14 показан график загрузки Экономиста ФЭО. Зеленым показаны часы его работы. Видно, что этот сотрудник весьма сильно загружен работой по проверке заявок на оплату – у него остается не так уж много свободного рабочего времени. Обратите внимание, что посмотреть этот график можно только до формирования отчета по имитации (после формирования отчета он становится недоступным).

Далее запустите создание отчета по результатам имитации (см. кнопку отчеты вверху страницы слева). В результате будет сформирован и выгружен в файл MS Word сводный отчет по результатам имитации. Его фрагмент показан на рис. 1.15. Вы можете посмотреть параметры среднего времени выполнения и стоимости одного экземпляра процесса. Так же можно выполнить анализ разброса значений и гистограммы.

Теперь вы умеете настраивать простые модели для имитации и выполнять их анализ. При построении более сложных моделей могут потребоваться дополнительные знания, которые вы сможете получить в гипертекстовой справке по системе Business Studio: https://www.businessstudio.ru/wiki/docs/v4/doku.php/ru/start (https://www.businessstudio.ru/wiki/docs/v4/doku.php/ru/start).

Полезные видео по практике работы в Business Studio вы можете посмотреть на моем канале: www.youtube.com/VladimirRepinBPM (http://www.youtube.com/VladimirRepinBPM).

2. Типовые ошибки создания описательных моделей в нотации BPMN в Business Studio

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, наоборот, это не нужно. Такая информация просто будет во многом лишней для настройки.

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

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

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

2.2. Логические ошибки и лишние элементы

(плохой стиль)

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

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

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

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

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