Бесплатный фрагмент - Моделирование бизнес-процессов в нотации BPMN

Введение

Вы держите перед собой вторую часть книги «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих». В Части I на простых примерах рассматривались основы моделирования бизнес-процессов в нотации BPMN.

Часть II поможет вам практически применить нотацию BPMN для настройки исполняемых процессов в BPMS — специализированном программном обеспечении для автоматизации бизнес-процессов. Это даст возможность освоить суть подхода и использовать его для оптимизации бизнес-процессов своей компании. Тем, кто не знаком с нотацией, рекомендую начать изучение BPMN с Части I.

В первом разделе книги рассматриваются практические аспекты имитационного моделирования бизнес-процессов в среде Business Studio. Настройка, запуск имитации и анализ ее результатов помогут вам на простом примере вникнуть в суть исполняемых процессов — освоить понятие токена и экземпляра процесса. Кроме того, вы сможете изучить метод анализа процессов на основе показателей времени выполнения и стоимости. Данный раздел может быть полезен читателям, использующим программный продукт Business Studio для проектирования, анализа и регламентации бизнес-процессов. Следует отметить, что имитационное моделирование — это эффективный инструмент проектирования. С его помощью можно проверить спроектированный процесс на эффективность до внедрения, тем самым сэкономив время и деньги.

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

В третьем, основном разделе книги последовательно раскрывается методика настройки и запуска на исполнение группы связанных между собой процессов в BPMS Bizagi Digital Platform (далее Bizagi). Процессы, используемые в качестве примера, были представлены в комплексном задании по моделированию процессов в Части I книги.

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

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

Автор выражает глубочайшую признательность за помощь в настройке исполняемых процессов в Bizagi коллеге по ассоциации ABPMP, BPM-эксперту, сертифицированному специалисту Bizagi — Вагнер Юлии Борисовне. Так же автор благодарен Людмиле Калошиной и Егору Репину за содействие при подготовке книги.

1. Имитационное моделирование бизнес-процессов в Business Studio

В данном разделе показано, как создать, настроить и использовать имитационную модель процесса в среде проектирования процессов Business Studio.

Имитационная модель позволяет «оживить» схему процесса, проведя необходимое количество его запусков в течение заданного времени. При этом расчет выполняется во много раз быстрее реального времени.

Простые, линейные схемы процессов, состоящие из 4—5 шагов, не нуждаются в имитации. С ними и так все понятно — достаточно взять в руки калькулятор и сделать простейшие расчеты. Но параметры процесса, имеющего логически сложную схему с большим количеством возвратов, уже не могут быть легко рассчитаны. Нужна автоматизация. Программный продукт Business Studio позволяет настроить достаточно сложные имитационные модели процессов, выполнить имитацию, анализ и обосновать мероприятия по улучшению процессов вашей компании.

1.1. Модель в Business Studio

На рис. 1.1 представлена схема процесса, для которой будет настроена имитационная модель. Данную схему необходимо создать в программном продукте Business Studio. Если у вас нет этой программы, то можно написать мне на адрес info@bpm3.ru для получения полнофункциональной временной лицензии на один месяц.

В Business Studio нужно создать новую модель в нотации BPMN. На модели в горизонтальном формате показать четыре дорожки: Инициатор платежа (роль), Начальник Инициатора платежа (роль), Экономист ФЭО (должность), Генеральный директор (должность). Далее сформировать графическую схему, при этом названия всех объектов и логика должны соответствовать представленным на рис. 1.1.

На рисунке 1.1 вы видите надписи: «Раб. Константа», «Ожид. Нормальный» и «Ожид. Константа» с цифрами. Это параметры времени для имитации — рассмотрим их чуть ниже. Красные надписи с процентами, показанные рядом со стрелками, в Business Studio создать нельзя — они созданы и скопированы из MS Visio для наглядности. Ниже станет понятно, зачем они нужны.

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

• нагрузка на процесс — количество и интенсивность возникновения стартовых событий;

• нормативное время выполнения операций;

• вероятность логических переходов;

• стоимость ресурсов (рабочего времени участников процесса).

Рассмотрим, как настроить указанные параметры, тем самым создав имитационную модель бизнес-процесса.

1.2. Определение нагрузки на процесс

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

В следующем столбце «Интервал» нужно выполнить настройки так, как показано на рис. 1.2. Для рабочего времени нужно указать «Базовый календарь». Далее указать период повторения «Ежедневно», «Каждый 1 рабочий день», по «Базовому календарю», Окончание — «нет конечной даты». Параметр «Начало» можно указать, например, 01.01.2020.

Настройка календаря дает системе Business Studio возможность использовать интервал времени, в течение которого допустимо возникновение стартовых событий процесса. Замечу, что вы можете создавать и использовать свои календари — круглосуточный, «сутки через двое», ночную смену и любые другие.

Далее настроим количество возникающих событий, как показано на рис. 1.3. (столбец — «Количество экземпляров события»).

Для моделирования количества событий использовано обрезанное нормальное распределение. Выберите тип закона распределения «Нормальный» и настройте его параметры, как показано на рис. 1.3.

Видно, что в среднем в день возникает девять заявок на оплату, т.е. инициируется девять экземпляров процесса «Подача заявки на оплату».

Далее нужно настроить распределение в части поступления заявок на оплату в течение рабочего дня, как показано на рис. 1.4. (столбец — «Закон распределения»). Экземпляры процессов «Подача заявки на оплату» могут возникать в течение дня в интервале с 9—00 до 18—00, при этом с пиковой нагрузкой в 15—00 (нижняя граница — 9—00, верхняя граница — 18—00, матожидание — 15—00, стандартное отклонение — 3—00).

Как практически узнать вид распределения? Необходимо собрать и проанализировать данные управленческого учета, либо организовать и провести соответствующий хронометраж. В некоторых случаях можно обосновать выбор параметров выполнения теоретически, например, в случае разработки нового процесса «с нуля».

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

1.3. Нормативное время выполнения операций процесса

Следующим шагом необходимо задать нормативное время выполнение операций процесса.

Выберите, для примера, операцию «Согласовать заявку» на дорожке «Начальника инициатора платежа». Для этого нужно выделить эту операцию мышкой и по правой кнопке выбрать «Свойства объекта», а затем открыть закладку «Параметры ФСА». Нажмите кнопку с тремя точками справа от параметра «Время выполнения». В открывшемся окне выберите тип закона распределения «Константа» и укажите время 5 минут. Это означает, что процесс задержится на этой операции ровно на 5 минут — нормативное время выполнения.

На рис. 1.7 показана настройка времени ожидания. Выберите закон распределения «Нормальный» и задайте параметры как показано на рисунке.

Время ожидания в данном случае задано для того, чтобы имитировать ситуацию с недоступностью ресурса — начальника инициатора платежа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Полезные видео по практике работы в Business Studio вы можете посмотреть на моем канале: 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 и т. п. Это — нюансы настройки конкретной BPMS.

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

---

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

2.2. Логические ошибки и лишние элементы
(плохой стиль)

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

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

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

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

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

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

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

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

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

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

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

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

С точки зрения логики выполнения, наличие двух шлюзов неисключающего «ИЛИ» в таком виде, как показано на рис. 2.9., является бессмысленной конструкцией, так как процесс все равно пойдет дальше не зависимо от какого-либо события. С другой стороны, в BPMS на данных события можно изменять статусы и проч. Для BPMS такая конструкция может иметь определенный смысл. Хотя те же действия можно сделать на выходе из операции.

2.3. Лишние элементы/отсутствие необходимых элементов

На рис. 2.10 показана ситуация чрезмерной, необоснованной детализации операций на схеме процесса. В первом случае можно вообще не упоминать про получение и передачу документа — в модели процесса это и так понятно. Если уж очень сильно хочется об этом написать, то это можно сделать в атрибуте «Комментарий» в свойствах операции процесса (в Business Studio).

---

На рис. 2.11. показана ситуация, схожая с представленной на рис. 2.10. После шлюза показаны две лишние операции. Они не повышают информативность модели, но при этом заметно увеличивают ее размер.

Рис. 2.12 иллюстрирует ситуацию, когда разработчик хотел описать цикл управления. Но с точки зрения Work Flow операция контроля наступит сразу после постановки задачи, т.е. исполнители еще ничего не успеют сделать. Да, с точки зрения BPMS эта операция будет запущена, но не завершена, пока контроль не будет выполнен.

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

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

2.4. Использование событий отправки/получения сообщений

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

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

Слева показано, что сотрудник «как бы отправляет пакет документов» другому сотруднику. Видимо, автора схемы смутил маркер конверта.

Во втором случае (фрагмент схемы справа) автор интерпретирует событие с конвертом сначала как заявку на согласование, а потом как документ — список кандидатов на обучение. Оба варианта использования некорректные. Правильный способ использования событий отправки/получения сообщения описан в Части I данной книги.

Важно, что практически освоить метод отправки/получения сообщений между разными процессами вы сможете, изучив Раздел 3 данной книги.

Довольно часто пользователи создают на схеме событие отправки сообщения, интерпретируя его как документ, а потом ставят End, как показано на рис. 2.14. Если действительно нужно отправлять сообщение в другой процесс, то можно сделать завершающее событие отправки сообщения, а обычный End просто убрать — он лишний.

2.5. Использование таймеров

Весьма многие неопытные пользователи BPMN некорректно интерпретируют и используют граничные события-таймеры, как показано на рис. 2.15.

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

«Картиночка с часиками» не предназначена для того, чтобы описать требования к нормативному времени выполнения процесса или показать ограничения по срокам предоставления каких-то документов. Так делать нельзя. Правильные примеры приводятся в Части I книги.

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

Обратите внимание на формулировку таймера на рис. 2.17 — «Не позднее…». Она означает, что таймер сработает ровно через 2 дня после «…подписания чего-то…». Это означает, что процесс будет стоять и ждать, что бессмысленно.

Замечу, что при наличии нескольких стартовых событий желательно использовать шлюзы (см. Часть I книги).

2.6. Использование маркеров операций

Часто неопытные разработчики используют на описательных схемах в нотации BPMN маркеры, значения которых не понимают, но пытают интерпретировать на основе своего опыта и здравого смысла. Так делать нельзя. Маркеры в BPMN имеют конкретный смысл. Например, на рис. 2.18 пользователь показал маркер получения сообщения, интерпретировав его как получение сообщения по электронной почте. В BPMN это означает совершенно другое — то, что экземпляр процесса получается управляющее сообщение из экземпляра (возможно, нескольких) другого процесса.

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

3. Настройка исполняемых процессов в BPMS Bizagi

3.1. Установка Bizagi на локальный компьютер

В данном разделе представлен комплексный пример настройки и запуска на исполнение в BPMS Bizagi трех связанных между собой бизнес-процессов.

Для выполнения практической работы нужно скачать и установить программу Bizagi Studio с сервера https://www.Bizagi.com.

Для работы Bizagi необходимо установить MS SQL Server версии 2008 (и выше) и компонент SQL Server Management Studio. Если на вашем РС еще не установлен SQL Server, то при установке Bizagi можно выбрать опцию «Install SQL Server Express» и программа установит локальный экземпляр MS SQL Server Express (логин sa пароль BizagiBPM123).

Если вы установили SQL Server самостоятельно (программу можно бесплатно скачать с сайта компании Microsoft), то при установке Bizagi необходимо выбрать опцию «Verify access to SQL Server database already installed» и ввести логин и пароль администратора СУБД Bizagi.

После установки программы, вы можете запустить Bizagi и создать новый проект под названием «BPM3», как показано на рис. 3.1.

Если при установке вы пропустили шаг верификации подключения к MS SQL Server, то при создании проекта вам необходимо будет указать логин и пароль, которые вы задали при установке MS SQL Server, см. рис. 3.2.

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

Будьте внимательны! Можно отмечать на полях карандашом те действия, которые вы уже сделали.

3.2. Создание графических схем процессов