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

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

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

Некоторые считают такую ситуацию допустимой, мол, исполнитель сам решит, какую операцию делать первой. Но это некорректно. Как быть в такой ситуации? Вместо параллельного делать последовательное исполнение операций.

Физическая нереализуемость – это ситуация, когда один исполнитель должен согласно схеме процесса одновременно выполнять два разных действия – см. рис. 43.

Документы «повисли» в воздухе – несоответствие – нужно показать откуда приходят, и куда попадают документы (другие процессы, базы данных).

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

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

Запустить этот процесс как сервис из других процессов будет нельзя. В каком-то другом процессе придется описывать согласование договора повторно и т. п. Это неудобно.

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

В этом случае нужно будет воспользоваться промежуточными событиями отправки и получения сообщений. Фактически, мы будем из нашего процесса инициировать (запускать) другой процесс как сервис. После его выполнения, мы получим нужные нам результаты и продолжим выполнение нашего процесса.