ну и до кучи стоит еще познакомиться с терминами composite application и mashup.

Lunxправильно начинать с workflow - это систематизирует Есть и более весомый довод: у большинства бизнес-руководителей workflow вызывает самый живой интерес. Объясняется это тем, что схема бизнес-процесса в типовой BPM-системе соответствует той "картинке" бизнеса, которую они рисуют в голове или на клочке бумаги. Workflow предлагает сделать эту картинку исполняемой, т.е. без искажений довести ее до каждого исполнителя - фантастика! Это порождает энтузиазм с их стороны, выливающийся в поддержку проекта - и моральную, и бюджетную. Заручившись этим энтузиазмом, ИТ получает шанс "заодно" реализовать и необходимую инфраструктуру в виде SOA и ESB. Как советуют умные люди, "если хотите реализовать SOA - не называйте то, что вы собираетесь сделать, SOA". То же справедливо по отношению к любой "прогрессивной" ИТ-архитектуре: ищите аргументы для бизнеса. В случае SOA такие аргументы - BPM и процессный подход к управлению.

asdfghjklчто даст "нормальная BPM" сверх того, что дает арис Хотите загубить дело, скомпроментировать идеи процессного управления - приобретите арис. Приходилось иметь дело с компаниями, которые давно и "успешно" им пользуются. Результаты убогие. Мертвые схемы - устаревшие, грешащие приблизительностью, предполагающие "творческую интерпретацию" программистом, транслирующим их в разрабатываемые приложения...

В "нормальной" BPM схема бизнес-процесса является непосредственно исполняемой - без трансляции в компьютерные языки, без экспорта-импорта. И это принципиально, иначе (как в случае ARIS eEPC) разрыва между диаграммой процесса и информационной системой, между бизнесом и ИТ избежать не удается. Когда же такой разрыв происходит, можно забыть об идее непрерывного усовершенствования в духе цикла PDCA. А следовательно, забыть об идее процессного управления. Впрочем, заниматься старым добрым реинжинирингом можно, если кому-то это еще интересно.

iscrafmсегодня какой-то день сказок А что собственно вам представляется неправдоподобным? Нормальный DDA - Design Driven Architecture. Расширяйте кругозор.

Еще к вопросу о разнице между ARIS и BPM: From CIO to CPO via BPM. The Next Generation of Enterprise Automation. Howard Smith, 2005...In the 1990s, before the DBMS, process modeling was mostly process mapping oriented towards building the understanding of "how thigs get done around here", a step many felt necessary prior to any change, no matter how small. That's still a highly valid activity, but non-executable process maps are, like milk, perishable; use them, or they quickly lose relevance as the business simply "moves on". Now that we have a tool that manages runnging processes, why draw hundreds of process diagrams and leave them lying on the shelf, or in an electronic repostiory, unused and rarely referenced? The BPMS brings processes to life as executable systems, as simply as immediately as spreadsheets perform calculations...

Еще хорошая цитата из того же источника: Howard SmithThere is industry confusion about how the BPMS achieves DDA. A BPMS is not a compiler or translator that makes process diagrams and generates software code. A BPMS is a software system, not the beginning of a software development process. Buyer beware: any IT salesman who speaks about translation of a process diagram into any form of code, including new languages such as Business Process Execution Language (BPEL), is not speaking about BPM. Data is not translated to the relational model before it is managed using a RDBMS. Nor with the BPMS is it necessary to translate process to code for them to execute. Process models may be represented in BPEL or BPML, but this is merely a convinience and a manifestation of the trend towards the use of the Internet standrard, XML. In reality, a BPMS supports an executable process and it is, at one and the same time, the process and the system. Не найти систему, которая работает по этому приниципу способен, извините, только ленивый. TIBCO, WebMethods, Interstage, Unify, Intalio, JBoss... У многих, если не всех, есть evaluation версии. Цены разные, от очень дорогих до бесплатных.

aagВидимо, имелось в виду что в "нормальных" BPM процессы можно мониторить. Насколько я знаю, Aris 6.хх это также умеет. Мониторить он умеет, и даже очень хорошо. PPM - действительно симпатичная вещч. Он исполнять бизнес-процессы не умеет, вот беда. И не научится никогда, если говорить о eEPC. Импорт-экспорт не спасает.
aagТолько вот почему решили, что топикстартера спасет только BPMS - мне совершенно неясно. Уклонился от темы, признаю. Топикстартеру я бы посоветовал, прежде чем изобретать собственную архитектуру интеграции, прочесть книжку под названием "Шаблоны интеграции корпоративных приложений". В ней и теория, и описание нескольких коммерческих реализаций, и вполне жизненные примеры.

iscrafmнарисовал квадратики и они чудесным образом ожили! если с программированием, то в топку, не круто! Цирк уехал, клоуны остались.

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

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

iscrafmХотите достичь глубокого сымсла - извольте потрудится, серьезно попрограммировать, поимпортировать и т.п. Да, тренер

Смешно ей-богу считать, что вы один тут "серьезно трудитесь".

Уважаемый iscrafm! Если вы не согласны с моими высказываниями, то будьте любезны возражать по существу. Приписывать оппоненту тезисы, которые он не высказывал, и потом с успехом их опровергать - это дешевый полемический прием, который не делает чести вам и не уместен на профессиональном форуме, каковым является sql.ru.

Очевидно, вы просто не владеете вопросом: не дали себе труда познакомиться с тем, как работают BPM-системы. Только так можно объяснить вашу позу "этого не может быть, потому что этого не может быть никогда".

iscrafmПод вашим ником кто-то еще пишет? Нет, под этим ником пишет один человек, с одной головой и двумя руками.

Ну что ж, давайте спокойно рассудим.

Mainframe_старыйКогда Вы предлагаете от всех болячек BPMS Если Вы перечитаете топик от начала, то убедитесь, что я ничего подобного не предлагал. Тема workflow (точнее, в данном контексте это была не тема, а вариация) началась со следующего замечания:
LunxВообще - правильно начинать с workflow - это систематизирует. Я дал к нему небольшой комментарий, основанные на личном опыте.

Затем был задан вопрос asdfghjklА можно - очень кратенько - ответить: что даст "нормальная BPM" сверх того, что дает арис? Спасибо. Задан был не мне, но я позволил себе ответить. Надеюсь, это простительно? Этот ответ зацепил iscrafm, который употребил термин "сказки", что заставило меня аргументировать свою позицию.

Факт уклонения от темы я уже признал: АБУклонился от темы, признаю. Топикстартеру я бы посоветовал, прежде чем изобретать собственную архитектуру интеграции, прочесть книжку под названием "Шаблоны интеграции корпоративных приложений". В ней и теория, и описание нескольких коммерческих реализаций, и вполне жизненные примеры.

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

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