GERAM

А это отдельная подсистема. В модели GERAM две основные подсистемы. Типа производственная и обслуживающая. И они связаны весьма интересно, не иерархически. Смотрите тут (хотя текст не полный, но в приложениях почти все есть): https://www.iso.org/obp/ui/#iso:std:iso:15704:ed-1:v1:en

Корректнее говорить о «событии». Некое событие возникает и обрабатывается в системе. Оно может (!) порождать бумажки и проходить через людей. Может не порождать бумажки (1 метод оптимизации). Можно исключить людей (2 метод оптимизации). А можно исключить сам процесс, порождающий или требующий бумажку. Сделать его частью иного процесса. И бумажка — это самое простое.

Одно из решений: стандарт процесса описывает время реакции в 24 часа на событие (например). Если триггер (утвердить или нет) — то автоматическое утверждение, если нет замечаний в течении 24 часов. Успел, не успел — по-фигу. Жестоко, но работает прекрасно. Так у нас договор, кстати, построен. Это один из немногих пунктов договора с Заказчиком. Если решение в выборе вариантов, то тоже установлено время принятия решения. К 18:00 решение принимается и все. Если не выбран оптимальный вариант через лицо принимающее решения, то автоматически выбирается один из предложенных вариантов. Метод выбора: случайный выбор. И да, уже доказано, что при принятии сложных решений в ситуации неполной, неточно и несвоевременной информации случайный выбор из нескольких более-менее равнозначных вариантов не хуже, чем оптимальный с какой-то точки зрения.

Технически и организационно внедрить такие алгоритмы работы несложно. Не в виде идеи! Даже не пытайтесь рассказывать такие идеи Заказчику. А просто в виде регламента, как само собой разумеется. Важен уровень проработки и обоснования такого метода. Проработка во всех аспектах: и юридическом, и финансовом, и организационном.