Про Vision понятно - это документ, в частности для сбора бизнес требований.

А как быть с БП "as is" и "to be"? Какие документы/шаблоны можно использовать для описания БП. Я в своем решении предложил использовать некий не формальный документ чем-то похожий на спецификацию ВИ + всякие цели, задачи, бизнес/риски и т.д.

Как Вы решаете/решали_бы проблему оформления БП "as is" и "to be"?

Если сразу и as is и to be, то это, скорее всего предложение по реинжинирингу. Цель предложения - убедить лиц, принимающих решение, в целесообразности принятия предложения. Значит, надо заострить внимание читающих на сути предлагаемых изменений и показать их целесообразность, используя описание БП, как иллюстрации, подтверждения и обоснование выкладок.
Как можно видеть, я за то, чтобы не ставить описание БП на пъедестал - это иллюстрация к предложению, основа принятия решений.
Другое дело, если описание БП - это регламент работы, тогда его и надо писать, как регламент: предельно четко и однозначно.

Да, цель - именно реинжиниринг БП. Причем хотелось описывать БП в виде use-case сценариев, т.е. не хотелось лезть в IDEF и ARIS.

Видимо, в документе описания БП "as is" должны быть следующие разделы:
1. Цель
2. Общие БПравила и Ограничения
3. БПроц. в виде use-case сценариев
4. Проблемы
5. Бизнес риски

Видимо, в документе описания БП "to be" должны быть следующие разделы:
1. Цель
2. Общие БПравила и Ограничения
3. БПроц. в виде use-case сценариев
4. Решенные Проблемы
5. Минимизированные Бизнес риски

Что-то я не видел похожего документа. Меня интересует именно СТАНДАРТНЫЙ (уже придуманный) шаблон для данного описания.
Возможно что-то есть в ARIS и его можно адаптировать, но не хотелось перелопачивать весь ARIS, т.к. я его плохо знаю. Если кто-то может что-то посоветовать из ARIS, то можно именно ссылку на шаблоны.

Не буду комментировать.
Просто посмотри вотэти шаблоны от IDEF0/Doctor

Еще не понимаю слово риски - это не то же что и проблемы? (то есть проблема может заключаться в том, что риск велик)

Да возможно риски и проблемы - это одно и тоже. В своем шаблоне я назвал проблемы - рисками.

1. Постановка проблемы
1.1 проблемы+возможные решения, отражающие суть изменений (шаблон vision)
1.2 Условия и ограничения (шаблон vision)
2. Более подробное описание изменений со ссылками в сценари.
3. Описание БП (соответствует разделам vision, которые описывают окружение заинтересованных лиц (среда пользователя) и бизнес-контекст) может быть вынесено в приложение, так как сценарии будут читать только технологи и инженеры, но никак не руководство.
3.1 БП Было
3.1.1 Введение. Включает в себя UC и контекстные диаграммы, как средство ориентирования в сценариях  и пару слов, помогающие читателям ориентироваться в сценариях
3.1.2 сценарии
3.2 БП Стало (та же структура, что и в 3.1)

А разве проблемы видны до описания "БП Было"? Или ты прост их хотел вынести для руководства?? Для руководства возможно еще нужно краткое описание было и стало, чтобы проблемы поднять.

На мой взгляд еще не хватает оценки необходимых ресурсов (затрат), сроков и рисков для полноценного предложения по запуску проекта реинжиниринга.

Ну для "БП Стало" можно использовать шаблон vision как таковой. А вот для было?

описание БП - это не только "несколько килограммов приложений к основному документу", но и основание для понимания проблем.

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

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

Ну хорошо, ты вникнишь в суть, а что будет через месяц или если другой БА будет заниматься реинжинирингом? То что ты обследовал канет в лета? Как ты свой труд оформишь-то?? Для другого БА или для себя? Да и про заказчика не надо забывать, т.к. он тоже не во всех нюансах может разбираться и скажет те что проблем у меня нет, а на самом деле куча проблем у него, а он об этом даже не знает.
Что-то мы не о том.
ДАЙТЕ ШАБЛОН!

Если ОБП в IDEF, то там вообще предельно четкие рекомендации по оформлению документов...

А нельзя их посмотреть? Честное слово ни разу не видел. Хотя какой я БА - так баловник одно слово