Тема, подозреваю, не нова.
Есть немало форумов, посвященных моделированию БП (бизнес процессов).
Еще больше форумов, посвященных программированию.
И очень мало материалов, посвященных мостику между ними.
Я имею ввиду следующее: аналитик создает описание БП-а; архитектор придумывает, как это автоматизировать; программист реализует. В результате имеем работающую инфрмационную систему, поддерживающую и реализующую БП.
Любое изменение в БП влечет за собой работу программиста, ибо мостик между аналитиком и программистом, как правило, не автоматизирован.
Некоторые компании (не буду показывать пальцем) декларируют автоматизацию процесса анлиз-постановка-реализация, причем так, что незначительные изменения в БП не влекут за собой работы программистов в принципе: исправил даграмму, "откомпилировал" ее (ткнул в кнопочку "принять" , и БП "закрутился" уже по-новому.
Впрос: эта "идилия" действительно возможна или это лишь "маркетинговый ход"? И возможна ли эта идилия в принципе? Если да, то с помощью каких средств?

Я думаю, что эта идиллия пока невозможна. Хотя мы туда идем и когда-то придем. Как я понимаю можно сделать так - писать веб-сервисы (ВС), которые реализуют маленькую часть ф-ти, а потом с помощью BPMS моделировать и аркестрировать эти ВС. Но все равно код будет, хотя он и будет привязан к определённым частям БП, если использовать дорогущие инструменты от Оракла или ИБМ.
Что реально сделать, так это прописать хорошо Requirement Management Plan, в котором будет описан процесс трассировки от БП к коду и процесс изменения с верха вниз, а не наоборот или из середины.

Насколько я понимаю, идиллия возможна, но с весьма существенными ограничениями. И ограничения эти будет накладывать а) методология описания БП и б) ее (методологии) реализация в движке BPM системы.
Если ваши изменения в БП будут укладываться в возможности движка и, при этом, ваш БП будет непротиворечиво выполняться (сиречь не подвешивать движок) - you are welcome. Как только потребуется некий нестандартный функционал - придется делать ручками. К тому же вы в этом случае получите потенциальный (или реальный) roundtrip.

bas, хороший план управления требованиями - это немного не о том. Его наличие ну никак не спасет от, цитирую:

Любое изменение в БП влечет за собой работу программиста, ибо мостик между аналитиком и программистом, как правило, не автоматизирован.

Да ПУТ тут не поможет Я просто не внимательно прочитал. Но ПУТ - это действительно единственный путь к правильной организации процесса изменений.

...незначительные изменения в БП не влекут за собой работы программистов в принципе: исправил даграмму, "откомпилировал" ее (ткнул в кнопочку "принять" , и БП "закрутился" уже по-новому...

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

А следовательно наступит и описанная MasterShi идилия.

А когда все это наступит, и наступит ли вообще - пока сказать трудно.

Ну, вопрос о необходимости программистов не стоит.
Другое дело, что хочется и их разгрузить, и распухание КИС остановить. Желательно адекватными средствами. При этом не купить "кота в мешке". А то презентации выглядят заманчиво, а "потрогать" не удается - некотрые важные функции в демоверсиях отключены. Если к этому добавить коментарий

весьма существенными ограничениями

из одного из предвдущих постов, то вопрос перестает быть праздным. Как использовать нотацию, если "самое вкусное" в  ней обрезано?

Т.е. Вы говорите - зачем нужно моделировать??
А тогда встречный вопрос - а зачем нужно делать модель дома, если из нее нельзя сразу построить дом?

Мне кажется, что MasterShi хочет узнать существует ли ПО, которое помогло бы реализовать описанную идилию. И если существует - то название вендора.

А тогда встречный вопрос - а зачем нужно делать модель дома, если из нее нельзя сразу построить дом?

Тут есть большая разница - дом строится не по модели дома. Модель дома используется для определения некоторых его характеристик. Например теплоснабжения, освещения и т.п.
Дом же строится по чертежу. Чертеж - вещь строго формальная. К чертежу естественно прилагается технология.

Любое ПО делается по коду, код (как сказал Денис Иванов) и есть чертеж, по которому компилятор или интерпретатор формирует исполняемый код или байт-код.

В случае построения моделей процессов мы надеемся, что существует некоторый интерпретатор таких моделей, переводящий их в исполняемый код. Ясно, что в этом случае модель должна быть адекватно формализуема.

Пример визуального создание моделей и их дальнейшего исполнения - Simulink Matlab. Там мы реализуем модель процесса, используя визуальные элементы-блоки, делая между ними связи и настраивая их определенным образом. Чем сложнее логика процесса, тем больше приходится применять усилий. Но в целом они меньше, чем при создании полноценного кода. Однако ограничения могут быть таковы, что без программирования (а оно там есть) не обойтись.
Реалии показывают, что нетипичные задачи реализуются грамотным программистом. После чего она становится доступной обычному пользователю при визуальном проектировании и реализации процесса

Приличная BPM-система дает вам всего-навсего единую модель бизнес-процесса, с которой работают и аналитик, и архитектор, и программист. Происходит это примерно так: 1) бизнес-аналитик рисует схему процесса (шаги, переходы, бизнес-правила), 2) архитектор добавляет к ней оркестровку и хореографию, 3) программист разрабатывает интерфейсы - пользовательские и для связи с унаследованными системами. При этом инструментарий поддерживает различные представления этой единой модели. Например, аналитику незачем видеть детали программной реализации (еще испугается болезный) - он их и не видит в своем представлении, хотя в модели они присутствуют, например, в виде URL вебсервисов и JSP-страниц.

О том, чтобы избавиться от программиста, речь не идет; максимум - о том, чтобы BPM-система без его участия могла автоматически сгенерировать прототип информационной системы. Непригодный для промышленной эксплуатации, но позволяющий аналитику потестировать процесс.

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

Но что такая система реально обеспечивает - это устранение разрыва между аналитиками и программистами. Тут не забалуешь: если архитектор или программист увидел, что нарисованная аналитиком схема технически не реализуема (бывает в 100% случаев), то она тут же и исправляется им самим или аналитиком по его требованию. То есть при всех обстоятельствах аналитик и программист работают с одним и тем же процессом, хотя и с разными его аспектами.  Надо ли объяснять, что при традиционной разработке процесс, который представляет себе аналитик, и процесс реализованный в системе - это далеко не одно и то же, и к чему в итоге приводит такой разрыв?

Полагаю, это и есть в реальности тот мостик, о котором мечтает топикстартер.

Будьте осторожны: системы, в которых исполняемая модель процесса генерится из аналитической модели (например, из ARIS генерится BPEL) - типичное "не то". Во-первых, далеко не все из аналитической модели можно странслировать в исполняемую, а во-вторых, к исполняемой необходимо добавить много того, чего нет в аналитической. В итоге мы получаем ДВЕ модели, каждая из которых правится разными ЛЮДЬМИ. И синхронизовать эти две модели не получается, хоть убейся. Разговоры об этом тот же IDS Scheer ведет уже много лет, а толку чуть. Поэтому в итоге и пришли к необходимости единой модели.

В качестве положительного примера могу предложить взглянуть на Oracle BPM (ранее известный как BEA AquaLogic BPM, ранее известный как Fuego BPM, не путать с Oracle BPEL). Скачайте бесплатно на сайте Oracle BPM Studio - этого достаточно, благо в студию встроен движок.

По поводу чертежа и дома... Тут ближе другая аналогия: CAD/CAM. Чертеж не на ватмане, а в программе, которая умеет закачать его в станок, а тот, в свою очередь, умеет изготовить по чертежу деталь.

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

Будьте осторожны: системы, в которых исполняемая модель процесса генерится из аналитической модели (например, из ARIS генерится BPEL) - типичное "не то". Во-первых, далеко не все из аналитической модели можно странслировать в исполняемую, а во-вторых, к исполняемой необходимо добавить много того, чего нет в аналитической. В итоге мы получаем ДВЕ модели, каждая из которых правится разными ЛЮДЬМИ. И синхронизовать эти две модели не получается, хоть убейся. Разговоры об этом тот же IDS Scheer ведет уже много лет, а толку чуть. Поэтому в итоге и пришли к необходимости единой модели.

Согласно презентации господина Ладыженского (Директор по технологиям Oracle в СНГ) цепочка BPA->BPEL(JDev)->Репозиторий якобы обеспечивает такую приемственность, но "потрогать руками" ее нельзя, т.к. Репозиторий в демоверсию не входит .

В качестве положительного примера могу предложить взглянуть на Oracle BPM (ранее известный как BEA AquaLogic BPM, ранее известный как Fuego BPM, не путать с Oracle BPEL). Скачайте бесплатно на сайте Oracle BPM Studio - этого достаточно, благо в студию встроен движок.

Он позволяет получить готовый модуль для AS? Многопользовательская работа с разделением полномочий?

Так и я о том же: говорят об этом давно... Задача взаимно-однозначной трансляции eEPC -> BPEL очевидно не решается в принципе. Моделировать же BPEL в ARIS вообще непонятно зачем, а главное, BPEL - это точно не для бизнес-аналитиков.

Не понимаю что Вы имеете в виду под "готовым модулем для АС", но запустить в браузере процесс и выполнять его шаги от лица нескольких пользователей сможете. Подключиться с другого компьютера очевидно тоже сможете, а вот при работе одновременно несколькими пользователям возможно ограничение по количеству сессий. Но там же и на тех же условиях можете скачать полноразмерный движок. Процесс экспортируется из студии и импортируется в движок вполне гладко. Только берите вариант standalone, если только Вы не эксперт в WebLogic.

Не понимаю что Вы имеете в виду под "готовым модулем для АС"

Имеется ввиду модуль для размещения на сервере приложений.

Но там же и на тех же условиях можете скачать полноразмерный движок

Полноразмерный движок это...?

У вас есть следующий выбор:
1) Движок, встроенный в студию. Специально инсталлировать ничего не надо, запускается одной кнопкой, экспортировать-импортировать процесс не требуется. Идеально для evaluation, полезно для эскизной разработки.
2) Standalone движок. Инсталлируется достаточно просто, предварительно требуется наличие СУБД. Запускается как отдельный процесс. Бизнес-процесс экспортируется из студии и импортируется в движок достаточно просто. Для тестирования и эксплуатации в неэкстремальных условиях.
3) Движок в виде J2EE приложения под WebLogic. Инсталляция сложная, без помощи эксперта по WebLogic лучше не пытаться. Зато можете пользоваться всеми прелестями J2EE, например кластеризацией. Импорт-экспорт бизнес-процесса аналогично варианту Standalone. Для business-critical приложений и там, где требуются высокая производительность/масштабируемость.