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