Статья подготовлена для студентов курса «Аналитик бизнес-процессов» в образовательном проекте OTUS.
Как известно бизнес-аналитикам, реальное исполнение бизнес-процессов в компании штука сложная, ведь процессы взаимодействуют между собой. Для описания таких взаимодействий в BPMN 2.0 часто применяются сообщения. Типичное описание такого взаимодействия выглядит так: «Процесс 1» шлёт сообщение «Процессу 2», при этом «Процесс 2» не пойдёт дальше «Задачи 23», пока не получит сообщение. Но что будет, если «Процесс 1» отправит сообщение раньше, чем «Процесс 2» будет готов его получить? Например, будет находиться на этапе выполнения «Задачи 22».
Нотация BPMN 2.0 прямого ответа на этот вопрос не даёт, оставляя его решение на откуп разработчикам процессных движков. А у разработчиков вариантов немного: хранить сообщение или не хранить.
Если хранить, то последовательность выполнения задач во взаимодействующих процессах неважна — сообщение из «Процесса 1» дождётся «своего часа» в «Процессе 2». А если не хранить, то сообщение, пришедшее раньше, просто потеряется и экземпляр «Процесса 2» навсегда зависнет на «Задаче 23».
Но если вы разрабатываете описательный бизнес-процесс, который не предполагается «скармливать» процессному движку, а предполагается обсудить с исполнителями и изготовить на его основании регламент, то первый вариант сгодится лучше.
Во-первых, он более читаем, а во-вторых (и это главное отличие людей от компьютеров) — любой вменяемый человек обязательно проверит, не пришло ли сообщение раньше: получено ли письмо, пришла ли машина, поступал ли товар и т. п. Ему даже в голову не придёт остановить процесс, просто потому что письмо, на которое он должен ответить, пришло раньше, чем он закончил читать предыдущее.
Всем адекватных исполнителей бизнес-процессов и не забывайте оставлять комментарии!
Материал подготовлен для студентов курса «Аналитик бизнес-процессов» в образовательном проекте OTUS. Чтобы присоединиться к ближайшей группе, обязательно пройдите вступительное тестирование:
ПРОЙТИ ТЕСТИРОВАНИЕ