А иногда надо самому пахать и описывать эти процессы, чтобы подать пример.

Описывать процессы нужно обязательно. Именно обязательно.

Больше того, антикризисные мероприятия, редизайн, немыслимы без понимания бизнес-процессов.

Сам процесс описания важен для осмысления автором. Артефакты (описания) для совместного обсуждения, дискуссии, инсайтов.

И 50% компаний такие: "ой всё..." *сарказм*

Все знают, что надо. Но считают, что это затратно и не важно для текущих целей бизнеса.

Нужны цифры, как я понял

Да, оценил)

А зачем? Пусть не описывают. Это наши будущие клиенты

Коллеги вы опять путаете процесс и результат. Отрисовка, bpmn и все такое -это лишь метафизика, один из  приемов структурирования. И _можно_ проводить рефакторинг бизнес процессов без их зарисовки. Тейлор прекрасно помогал Форду делать конвееры без bpmn. В военном деле есть разные схемы (включая краткий курс лмдерства в виде Петьки и Чапая с Картошкой впереди на лихом коне). Есть OKR, MBO, Balance score card.. SAFe в конце концов.. В медицине есть guidelines, там и в голову не придет рисовать as is и to be для регламента . Простое лечение апендицита это около 600 (!) операций и условных шагов..

Гюльчатай! Открой личико!

Я рассматриваю бизнес процесс по сути как path , связывающий входы (ресурсы) с выходами. Просто чуть более оптимизированный, например при помощи оптимизационной функции типа "задача комивояжера".  Очень похоже на задачи трассировки электрических плат или микросхем. Видкл как в 80е в КБ это делали руками на кальке, но по мере роста сложности и числа компонент, а также к скорости, это уже делают автоматически.  Как хранит этот граф всякие pcad/orcad и можно ли его визуализировать, уже неважно, главное чтобы в итоге правильные команды на сверлильный станок или там фотолитографию, пайку и прозвонку пошли...

А почему BPMN? Математический аппарат моделирования динамических дискретных систем - сети Петри. BPMN придумали для того, чтоб ... Впрочем, я не знаю зачем его придумали. Может для денег, а может из каких-то бескорыстных, но от этого не более умных соображений. А может, модель процесса в BPMN это что-то из современного искусства. Чем не симулякр, например. Процессов нет, а модель есть

Верно, и сети Петри являются ориентированным мультиграфом. так как он допускает существование кратных дуг от одной вершины графа к другой, что в общем в bpmn не приветствуется. Как тогда объяснить заказчику что ты, самый умный консультант, долго думал и придумал 'самый крутой бизнес процесс' если по факту таких бизнес процессов и вариантов исполнения может быть бесчисленное множество. Пичалька для бюрократов и контролёров - непонятно как кнут/пряник применять..

Есть ещё 'нагуглить' или как по модному найти паттерн. Не вдаваясь в физику, по симптоматике подыскать похожий кейс. Если забанили в интернете, то можно поискать в knowledge base компании или отрасли. Можно устроить краудсорсинг чтобы поискать ответ коллективно. И даже интуитивный и прочие трансцедентальные методы - можно вызвать дух Сталина (или Шеннона - кому что ближе) и погадать на хрустальном шаре.. Вы слишком преувеличиваете рациональность совета директоров в принятии решений. Если было так, Канеману и пр. нобелевки бы не вручали. Впрочем модные консалтеры к счастью это знают, и мастерски умеют работать и без логики, удивляя заказчика своей шляпой фокусник и выпрыгивающим из неё кроликом, лягушкой или пентаграммой из bpmn рун..

В целом, процессы можно и текстом описать. Т.к. bpmn - это просто инструмент визуализации.
В конкретном случае был вопрос про внедрение enterprise архитектуры + bpmn.

Очень часто вижу, что в таких случаях "буксуют" именно в сложности схем и bpmn становится не полезным инструментом, который экономит время за счёт визуализации и отсутствия необходимости текстового описания, а наоборот, перегруженной детализированной схемы, часто гибридного характера, не отражающей суть процесса, а больше говорящая про детали этого процесса.

И тут аналитики начинают показывать как они могут выписывать пируэты в bpmn. 👺
Опытный же аналитик будет использовать минимализм, понимая, кому и зачем нужна эта схема, а также её ценность относительно затраченного времени на  создание.

Нужно ввести правило, если его ещё нет:
"инструмент не должен становиться проблемой, а помогать решению проблем"

Вот тут есть нюанс

Степень детализации во многом зависит от контекста/проекта. То есть конкретных потребителей, их навыков и предпочтений

И редко можно сразу угадать как с инструментами (нотациями), так и с детализацией

Мне нравится мысль (на собственном опыте) что эти моменты нужно тюнить на первых итерациях проекта

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

Ну как. Это проблема, только если проблема. То есть когда у кого-то задница горит/загорелась