Как проверить, насколько корректно выбраны уровни абстракции и детализации на схеме бизнес-процесса - не слишком ли мы закопались?

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

По сути, это про отсечение частных дифференцирующих признаков нескольких объектов (например, работ/шагов в процессе) и поиск общих интегрирующих свойств, которые позволят обобщить разные на текущем уровне описания вещи (их смыслы) в одну абстракцию (общий смысл) более высокого уровня (см., например, аксиома выбора Цермело). Грубо говоря, не просто отделить мух от котлет - а не путать конкретных мух с остальными насекомыми и котлеты с ужином вообще.

Если у вас уже есть какая-то диаграмма процесса, предлагаю начать верификацию так:

• смотрим на блок с работой (шаг процесса/алгоритма), выписываем в блокнот (сеньорам - мысленно) его базовые свойства (входы/выходы, инструменты/управление в парадигме IDEF, либо иные онтологические признаки);
• смотрим на соседние блоки работ по цепи управления, определяем так же их свойства;
• оцениваем, насколько свойства всех рассмотренных блоков схожи по уровню абстракции/обобщения (см., например, теории категоризации Рош и Мёрфи) - если общего больше, чем явных различий, модель корректна по критерию единообразия обобщения.

Затем нужно проверить, насколько выбранная степень детализации (текущий уровень обобщения в блоках процесса) соответствует цели моделирования. Иными словами, понять, что важнее - увидеть сценарий во всех возможных нюансах или показать результаты. Как только второй фактор начнет превалировать по большинству блоков над первым, декомпозицию следует остановить. Обращаю внимание - такой подход к верификации можно использовать не только для готовых моделей, но и прямо по ходу моделирования, применяя методику последовательно, продвигаясь по цепи управления.