Сообщения в BPMN могут использоваться двояко:

1) Как средство межпроцессного взаимодействия. В этом случае за пунктирной стрелочкой в исполняемой среде стоит вполне конкретный механизм типа message queue, обеспечивающий доставку сообщения из одной указанной точки в другую.

2) Как средство документирования взаимодействий с внешним миром, который моделируется пулами-внешними сущностями, иначе называемыми black box. В этом случае за пунктирной стрелочкой никакой исполняемой семантики не стоит, фактически она играет роль комментария к схеме.

Кто-то рисует исполняемые диаграммы BPMN, кто-то аналитические… это нормально. Внешняя сущность есть элемент аналитической диаграммы, но диаграмму на рис.3 легко превратить в исполняемую - достаточно выкинуть пул “Клиент” и сообщения, идущие в/из него, и заменить message start на none start. А вот диаграмму на рис.2 так легко в исполняемую не превратить.

Стартовое событие в основном процессе - поступление сообщения (message) от клиента.Поясните пожалуйста, как Клиент посылает это сообщение из “внешней сущности”? Если процесса Клиент нет, то послать сообщение некому. Значит ваша модель работать не будет - не чем стартовать основной процесс.

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

Спасибо за цитату из Канта. Впечатлен.

По поводу пула “Клиент” - это ни в коем случае не процесс. Пул в BPMN изображает либо процесс, либо внешнюю сущность. В данном случае мы имеем дело со вторым вариантом.

По поводу Id процесса замечание совершенно верное: чтобы послать сообщение другому процессу, нужно знать его Id. Но для этого вовсе не обязательно эти два процесса должны быть связаны родственными отношениями.

Так, процессы, изображенные на рис.3, взаимодействуют через данные: основной процесс “Выдача банковской карты” записывает в БД карт к выдаче не только реквизиты карты (включая ФИО клиента), но и собственный Id! Это дает возможность вспомогательному процессу, в случае успешной идентификации записи в БД, относящейся к данному клиенту, извлечь Id из базы и успешно послать сообщение туда, куда следует.

Так что возвращаю мяч обратно - автор вовсе не увлечен аналитическим моделированием и в курсе реальных сложностей, а вот отдельные комментаторы похоже чересчур увлеклись философией

Владимир,
твое предложение
> 10. при обращении клиента проверить у него документы и найти карту в пачке карт (либо найти ее в списке аннулированных по срокам карт);
> 11. оформить документы на выдачу карты (и учесть в базе данных банка);
> 12. выдать карту клиенту.
если я правильно тебя поняла, касается не принципа взаимодействия процессов, а детализации процесса выдачи карты (его части). Не вижу проблемы - шаг, названный Анатолием “Найти карту” может быть не одним шагом, а несколькими, в том числе и п.10 может быть выполнен там же.
Пункты 11 и 12 могут быть выполнены только в случае успешного поиска, поэтому их выполнение относится к части “Выдать карту”, которая тоже может быть детализирована, и содержать даже большее количество действий.
Предлагаю абстрагироваться от деталей и оставить два действия “Найти” и “Выдать”.
Если ты считаешь принципиальным, чтобы эти действия были в одном процессе, то это вариант, который предлагает Aliya - вынести шаг “Выдать карту” в процесс “Обращение за выдачей”. Тогда, как предлагает Анатолий, ожидание ответа, что карта выдана, оставить в процессе “Выдача банковской карты”.
А вот разделить эти процессы - это уже принципиальный вопрос. Тут действительно другой процесс. Анатолий назвал его “Выдача банковской карты”, но на самом деле этот процесс имеет более глубокий смысл. Это, по сути, процесс, отслеживающий состояние карты. Карта заказана, изготавливается, выдана, а дальше будет следовать еще один автомат: закончилась, утеряна и т.д. Я бы и рассмотрение заявления вынесла в другой процесс, т.к. на жизненном пути карты может быть заявление о ее утере, обмене и т.д.

ОК. Не буду учить Вас на “лыжах кататься” (это про “менторский” тон).

Не скрою, что большие корпоративные информационные системы не разрабатывал и не внедрял.

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

По данному примеру у меня вопросов больше нет.

С уважением,
Владимир Репин

Вроде мы обсуждали логику процесса, а не цену софта?

>> Бизнесу нужны эффективность, а не мода.

Оставьте пожалуйста менторский тон.

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

Я большие корпоративные системы и разрабатывал, и внедрял. А Вы?

Показателей может быть много. Для их расчета и мониторинга внедрение BPMS - один из возможных вариантов, причем весьма недешевый.

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

Далее. На рабочем месте операционисту совершенно не обязательно “пролистывать 10 скринов, чтобы получить информацию по карте”. Это приложение может быть оптимизирован под типовые, часто повторяющиеся задачи. Один клик - меню проверки статуса и выдачи карты.