Чек-лист моделей (схем) BPMN аналитического уровня

Указать:

обозначение действий в верном формате (инфинитив глагола. К примеру, “создать”, а не “создаёт”)
названия событий в верном формате (событие, которое с объектом произошло) Форма деепричастного оборота
все хранилища данных рабочего потока
все документы рабочего потока
метрики всех задач рабочего потока
все названия функций, отделов, ролей
кодировку процесса
начальные и завершающие события (Закрасить их в зелёный и красный цвет)
сообщения там, где они есть
верно указать связь пулов (message flow)
все экземпляры процесса (полноту определяют цели моделирования)
подпроцессы обработчики
смены статусов простой иконкой промежуточного события
завершающее события всех прикрепленных-граничных событий
все события, которые есть
ценность для клиента процесса
пути по умолчанию (default flow) при использовании определённых типов шлюзов
номера действий рядом с обозначением действий (1.0; 1.1; 1.2.; и т.п.; 2.0; 2.1.; 2.2; и т.п.)

На модели (схеме) не должно быть:

брошенных блоков задач
кривых стрелок
большого количества используемых стрелок, входящих в блоки задач (надо использовать операторы-шлюзы)

Проверить:

верное использование пулов?
процессы строго слева направо?
каждой ветке свой конец?
используете множественное выполнение там, где это надо?
не ставим отдельные задачи для приёма и принятия информации?
комментарии не мешают?
не путаете знак бизнес-правила с таблицей?
уровни выполнения задач на схеме не перемешаны?
потоки не перепутаны?
мы не решаем за клиента (внутреннего\внешнего) в пуле его судьбу?
использование событий “ссылка” оправдано?
используем событие “условий” (conditional) только тогда, когда нет другого выбора?
есть события начало и конца?
у элементов однотипный размер?
основная ось процесса - поток по умолчанию?

Допустимо:

красить пулы в цвета (1 цвет на 1 пул)
не использовать пулы
в каких-то нюансах отступать от нотации под потребности заказчика. Но необходимо фиксировать отступление от нотации в технической документации.