Рис. 14. Пример логической ошибки на схеме процесса.

Рассмотрим вопрос старта процесса несколькими событиями. Эта ситуация часто возникает на практике при создании схем для целей анализа и оптимизации, реже – для автоматизации.

На рис. 15 показано три варианта старта процесса двумя альтернативными событиями.

Рис. 15. Старт процесса несколькими событиями и шлюзом «ИЛИ».

Вариант 1 – возникает два события. После них стоит шлюз «Исключающее ИЛИ». Поток работы запускается одним из возникших событий.

Вариант 2. Процесс так же инициируется двумя событиями по альтернативе. Но шлюз «ИЛИ» стоит не в начале процесса. Этот вариант вполне допустим. Нужно только быть аккуратнее и не забывать про эту альтернативу.

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

Вариант 3 – когда нужно на одной схеме показать два потока работ, которые вообще не связаны между собой и запускаются различными событиями. Для этого использованы два шлюза «Исключающее ИЛИ», стоящие друг за другом.

Если вас смущает такая конструкция, то можно поместить еще одну задачу между этими шлюзами. Она будет, например, анализировать данные и определять, как маршрутизировать процесс дальше. Хотя в BPMS такие действия вполне можно «повесить» на сами шлюзы.

На рис. 16 показана ситуация, когда нужно запустить процесс при одновременном возникновении двух и более стартовых событий. Используется шлюз «И». С точки зрения моделирования процессов в Business Studio для целей анализа и регламентации так делать можно. Но с точки зрения нотации BPMN и автоматизации в BPMS такой вариант не является корректным. Имейте это в виду.

Рис. 16. Старт процесса несколькими событиями шлюзом «И».

Более сложные инструменты нотации BPMN, используемые для моделирования запуска процесса несколькими событиями будут рассмотрены ниже.

На рис. 17 показано применение конечного события-терминатора (Terminate). В Business Studio такое событие имеет так называемый триггер «Завершение». На рис. 17 терминатор – это End с черным кружком внутри.

После старта процесса и выполнения Задачи 1 одновременно начинают выполняться три потока. Если нижний поток (Задачи 8 и 9) завершается раньше других, то срабатывает терминатор. Оставшиеся два потока будут остановлены, а экземпляр процесса в целом завершен. Содержательно это можно интерпретировать так, что завершение одного потока делает бессмысленным выполнение оставшихся задач в других потоках процесса. Не используйте терминатор без четкого понимания его назначения.

Рис. 17. Использование «Терминатора» для завершения всех потоков в рамках одного экземпляра процесса.

В нотации BPMN существует несколько маркеров для задач. При моделировании в Business Studio они могут использоваться для визуального представления типа выполняемой задачи, что делает схему понятнее. На рис. 18 показаны представленные в Business Studio маркеры задач.

Рис. 18. Маркеры задач.

Как правило при моделировании в Business Studio используются абстрактные задачи, то есть обычные задачи (операции) выполняемые исполнителем в процессе.

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