Данный паттерн не столь универсален, как, например, «Внутренний заказ», но все же встречается достаточно часто: если не на каждой практике по BPMN, то через одну - точно.
Примеры:
- Закупка по конкурсу
- Прием на работу по конкурсу
Упрощенная схема иллюстрирует идею паттерна:
Полная схема:
Пояснения к схеме:
- Процесс «Конкурс» размещает объявление о конкурсе, записывает информацию о конкурсе в базе данных конкурсов, с которой в дальнейшем будет сверяться процесс «Конкурсная заявка», и впадает в спячку до окончания срока подачи заявлений на конкурс. После этого конкурс в базе данных помечается как закрытый.
- Каждая заявка, пришедшая на конкурс, инициирует запуск экземпляра процесса «Конкурсная заявка». В общем случае мы можем проводить несколько конкурсов одновременно, поэтому данный процесс начинается с определения того, на какой собственно конкурс представлена заявка. В случае закупки по конкурсу это просто, но в случае приема на работу, где роль конкурсной заявки играет резюме, это задача нетривиальная, потому что люди зачастую рассылают резюме «веером», особенно не заботясь, есть ли в компании для них подходящая вакансия (которая в данном случае играет роль конкурса), или нет.
- Если конкурс, к которому относится заявка, успешно идентифицирован, и заявка прошла первичную квалификацию (в случае приема на работу – человек прошел сквозь сито собеседований), то заявка записывается а базу данных кандидатов, и процесс заявки переходит к ожиданию одного из двух сообщений: либо данная заявка победила в конкурсе, либо конкурс завершился и данная заявка в нем не победила.
- Сообщение о том, что заявка победила, процесс «Конкурс» отправляет по результатам определения лучшей из представленных заявок. В процессе «Конкурсная заявка» возможны два варианта: если все идет штатно, мы заключаем соглашение с победителем, в процесс «Конкурс» шлется соответствующее сообщение, и он, в свою очередь, информирует остальных участников конкурса о том, что их заявка не стала победителем. На этом процесс «Конкурс» успешно завершается.
- Если же соглашение по какой-то причине заключить не удается, то процесс «Конкурс» вновь определяет победителя из оставшихся заявок. Если заявок больше не осталось (или не было изначально), то конкурс заканчивается неудачей.
- Предполагается, что интервал времени между датами окончания приема заявок и подведения итогов достаточен, чтобы оценить заявку, которая поступила «за пять минут» до окончания срока. Если мы успели оценить все поступившие заявки до даты подведения итогов, то можно приступать к определению победителя, не дожидаясь этой даты. В случае приема на работу это имеет смысл, а в случае закупки по конкурсу, пожалуй, нет, так как в этом сценарии дата окончания конкурса объявлена, известна всем потенциальным участникам, и они, как правило, тянут до последнего. При желании и такую логику можно смоделировать, но схему процесса она усложнит значительно.
Пара замечаний общего характера:
- Обычно повторяющиеся действия в BPMN моделируются либо с помощью цикла (простого или по объектам), либо с помощью развилки «или-или». Здесь же повторяющие действия (обработка заявок на конкурс) моделируются отдельным пулом – каждой заявке соответствует свой экземпляр бизнес-процесса.
- В паттерне «Планирование ресурса» мы имеем дело с несколькими заказами, для которых есть один исполнитель. Здесь ситуация обратная: несколько потенциальных исполнителей на одну роль.
Анатолий, как Вы советовали бы Выходить из ситуации когда кандидат может в любое время отозвать свою заявку или тендер тоже в любое время может быть отменен. Что делать с оставшимися экземплярами процессов? Как корректно показать на диаграмме событие “отмены” которое может появиться в любое время?
Стандартным образом: погружаем последовательность задач в подпроцесс и прикрепляем к нему пограничное событие - получение сообщения “Отмена”.