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

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

Я не думаю, что объединение и без того богатого функционала BPM-систем с непростой бизнес-логикой, заложенной в ERP-системы в одном продукте, является целесообразным. Не следует забывать, что на предприятии существует большое количество информационных систем других типов: HRM, CSM, CRM, а также и другой зоопарк. Integration-centric BPMS как раз и призваны объединить все информационное пространство компании в едином интерфейсе выполнения задач по принципу "Смотри, что и когда ты должен сделать и не думай о том, в какой системе требуется эти задачи выполнять". При этом решаются проблемы интеграции (чтения метаданных, передачи данных, удаленного исполнения логики систем), а не объединения функционала в едином продукте-монстре, который может оказаться слишком тяжеловесным, чтобы с ним работать ежедневно.

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

Рано или поздно это должно было произойти: если считать, что накопленный объем кодов систем ERP, CRM и прочая растет с годами линейно, то затраты на переписывание будут расти квадратично - с добавлением очередной компоненты нужно переписывать все уже имеющиеся. Когда-то эта квадратичная парабола должна была упереться в ресурсные ограничения, и похоже это уже произошло.

Отсюда идея SOA - раз переписывать невозможно, давайте договоримся о платформенно-независимых и с поздним связыванием интерфейсах взаимодействия. Так что уместно говорить только об интеграционном продукте, который *свяжет* функционал различных классов, но никак не "вместит". Инфраструктура SOA свяжет на физическом уровне, а BPMS - на логическом.

Алексей, а таёта тут причем? Поясните Вашу мысль пожалуйста.

Попытки создать нечто, включающее в себя "Все вообще", предпринимаются постоянно, и с таким же постоянством заканчиваются тем, что потом к этому "всему" прирастает еще что-то со стороны для полного счастья...
При помощи одного маркера можно разрисовать все, кроме самого маркера. Двумя маркерами можно разрисовать вообще все

Честно говоря, мне кажется, что ничего хорошего в зоопарке с дирижёром нет.

Никто не говорит про "все в одном". Два в одном вполне возможны. Нет никаких реальных причин, почему функции ERP и BPM не могут быть хорошо собраны в одном продукте. Никого же не напрягает, что ERP системы содержат принципиально разные приложения.

Понятно, что вендорам ERP не хочется, чтобы BPM конкурировали, а вендорам BPM хочется зарабатывать еще и на ERP пользователям (которые от ERP уже не откажутся). Аналогично были разговоры про CRM, как модель параллельную ERP. Потом оказалось, что CRM вполне реализуемы внутри ERP как очередное приложение.

Максим

Ваши параллели с CRM не вполне корретны. Дело в том, что и ERP, и CRM относятся к прикладному ПО, а BPM - нет. BPM корректнее сравнивать с DBMS, а нынешние дискуссии на тему нужен или нет BPM один-в-один копируют дискуссии двадцатилетней давности на тему так ли уж нужна DBMS, как нас в этом уверяет Oracle. И в полной аналогии с Вашей аргументацией тогда некоторые производители бухгалтерского софта заверяли, что внутри у их продукта есть собственная СУБД, которую заказчик получает впридачу. Цена той аргументации сегодня ясна всем - пройдет время и дискуссии вокруг BPM сойдут на нет.

Не хочется вдаваться в подробности, но между системным и прикладным софтом есть фундаментальные различия с точки зрения бизнеса, и совмещать одной компании и те, и другие разработки крайне сложно. А совмещать в одном продукте в сколько-нибудь значимом масштабе и вовсе невозможно.

Анатолий

Я бы согласился бы, если бы не "но". BPM системы часто содержат наборы прикладных типовых процессов. Так же, как и бизнес сюиты. Я не большой специалист по Unify, тут уж Вам виднее, но в целом - BPM это система управления Бизнес процессами, а не системными процессами. Аналогия с DBMS понятна, но это скорее SOA оркестраторы ближе к системным. Нельзя забывать, что на самом деле и СУБД давно уже стали решать прикладные задачи, работая серверами приложений. Так что и помеси системного с прикладным давно известны.

Касательно аналогии с моей аргументацией: СУБД стали выносить отдельно потому что хотели хранить данные в одном месте, потому что появился какой-никакой а стандарт и потому что это очень сложный инструмент, чтобы его сделать самому. Сейчас все чаще приложения переходят на ембеддед базы, потому что это проще и удобнее (если не нужно централизованное хранение и обработка).

Но сравнивать BPM с системными СУБД я не могу. BPM это все-таки больше чем например системный .NET Workflow Foundation. BPM это часто продукт с инструментами BI, Executive Dashboard, User Portal, Process Simulation и т.п. Вполне такая платформа бизнес приложений. Не сильно отличающаяся от платформ под CRM/ERP приложениями.

Максим, в Вашем перечислении подсистем, входящих в BPMS и итоговом выводе об отличиях по сравнению с платформами CRM/ERP, в которых есть свой Workflow - я не нашел подсистемы моделирования процессов (бизнес-модель) и дизайна процессов (IT-модель). Анатолий рассказывал про необходимость устранения разрыва между этими двумя моделями, проблемах roundtrip и прочих необходимостей внесения изменения для повышения гибкости бизнеса.
Если в ERP надо поменять Workflow - то это гораздо бОльшая проблема, чем сделать то же самое в BPM. А возможность создания композитных приложений без программирования? А ролевые интерфейсы с отображением только необходимой для выполнения задачи информации?.. Вобщем я вижу много отличий и надеюсь, что Вы тоже увидите их, если захотите.

Максим,
наборы типовых процессов - это заранее описанная последовательность шагов, которые определяют очередность ввода информации в систему. При этом, очередное событие наступает тогда, когда определенный пользователь ввел в систему определенную информацию. Это workflow - да, но не BPM.
Пример: поступила выписка из банка (через Клиент-Банк). Пользователь ERP-системы вводит информацию о платеже, после чего задание переходит в следующие руки. Это "ERP-BPM". Как в этом случае работает BPM: выписка поступила - по этому событию движок BPM инициирует процесс обработки, дальше процессы, ожидающие этого события, что-то выполняют... Разница в том, что ERP - пассивная система, ожидающая действий участника, чтобы что-то сделать. Она обрабатывает только те события, которые уже зафиксированы в системе. Забыл участник разнести платежи - значит все ждут. BPM - система активная, она общается не только с узким кругом собственных транзакций, а сует свой нос во все ИТ-окружение. Она сама запрашивает у участника действия, сообщая ему, что уже пора. Она не ожидает выполнения заданий, а активно напоминает, запускает процессы эскалации - т.е. предпринимает меры (если по-человечески )Здесь напрашивается еще одна большая тема - асинхронные процессы. Workflow этого не делает.

Позволю себе большую цитату, источник: Intelligent Enterprise №4, 2008 года, стр. 16-25:

"Intelligent Enterprise: Теперь от концептуальных моментов BPM давайте перейдем поближе к конкретике. Можем ли мы описать видовые черты BPM-системы — функции, которые она обязательно должна делать? Что можно считать BPMS, а что точно ею не является? И в чем её отличие от workflow-системы?

Дмитрий Грязнов: В моем понимании BPMS — это решение, позволяющее на основе модели бизнес-процесса и ее привязки к реальным системам отслеживать прохождение процесса и оптимизировать его. К примеру, система бюджетирования позволяет реализовать процесс планирования бюджета. Но она не позволяет отслеживать его ход, видеть, какими ресурсами сделаны эти действия. Любая операция в процессе должна как-то отражаться в информационной системе, чтобы мы имели возможность смотреть, как он проходит.

Александр Тарасов: Мне кажется, это очень размытое понимание. Какую функциональность должна обеспечивать BPM-система? Я думаю, здесь целесообразно опираться на понятие жизненного цикла. Бизнес-процесс нужно разработать, спроектировать, смоделировать, описать. Затем его необходимо протестировать, еще не запустив в реальную работу, — сделать эмуляцию этого процесса. После этого он внедряется и запускается в реальный бизнес. Следующий шаг — за ним нужно наблюдать, чтобы произвести оптимизацию. И потом мы снова возвращаемся к его моделированию — цикл замкнулся. Это та функциональность, которую должна покрывать BPM-система. Если и не самостоятельно, то в комплексе с другими продуктами.

Дмитрий Грязнов: BPM-системы выросли из workflow. Потому что оба эти класса основаны на понятии процесса. Но их коренное различие заключается в том, что workflow сосредоточено на движении — передаче документов, фиксировании результата на каком-то этапе. Нам было важно, чтобы процесс шел по правильному пути, но в рамках workflow не ставилась задача его непрерывного мониторинга. Мы могли смотреть, сколько документов скопилось, но вопрос прохождения процесса, скорости и затрачиваемых ресурсов нас не интересовал. Кроме того, в ВРМ-системе существуют такие понятия, как human workflow, когда что-то делает человек, и transactional workflow, когда какие-то процессы должны пройти автоматически, без его участия.

Алексей Прошин: Еще одно принципиальное отличие workflow от BPM-систем в том, что бизнес-описание, которое строится с использованием средств бизнес-моделирования в системах workflow, оказывается довольно примитивным. Это — своеобразный язык, который уже напрямую переводится в конкретные автоматизированные системы. Создаются дополнительные диалоговые окна, интерфейсы и так далее. В workflow не было языка моделирования бизнес-процессов. И вот появился BPMN — Business Process Modeling Notation. Именно как средство моделирования на языке, понятном бизнесу, на котором могут и должны говорить бизнес-менеджеры. И это важнейшая черта ВРМ-систем."

Пару слов от себя: есть много компаний-поставщиков, которые можно назвать Workflow и нельзя называть BPMS ) Ярким примером Workflow на конференции BPM 2008 был доклад компании Epicor Scala.

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

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

Можно выделить следующие сценарии взаимодействия WоrkFlоw-системы с произвольной прикладной системой:
- отслеживание событий в приложении. Например, при появлении нового платежного документа в ЕRР-системе WоrkFlоw-система должна обеспечить доставку информации об этом событии заинтересованным лицам;
- маршрутизация ссылки на объект прикладной системы. Например, в предыдущем сценарии заинтересованным пользователям доставляется не только информация о документе, но и ссылка для ознакомления;
- обмен данными между прикладной системой и подсистемой WorkFlow. Например, сумма, указанная в платежном документе, должна быть считана в переменную процесса для определения маршрута согласования документа;
- синхронизация справочной информации. Например, синхронизация справочника пользователей прикладной системы и системы WorkFlow

Перечисленные примеры - интеграционные возможности Workflow, из которых следует, что не так уж и пассивно ведут себя системы ERP с использованием функциональности Workflow-модулей. На имеющемся функционале при должном уровне владения инструментом можно реализовать и эскалацию, и хореографию, и конечно же оркестровку... В ARIS есть многие возможности для успешной работы (события, триггеры). Подход Workflow также требует минимизации программирования при описании процессов. В Workflow решается и проблема управления изменениями бизнес-процессов, для чего в модели процесса должна быть реализована возможность автоматического внесения изменений в экземпляры уже запущенных процессов (знаменитая "фишка" редизайна современных BPMS, переноса экземпляров процессов "на лету"). Мне самому сложно предоставить действительно веские аргументы в пользу того или иного подхода, но я уверен, что концепция BPM не отрицает достоинств workflow-систем, а развивает их возможности. Можете просто посмотреть эволюцию монстров типа EMC, DocsVision, Oracle, ... чтобы проследить чего же им не хватало, что они для этого добавили и что получилось в результате.

В предыдущем посте была цитата из источника: В. АНДРЕЕВ Компания Digital Design, Финансовая газета N 003 стр. 14-15 от 21.01.2005

"Термин "WorkFlow" отражает, скорее, тенденции в реализации подхода к автоматизации, чем четко оформленный стандарт. Несмотря на определенные попытки формировать спецификации, предпринятые различными организациями, каждый производитель волен интерпретировать данный подход. На наш взгляд, модели идеальной WоrkFlоw-системы, которая позволяла бы с помощью параметрического описания реализовывать произвольный процесс во всей полноте функций, необходимых для его автоматизации, до сих пор не существует. К классу WоrkFlоw-систем обычно относят системы, содержащие те или иные средства описания процессов в виде последовательности этапов обработки. Как правило, данное описание реализуется как графическая диаграмма, хотя в некоторых системах оно фиксируется в виде таблицы состояний и описания переходов между ними. Помимо этого от WоrkFlоw-системы требуется наличие "движка", позволяющего запускать экземпляры данного процесса. Обычно наличие двух этих инструментов и дает возможность производителям добавить к названию своего продукта расширение WorkFlow. При этом функциональное наполнение, класс автоматизируемых процессов и "степень покрытия" реальных нужд потребителей таких систем могут существенно отличаться. Кроме того, существуют дополнительные компоненты WоrkFlоw-систем, например средства мониторинга реального состояния процессов, средства отладки и имитационного моделирования процессов, наличие универсальной очереди заданий и интегрированного клиентского рабочего места, средства разработки и настройки объектов, обрабатываемых в рамках процесса, наличие инструментов интеграции с различными прикладными системами. Разные производители систем предлагают различные наборы подсистем в составе созданных ими продуктов.

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

Отсюда может косвенно следовать вывод, что вендоры наконец смогли совершить революционный шаг вперед и смогли разработать подходящий инструмент для того, чтобы реализовать все те заявленные преимущества. Но с маркетинговой точки зрения это уже нельзя было назвать просто "Workflow. Так как мы его задумали 10 лет назад" или "Workflow 2+". Для того, чтобы подчеркнуть инновацию концепции было дано имя BPM, поэтому, на мой взгляд, сейчас довольно сложно сравнивать и утверждать о достоинствах и недостатках того или иного подхода. Workflow не умер, он имеет право развиваться дальше. Надо просто понять суть "революции", научиться реализовывать ее преимущества, поймать волну прогресса, если угодно =)

Михаил, у меня нет никаких сомнений, что текущая реализация Workflow моделей в ERP или CRM это жалкое подобие возможностей полноценного BPMS. Что однако не отменяет того, что со временем либо ERP подойдут ближе к BPMS по своим возможностям, либо наоборот. Я спорил лишь с тем, что это параллельные модели, которым нужно жить вместе. Мое мнение, что ERP покроют по функциональности возможности BPMS со временем, что впрочем не отменяет того, что для BPMS будет место там, где ERP не будут установлены.

Юлия,

Я явно неправильно был понят. У меня нет никаких сомнений в том, что workflow от ERP это НЕ BPM. Я в конце концов сам разработчик BPM системы и понимаю чем одно отличается от другого. Я лишь сказал о том, что со временем ничто не помешает ввести функциональность BPM внутри ERP систем. Эта добавка не столь уж и велика, по сравнению с объемом функциональности ERP, чтобы считать, что и впредь ERP будет проигрывать BPM системам.

Михаил, спасибо за цитаты и мнение.

Я хочу еще раз подчеркнуть о чем я говорил - BPM не противоречит ERP модели, а эффективно дополняет. Но нет никакого логического основания считать, что эти 2 системы обязаны быть раздельными продуктами.

МОе мнение, что BPMN не является пределом счастья в плане управляемых процессов. Более того, я думаю, что это слегка тупиковый путь, так как за кажущейся гибкостью стоит существенное переусложнение и недостаточная понятность пользователям. Степень требуемой квалификации очень высока, а конечная реализация все-равно требует программиста. При этом, за счет отказа от объектных моделей и многих других наработок, создание эффективной и работоспособной BPM системы хотя бы с тысячами процессов становится слишком дорогим и длительным удовольствием.

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

Мне кажется, ERP вендоры понимают, что в направлении BPM будущее эффективной автоматизации. Но пока они не готовы бросаться на такие реализации, эффективность создания которых зачастую сомнительна. Я так думаю, со временем BPMS как отдельный продукт начнет отмирать, вливаясь в другие системы как составная часть. Не трудно заметить, что основные претензии к BPM системам в основном в том, что они не содержат в себе функций, которые уже есть в ERP.

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

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

Так что я сомневаюсь, что профессиональные ERP будут разваливаться на независимые блоки или даже микро-сервисы, с интерфейсом через веб-сервисы. Это и технически ошибочно и невыгодно самим производителям ERP. Однако публиковать доступ через веб-сервисы для сторонних систем - это и так уже есть. Но если есть ERP - то кому как ней ей решать как все должно работать?

Гибкость же, удобство, эффективность систем, как я вижу, никогда не была в прямой связи с кросплатформенностью и независимостью. Это всегда определяется тем кто насколько хорошо сделал свою работу, создав инструмент.

К тому же компании никогда не пойдут на то, чтобы BPM была извне, т.е. процессы между компаниями всегда будут просто разными процессами, стыкующимися через API вроде веб-сервисов. Так что и смысла им иметь независимый оркестратор - не много. Тут просто не грех будет добавить общих бизнес стандартов регламентирующих эти сервисы, чтобы проще было стыковаться как внутри, так и снаружи.

Так что я верю в то, что BPM сольются с ERP, видимо выживет скорее термин ERP.

Коллеги, может сначала определимся что называть BPM(S)? А то уж очень хаотичная дискуссия получается. В самом широком смысле этот термин означает континуум, простирающийся от языков (например BPEL) на одном краю до прикладных систем с встроенным (embedded) BPM или Workflow движком. Однако здесь, на этом сайте, в основном обсуждается середина этого спектра - BPM-системы общего назначания, включающие, как минимум, средства моделирования, исполнения и мониторинга/анализа бизнес-процессов.

Далее. Внутри этого класса тоже есть значительное разнообразие, отражающее эволюцию BPM-систем. Сегодня аналитики выделяют как самые прогрессивные те системы, в которых 1) наличествует roundtrip и единая модель процесса с различными представлениями для аналитика и ИТ-специалиста (по контрасту с системами, в которых разные модели преобразуются в одну сторону через экспорт-импорт) 2) на равных поддерживаются "человеческие" и "системные" процессы, workflow и интеграция, оркестровка и хореография 3) поддерживаются стандарты (сегодня - BPMN и BPEL).

Workflow-модули, встроенные в ERP и CRM, а также т.н. "traditional workflow" системы обычно хромают по всем этим критериям. (Правда надо признать, что и среди BPM-систем пока нет ни одной которая бы полностью им удовлетворяла. Но они хотя бы стремятся приблизиться.)

Максим, Вы упорствуете в заблуждениях 1) Да, многие поставщики BPM поставляют так называемые "отраслевые шаблоны" и консалтинговые услуги по превращению этих шаблонов в работающие прикладные системы. Точно так же в дистрибутив Excel Microsoft вкладывает "решения" типа пересчета долларов в евро. Означает ли это, что Excel можно ставить на одну доску с прикладной системой? 2) Вы правы, BPMS увешен большим числом "свистков и бубенчиков" в виде BAM, Dashboard etc. Но ведь и DBMS тоже сегодня поставляются в виде suite в комплекте со студией и средствами мониторинга, так что я настаиваю на том, что BPMS правильнее относить не к прикладному софту, а к системному. (Или, или если угодно, к промежуточному - разные авторы относят DBMS то к тому, то к другому.)

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

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

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

Поэтому успешно совмещать в рамках одного бизнеса прикладные и системные разработки крайне сложно. Разная культура. Исключением могут показаться Microsoft и Oracle, которые таки совмещают. Но если присмотреться, то и там это разные бизнесы, хотя и в рамках одной компании.

И напоследок отвечу на замечание Максима о встраиваемых СУБД. Все правильно, такой тренд есть, но объясняется он тем, что СУБД эволюционировали практически до предела и превратились в товар повседневного спроса. Ну да, маркетинговая машина Oracle работает на всех парах, рассказывая нам по каким критериям их СУБД превосходит всех конкурентов. И мы даже с этим соглашаемся, но штука в том, что нам как правило нужна не самая лучшая, а всего лишь "достаточно хорошая" СУБД. А таких - до черта! Включая бесплатные и/или встраиваемые с нулевыми затратами на администрирование. Посмотрите насколько упали цены СУБД. Да что там - сегодня вся ведущая тройка предлагает вполне рабочие конфигурации своих продуктов бесплатно.

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

"Компании никогда не пойдут..."? То есть Вы считаете, что SOA придумали вендоры и никаких реальных потребностей и/или проблем организаций за этой искуственной концепцией не стоит? Что ж, это достаточно распространенная точка зрения. Поживем-увидим. Я думаю, произойдет следующее: голоса типа "нафиг BPM, ERP рулит" будут звучать до тех пор, пока Gartner вместе с вендорами не начнут продвигать новую технологию XYZ. И тогда мы услышим "Ладно, ERP и BPM пусть живут. Но вот XYZ - это просто злобное изобретение вендоров!" Пока технологии развиваются, все время есть точка роста, и она-то привлекает максимум критики. Отчасти из-за незрелости и криваков, отчасти потому, что кое-кому не позволяет жить с накопленным багажом. У меня складывается впечатление, что те, кто сейчас поливают BPM и говорят, что "лучше уж ERP, чем это говно" еще вчера, когда про BPM они не слышали, а ERP было новым словом, точно так же хаяли ERP. (К присутствующим естественно не относится.)

Потери на трафике и производительности? Да наплевать, по большому счету! Неужели Вы не видите: ресурсы производительности серверов и пропускной способности каналов непрерывно растут, но одновременно растет дефицит ресурсов разработчиков. Толкового разработчика найти - жуткая проблема, а процессор на сервере в среднем загружен на 7%. Отсюда закономерное стремление менять машинные ресурсы на человеческие - максимально упростить администрирование (встроенные СУБД), конфигурирование и особенно изменение конфигурации (слабо-связанные блоки SOA), сделать формат файла читаемым и самодокументируемым (XML)... - во всех этих примерах мы тратим больше машинных, но меньше человеческих ресурсов.

А я не согласен, что процессы между компаниями всегда будут разными процессами. Есть масса теоретических методологий, которые обеими руками за то, чтобы выстроить взаимоотношения с поставщиками таким образом, чтобы мы напрямую могли предъявлять требования к выходу процесса поставщика. Чтобы взаимоотношения с заказчиками были максимально автоматизированы и заказчик мог не только оформить заявку на приобретение товара и отслеживать ее статус, но и вмешиваться в ход процесса в любой момент, уточнять требования, изменять маршрут. Если речь идет о двух различных компаниях одного холдинга - тут тем более информационные системы обязаны обмениваться данными, и очень хорошо, если это реализовано не точка-точка, а через процессы. Можно сколько угодно оптимизировать свои внутренние бизнес-процессы, но если у тебя плохой поставщик/не выстроены взаимоотношения, то ошеломляющего успеха не достичь. Поэтому даже сейчас (всмысле даже в России) можно привести несколько примеров объединения бизнес-процессов разных компаний с использованием BPMS.

Анатолий,

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

Насчет трафика и производительности. Ресурсы, как ни странно, растут медленнее чем запросы. Потребность в детальности данных, в степени глубины обработки, в объеме взаимодействия растет еще быстрее. Загруженность процессора не отражает факта наращивания лага и тем более не отражает пиковой нагрузки. Увы, с этим мифом о том, что теперь не надо делать эффективный софт родилось целое поколение программистов. Результат? Системы никогда не были такими медленными как сейчас на самом современном оборудовании.

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

Касательно того, что используя читабельный протокол мы экономим ресурсы программистов - это не так. Ресурсы программистов экономятся наличием эффективных библиотек с грамотным стандартом, хорошей документацией и отлаженным API. А как оно там внутри работает - это десятое дело совершенно.

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

К выходу, но не к внутреннему устройству. А примеры того как объединяются процессы разных компаний конечно есть. Но это исключительные случаи.

Смотря что понимать под блоками одной системы. Никто не призывает разбивать все на куски только ради удовольствия это делать. Но вот когда Oracle покупает Siebel и включает его в состав своих Applications - что делать с такой "одной системы"? Все переписывать чтобы сделать ее "по-настоящему" единой или стыковать через сервисы?

Если речь идет, например, о блоках такого масштаба, как "финансы" или "непрерывное производство" в ERP, то им бы лучше стыковаться через loose coopling, даже если они являются модулями системы одного поставщика. И я надеюсь, через некоторое время мы такие системы увидим, а еще через некоторое время это станет мейнстримом.

Есть шанс, что когда-нибудь wsdl будет достаточно доработан и кроме того появится бинарная нотация (для этого надо еще прекратить споры что лучше Big или Little Endian). Тогда, конечно, почему бы и не перейти на него. Только вот в контексте BPMS это не факт, что хорошо, что какая-то система снаружи будет дирижировать кусками erp.