Вот тут у меня появилась вопрос о границах наилучшей применимости (или не применимости) IDEF ( or ARIS) и  Use Cases при описании БП внутри организации.
Скорее даже интерсуют границы применимости ВИ, но решил расширить тему до IDEF ( or ARIS) vs Use Cases.

Если брать ВИ, то наилучшее их применение - это описание БП с точки зрения организации снаружи, с точки зрения RUP. Если же взять Кокберна, то можно спуститься и ниже - внутр организации. Но как это будет работать на больших проектах, на проектах по документообороту. Все ли БП будут охвачены, все ляжет в ВИ и Бизнес Правила (и много ли их будет).

Если же взять IDEF 0 и 3 (про ARIS плохо знаю, но рискну его сюда засунуть), то это как раз их стихия описания больших сложных БП именно внутри организации, особенно хороши они будут для документооборота и всяких учетных систем.

Что кто скажет?

"Самая короткая дорога та, которую знаешь" (с) ... На самом деле я бы не стал позиционировать юзкейсы какаппарат для описания бизнес-процессов как таковых. А позиционировал бы по-другому -- "можно ли при помощи юзкейсов описать документороот предприятия?" -- ответ -- "да можно" :-). А если ставить вопрос, а можно ли описать вообще бизнес-процессы, то и ответ будет тоже "можно". Другой вопрос для каких целей мы описываем эти самые бизнес-процессы, и какие аспекты БП хотим отразить в описании ...

Вот тут у меня появилась вопрос о границах наилучшей применимости (или не применимости) IDEF ( or ARIS) и  Use Cases при описании БП внутри организации.
Скорее даже интерсуют границы применимости ВИ, но решил расширить тему до IDEF ( or ARIS) vs Use Cases.

Если брать ВИ, то наилучшее их применение - это описание БП с точки зрения организации снаружи, с точки зрения RUP. Если же взять Кокберна, то можно спуститься и ниже - внутр организации. Но как это будет работать на больших проектах, на проектах по документообороту. Все ли БП будут охвачены, все ляжет в ВИ и Бизнес Правила (и много ли их будет).

Если же взять IDEF 0 и 3 (про ARIS плохо знаю, но рискну его сюда засунуть), то это как раз их стихия описания больших сложных БП именно внутри организации, особенно хороши они будут для документооборота и всяких учетных систем.

Что кто скажет?

Речь идет о диаграммах ВИ или о текстовом описании по Коберну?
Если речь о текстовом описании ВИ, то предлагается сравнить их с текстовми документами, генеримыми из под BPwin в результате работы с IDEF?

На самом деле я бы не стал позиционировать юзкейсы какаппарат для описания бизнес-процессов как таковых.

А что бы ты позиционировал как "аппарат для описания бизнес-процессов"?

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

Да цель забыл - риинжениринг/оптимизация БП. Т.е. надо сначала получить наиболее полную картину именно ВНУТРЕННИХ БП БОЛЬШОЙ ОРГАНИЗАЦИИ, понять что где не так и нарисовать/написать как надо. Скорее всего надо представлять все в виде диаграмм, чтобы получить наиболее полную и понятную картину и не забыть ничего.

Речь идет о диаграммах ВИ или о текстовом описании по Коберну?
Если речь о текстовом описании ВИ, то предлагается сравнить их с текстовми документами, генеримыми из под BPwin в результате работы с IDEF?

Сценарии нужны по-любому, но тут не суть важно как мы будет писать сценарии ВИ - либо текстом либо в виде ДП или ДД. Не важно с чем конкретно мы будем сравнивать (с диаграммами IDEF или "текстовыми документами"), важно понять и выявить лучший инструмент/технологию для описания внутренних БП, особенно интересует область применения документооборот или бухгалтерия.
Попутно можно описать области лучшего применения/не_применения IDEF и Use Cases.

Если речь идет об оптимизации, то мы как минимум должны говорить о критериях эффективности БП ... это могут быть определенные бизнесовые KPI например. В этом случае, чтобы доказать, что процесс более оптимален -- придется делать его имитационную модель, с тем, чтобы те самые KPI посчитать. А это уже иной уровень, одного описания (сценариев) будет не достаточно, нужны срдества динамического моделирования.
Говоря об аппарате описания БП, то это все-таки классика -- а именно IDEF, который по сути для этого и был создан. Хотя я бы сказал что должен быть документ-спецификация процессов, и как приложение -- диаграммы. В документе как раз и можно отразить те самые KPI и их значения которые будут приемлемы. И еще один момент -- инжиниринг бизнес-процессов -- это тема не совсем ИТ-шная я бы сказал, хотябы потому, что ИТ там выступает как интсрумент ... вместо компьютера вполне могут быть 1000 китайцев :-), которые будут например бегать с бумажками. Другой вопрос -- если "бизнес = ИТ", как то информационные порталы, инет-магазины, услуги по коммуникациям (та же e-mail) и т.п. ... тут составляющая ИТ в бизнесе очень высока, даже я бы сказал критическая. Но KPI процессов все равно бизнесовые будут :-).

Добавлю свой камень в Ваш сад камней.

Сначала свои впечатления от IDEF и SADT(DFD) про него тоже не стоит забывать.

IDEF простота и жесткость описания - и преимущество, и недостаток. Это как разница между Паскаль и Басиком.
С другой стороны IDEF явно определяет - что есть управление, что есть вход(который перобразуется в выход), с помощью чего и кого мы это делаем, т.е. можно указать исполнителей. Но точка зрения одна. на каждую точку зрения нужно делать отдельные описания-диаграммы, иначе получится каша и заблудишься.
IDEF0 хорошо декомпозируется в IDEF3 а последний можно сипользовать для создания имитационных моделей в Arena или BPSimulator.
В IDEF0 ясно и четко видны все сязи, прямые обратные, критические функциональные предшедствования и т.п. Что очень сложно отобразить в виде ВИ.
Далее в IDEF0 есть такой стоимостной анализ ABC, который можно использовать при принятии решения о структуре процесса.
К примеру процесс тестирования мониторов может включать: внешний регламент, тестирование по контрольным точкам, тестирование на стенде. Например каждая операция имеет норму брака (степень определения неисправностей) и естественно стоимость работы. Т.е. мы можем подобрать такую структуру следования этих подпроцессов чтобы минимизировать общие затраты на проведения тестирования задав например нагрузку в 1000 мониторов....

Далее для описания документооборота можно посмотреть в сторону DFD. Процессы центры обработки документов, хранилища - центры накопления документов, потоки - собственно циркуляция документов...

Кроме того если использовать UML, то может имет смысл начинать с диаграмм деятельностей - которые во многом похожи на IDEF3 диаграммы + диаграммы состояний.

В принципе все это в комплексе существует в Telelogic System Architect - и инжиниринг и реинжиниринг и имтационное моделирование во встроенном симуляторе. Вопрос цены конечно

Подвиду итог, в общем, IDEF рулит в этой ситуации, как я и предполагал.