В издательстве Альпина Паблишер готовится к публикации русский перевод книги Брюса Сильвера «BPMN Method & Style». Брюс – признанный авторитет в мире BPMN, и выход его книги на русском должен способствовать культивации «хорошего» BPMN. Пользуясь случаем, хочу поблагодарить издательство, компанию ELMA и лично Алексея Будина, проспонсировавшего покупку авторских прав, а также переводчика Андрея Матусевича. Моя роль в этом проекте – организатора и научного редактора.
Хотя я считаю Брюса своим учителем, с некоторыми рекомендациями его Метода я не могу согласиться.
В частности, Брюс рекомендует везде, где можно, экономить на развилках:
- использовать неявное распараллеливание -
- делать схождение альтернативных потоков на задаче -
- делать схождение параллельных потоков на завершающем событии -
Против этих рекомендаций у меня есть как конкретные, так и общие возражения:
- Первая схема не является интуитивно-понятной – с большой вероятностью неискушенный читатель решит, что на ней изображен сценарий выбора, а не распараллеливания. Интуитивная (без обучения и без пояснений) понятность – важное преимущество BPMN, и жертвовать им я лично не готов.
- Третья схема собьет с толку BPMS – в аудиторском журнале и в итоговом отчете по процессу будет зафиксировано два экземпляра конечного события вместо одного.
Общее же возражение заключается в том, что стремление сэкономить на развилках является контрпродуктивным.
Да, на первый взгляд чем меньше элементов на диаграмме, тем она понятнее. Но развилки не являются лишними элементами. Даже если, как в приведенных выше примерах, поведение схемы, из которой удалены развилки, останется тем же, для восприятия она станет сложнее. Стандартный блок со сходящейся и расходящейся развилкой -
- человек считывает не задумываясь, «на автомате». Если убрать развилки – придется вглядываться и задумываться.
Понятно, что для простых фрагментов процесса, приведенных выше, это не имеет большого значения. Но вот более реалистичная схема, которую приводит Брюс в своей книге (я лишь заменил реальные названия на условные):
Я бы изобразил этот процесс так:
Схема стала больше? Да. Количество элементов увеличилось? Да. Но вся она собрана из стандартных блоков, либо следующих один за другим, либо вложенных один в другой.
Какая схема лучше? Вероятно, это дело вкуса. Как пишет Брюс, «вы можете соглашаться с моим Методом или нет – главное, чтобы вы выработали свой метод и последовательно его придерживались». С этим нельзя не согласиться!
Я бы провел здесь параллель со структурным программированием, идея которого – разбить программный код на стандартные блоки: последовательность, выбор, цикл. В свое время структурное программирование произвело революцию в разработке программного обеспечения. Сегодня про него мало кто вспоминает, но не потому, что оно стало неактуальным – ровно наоборот, оно настолько прочно вошло в практику программирования, что его перестали замечать.
В моделировании процессов, по моему мнению, также следует придерживаться структурного подхода, что, в частности, означает – не экономить на развилках.
Чтобы освоить структурное моделирование в нотации BPMN и в теории, и на практике, приходите на мой тренинг – очередной курс пройдет 7, 8 и 10 октября.
