Ну я увидел это так:
BPMS - класс системного интегрирующего программного обеспечения позволяющее создаать сценарии выполнения типовых бизнес задач
(своего рода программы) типовых бизнесс задач и отслеживать выполнения конкретных процессов в соотвествии со сценарием.
Сценарий выполнения бизнес-процесса представляется как направленный граф, узлы которого - состояния,
являются либо задачей выполняемой пользователем, либо взаимодействием с некоторой внешней системой, либо другим сценарием.
Однако в отличиии обычных языков программирования языки описания бизнессов процессов предполагают не только последовательное
наличие состояний ожидания (например взаимодействие с пользователем) и обязательное графическое представление сценария.
Эти состояния ожидания не могут быть эмулированы средстами обычных языков программирования
аля wait-signal поскольку могут продолжаться значителное время.
Для выполнения конкретных заданий(процессов) требуется обеспечение runtime окружения, обеспечивающего:
1) персистентность состояния экземпляра процесса в узлах с сохранением состояния
2) обеспечение взаимодействия с внешними системами.А имеено на основании состояния экзепляра процесса сформировать
обращение к внешней системе и проецирование результата вызова на состояние экземпляра процесса
3) обеспечивать взаимоействие с пользователем
4) обеспечивать принятие решения (выбор из альтернативных путей выполнения)
5) вкуснсти связанные с мониторингом выполнения процессов.

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

Сахават Юсифов blindedЭти состояния ожидания не могут быть эмулированы средстами обычных языков программирования
аля wait-signal поскольку могут продолжаться значителное время.


Это почему же? Обычное асинхронное программирование.

Потом что обычно в таких системах одновременно исполняются сотни тысяч одновременных процессов и как првило каждый из них може иметь несколько параллельных путей исполнения. Да и времеа задержек могут быть по несколько дней, а иногда и месяцев. Сам когда-то был юзером service-desk и иногда задерживал исправление некоторых багов и доработок до полугода (типа будет в версии XXX)

Сахават Юсифов
Бизнес аналитики все равно не могут идти дальше квадратиков. :)
Чем больше квадратиков, тем больше программистов.
Это да и именно в этом мы c WJ и АБ сильно расходимся.
Кстати наиболее толковое представление о том что такое эти BPMS дает прочтение jBPM UserGuide там нет рекламных лозунгов и написао с точки зрения IT специалиста.

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

Но ежели почитать форум и рекламные хваленки свершенно не складывается представление о том зачем такие системы нужны и что они делают. И тут iscrafm абсолютно прав, если сторонник идеи не может в 10 строках объяснить квинтэсскнцию то либо идея гнилая либо сторонник плохо разбирается в проблеме

blindedОсновное достоинство и основной недостаок таких систем - легкость восприятия их представителями бизнеса и кажущаяся легкость изменения уже созданных сценариев бизнеспроцессов. Дело в том ценарии бизнесс процессов рисуются либо аналитиками, либо самими представителями бизнеса, однако эти лиюди не могут практически не способны правильно определить необходимые атрибуты описывающие состояние экземляра процесса, правильно расписать взаимодействие со внешними системами и создать формы дя взаимодействия с пользователем. В целом согласен. Язык BPM пусть не идеален, но он безусловно позволяет бизнесу и ИТ общаться более содержательно, чем известные альтернативы. Но более подходящее прилагательное к "легкости" -- не "кажущаяся", а "относительная". Этой легкости, помимо графических средств моделирования, способствуют: концепция композитного приложения, быстрые средства разработки таких приложений и reuse, которую призвана обеспечивать SOA. Все это, разумеется не гарантирует легкости, а только способствует -- т.е. насколько на самом деле окажется легко, зависит от вас: от вашей предусмотрительности в проектировании, в выборе инструментария, в постановке задач и т.д.
[/quot]
Слова, опять слова из рекламок. Есть пропасть между пониманием основополагающих идей BMP бизнесом(аналитиками) и IT - шниками (программистами)Для первых важен сценарий (квадратики и стрелочки) для других их наполнение. И BPMS отнюдь не сближает края этой пропасти
blindedпредставление о том что такое эти BPMS дает прочтение jBPM UserGuide там нет рекламных лозунгов и написао с точки зрения IT специалиста BPMS -- это только инструмент. Как можно понять что такое инструмент без понимания того, для чего он предназначен? А понять что такое BPM (по отношению к которому BPMS является инструментом) невозможно, не выйдя за рамки кругозора ИТ-специалиста, потому что это междисциплинарная концепция.[/quot]
Опять подтверждение моей мысли о пропасти. Способов познания есть множество и один из них взять молоток и тренироваться в забивании гвоздей

АБ
blinded
если сторонник идеи не может в 10 строках объяснить квинтэссeнцию...

Чтобы привести лошадь на водопой достаточно одного человека, но даже десять не смогут заставить ее пить. Или как там было у Стругацких: "Неубедительно!" и хоть в лепешку расшибись

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

АБ
Видите ли, я общаюсь с теми и другими (в соотношении близком к 50/50) постоянно. И на основании собственного опыта (а отнюдь не чтения рекламок) свидетельствую: сближает, и весьма заметно. Вы же, как мне кажется, теоретизируете "сидя на бережку".

Неправда ваша, мы рекламок вообще не читаем, предпочитаем документацию. Да и теоретиизировать о том чего не знаем не умеем. А недолгое плавание в водах предмета все же наводит на мысли
1) ни один из продуктов не разделяет роли аналитика и программиста при создании сценария бизнеса процесса,(не уверен что это вообще возможно). Но очевидно одно - it специалист не уполномочен создавать схему бизнес процесса и тем более ее менять, а аналитик не может определить контекст выполнения сценария и осуществить интеграцию с другими сценариями
Действительно дисциплина пограничная вот только не понятно что сней делать - выращивать породу универсальных аналитиков программистов? А сколько они стоить будут - эти человеки оркестры?
2) Все производители BPM систем говорят о простоте и невероятной скорости внесения изменений. Да не отрицаю что схему из квадратиков и стрелочек поменять достаточно легко. Но опять таки что делать с их наполнением, ведь вместе изменнеием схемы плывет и оно. Не говоря уже о смене версий сторонних систем и возможном изменении их интерфейсов. Насколько я понимаю - предполагается что сторонние интерфейсы давно устоявшиеся.
3) Как уже говорилось эти системы дают только средства по процессного анализа эффективности. А как быть с анализом межпроцессной эффективности. Ведь если у вас множество процессов сходятся на конкретном ресурсе(своеобразный bottleneck) то эффективность системы все равно ограничена, как бы не оптимален был каждый процесс.
4) КАк бы не были красивы слова о компонентных архитектурах, RAD и стандартных протоколах (RPC, CORBA,СOM, RMI, EJB, SOAР что еще забыл)- всем этим надо уметь пользоваться, и как показывает опыт -задача интеграции больших систем - одна из самых сложных.
Я не говорю что ничего делать не надо, нет надо. Только иногда проще и дешевле иметь команду it специалистов, или заказывать конкретные решения таким командам, нежели покупать универсальные системы. Опять же все зависит от масшстабов бизнеса, политических течений внутри организации и даже соображений престижа

АБЯ бы сформулировал это так: необходимо решить задачу представления функционала корпоративных систем (различных модулей ERP, CRM, MES, PLM и т.д.) в рамках сервис-ориентированной архитектуры, т.е. декомпозиции функционала на сервисы. После этого их можно связывать друг с другом напрямую, через EAI- или Workflow BPM.

И эта задача сейчас решается: где-то системно (вендорами ERP), где-то по месту (заказчиками и консультантами). В принципе, концептуальных проблем тут быть не должно: серьезные системы уже имеют интерфейсы в виде API, EDI и т.д., так что речь идет всего лишь о еще одной технической реализации.

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