Правила хорошего тона
Правила хорошего тона при моделировании в нотации BPMN
Автор: Олег Борознов, 14.01.2018
-
Избегайте пересечения потоков операций на диаграммах
Чем проще и нагляднее смоделирована диаграмма, тем более она понятна пользователям. Старайтесь избегать пересечения потоков операций на диаграммах: это упростит понимание моделей бизнес-процессов, как опытными, так и начинающими аналитиками BPMN.
Иногда нет возможности исключить пересекающиеся потоки, но всегда имеет смысл выделить дополнительное время на оптимизацию компоновки элементов диаграммы, чтобы она была еще более понятна пользователям и комфортна для восприятия.
Хороший пример моделирования потоков
Плохой пример моделирования потоков
-
Наименование элементов в BPMN
Каждый элемент BPMN имеет свое обозначение и наименование. Событие необходимо именовать по формуле «существительное + глагол в прошедшем времени». Например, «сделка состоялась». Процесс (пул) должен содержать имя процесса или субъекта, который его выполняет. Например, «Корпоративный портал» или «Инициатор договора» или «Управление доставкой». Задачи желательно именовать по формуле «отглагольное существительное + наименование объекта, над которым совершается действие». Например, «Подготовка отчета» или «Отгрузка товара» или «Подписание договора». Эксклюзивные шлюзы нужно обозначать вопросами, а потоки операций от них – ответами (условиями).
Ниже приведены примеры, иллюстрирующие наименование элементов диаграммы.
Хороший пример наименования элементов на диаграмме
Формулы наименований элементов
Плохой пример наименования элементов на диаграмме
-
Симметричное моделирование
Симметричное моделирование позволяет пользователям диаграмм лучше понять логику процесса. Этот совет проиллюстрирован на двух примерах ниже.
Пример 1: Приготовление ужина
Симметричное моделирование
Несимметричное моделирование
Пример 2: Выполнение заказа
Симметричное моделирование
Несимметричное моделирование
-
Используйте задачи одинакового размера
Мы рекомендуем всегда изображать задачи одинакового размера. Причина в том, что пользователи склонны интерпретировать размеры задач и считать, что более крупные задачи важнее маленьких, или они длятся дольше. Кроме того, большие задачи притягивают внимание, следовательно, маленькие задачи могут быть ошибочно пропущены при чтении процесса. В действительности размер задачи в BPMN не имеет значения. Ниже приведены примеры, иллюстрирующие этот совет.
Диаграмма с одинаковыми размерами задач
Диаграмма с разными размерами задач
Хотите быстро освоить BPMN?
Пройдите обучение в нашем учебном центре! |