Уточните пожалуйста вопрос.

It looks pretty similar but here is the difference:
- in my diagram the selection logic is embedded into the first task of collecting process
- in EPN diagram it is located in event aggregation

This logic isn’t trivial - I had cases where it was actually a human task: some incoming orders are accepted while others remain in the queue by some semi-formal reasons. If this is the case then your alternative #4 won’t work.

Смотрите: если явного буфера нет, то у вас во входящих накапливается гора заданий. Предположим, по нормативу вы должны управляться с заданием за 30 минут. Но вы зашиваетесь, задания ждут своей очереди по три дня - получается, вы кругом виноваты. А сделать ничего не можете. Стрессы, разборки..

Теперь рассмотрим схему с явным буфером и планированием. Теперь вы отвечаете за выполнение плана, и это зависит от вас. Да, очередь ожидания никуда не делась к сожалению, но по крайней мере она явно видна. Менеджер по продажам может честно предупредить клиента: готов поставить ваш заказ на следующий четверг, будете ждать? Можно предложить клиентам несколько уровней сервиса: стандартный или ускоренный, с доплатой. Или наоборот: стандартный и льготный со скидкой по цене, но с более длительным сроком исполнения.

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

Thanks,
AS

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

>> какой из токенов должен продолжить свой путь по приходу сообщения о доставке.

Вообще всегда, когда один процесс шлет BPMN-сообщение в середину другого процесса (в message receive task или event), он (отправитель) должен идентифицировать конкретный экземпляр процесса (токен). Делаться это может по-разному: в простейшей реализации BPMS тупо требует указать атрибут, через которой процесс-отправитель должен отдать id процесса-получателя, в более сложной может быть что-то типа publish/subscribe, т.е. связь может осуществляться не через id процесса. Вся эта механика называется correlation. (Если сообщение шлется в start event, то корреляция не нужна.)

Предвижу вопрос: откуда процесс-отправитель узнает id получателя? Самый простой способ - процесс “Клиентский заказ” вместе с информацией о заказе запишет в базу данных собственный id.

>> Если смоделировать процесс так как показано на рисунке 4, то у дизайнера в BPMS системе сама по себе организуется очередь из задач.

Вы правы, буфер образуется и в этом случае, но это будет неуправляемый буфер:
- Клиентский отдел не будет видеть плана для уже принятых заказов и соответственно не сможет назвать клиенту обоснованный срок исполнения его заказа.
- Дизайн не будет иметь возможность обозреть объем работы на завтра и как-то его оптимизировать. (Хотя может быть, дизайн в этом смысле не самый удачный пример - потери на старты и переналадки тут не столь очевидны.)
- При этом дизайн все время будет виноватым: он будет срывать свои сроки, так как задачи будут ждать своей очереди непредсказуемое время.

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

>> Еще вопрос: каким образом реализуется буфер? Движок BPM управляет заявками, а буфер организуется, например, в ERP системе?

Варианты могут быть разные:
1) Обычно для этого создается таблица в базе данных.
2) Можно воспользоваться ERP, но тогда вам как-то надо будет или найти место для хранения идентификатора экземпляра процесса клиентского заказа, или искать процесс клиентского заказа по пользовательскому ключу, который есть в ERP - например по номеру заказа.
3) В случае BizAgi BPMS все просто: в этой системе каждому экземпляру процессов автоматически ставится в соответствие запись в таблице БД, выделенной под данный процесс. Поэтому процессу “Клиентский заказ” ничего никуда специально записывать не придется - планирование дизайна просканирует эту таблицу, чтобы найти ожидающие клиентские заказы.