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

Что касается разработки ПО, то здесь событийный подход давно стал общепринятым. Основной принцип event-driven архитектуры — это разделение системы на независимые компоненты, которые общаются между собой через события.

Аналогично и с бизнес-процессами. Аналитики привыкли рисовать процесс как цепочку действий, следующих одно за другим. Такие модели легче воспринимать и обсуждать с бизнесом, но реальный мир так не работает. Возьмем, например, процесс обработки заказа. В первом приближении его можно представить как линейный. Но мы же понимаем, что клиент может отказаться от заказа в любой момент, да? То есть, происходит событие, которое не вписывается в линейную логику и его надо как-то обрабатывать. И как быть? Нагромождение проверок после каждого шага процесса быстро делает диаграмму запутанной и нечитаемой.

К счастью, люди, которые разрабатывали BPMN, об этом подумали и заложили в нотацию такие возможности. Однако далеко не все аналитики и разработчики умеют этим пользоваться. И эта одна из причин, почему BPMN диаграммы лишь украшают стены кабинетов, но не превращаются в автоматизированные процессы.

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