ЖораБушBizTalk прекрасно подходит для BPM сценариев.
При этом версионность поддерживается .Net фрэймворком. (а там с этим просто).Та версионность, которая обеспечивается .Net фрэймворком, преследует совсем другие цели. А именно - иметь информацию о том, что, кто и когда изменял. Это, конечно же, тоже интересно, но для BPM это не самое главное. Самое главное - сохранить работоспособность БП в процессе изменения его схемы. Вы попробуйте удалить в BizTalk шаг, на котором "подвисли" несколько "длинных транзакций" и посмотрите, как Вам поможет справится с выполнением этой операции .NET фреймворк. Если Вы считаете, что он справится, то опишите пожалуйста механизм обработки уже запущенных транзакций. И расскажите, в каком месте .NET-фреймворка этот механизм заложен.

ЖораБушЕще в BTS 2006 есть Human Workflow Services.
я думаю это то о чем вы говорите.Реально с "человеками" BizTalk-у наиболее удобно через MS InfoPath. Но MS InfoPath для отправки тех же уведомлений по электронной почте требует обязательного использования в качестве почтового клиента непременно MS Outlook (тысячу раз проклял за это InfoPath, когда пытался с его помощью реализвать пробное решение - мы пользуемся другим почтовым клиентом). Я уже не говорю о том, что XML-формы InfoPath сможет открыть лишь тот, у кого на компьютере установлен InfoPath . Согласитесь, что ни о какой кроссплатформенности в этом случае речи не идет. Следовательно, использование H2H ограничено лишь теми компьютерами, которые включены в локальную сеть и контролируются собственной IT-службой. Такой подход существенно ограничивает возможность широкого использования с предоставлением "человеческого" интерфейса для взаимодействия для потенциальных клиентов (то есть, неопределенной категории сторонних лиц). Опять же, для разветвленных холдингов нет уверенности, что на всех площадках присутствует MS InfoPath. Приобретать же его только ради возможности подключения к бизнес-процессам на все компьютеры несколько накладно... :(

P.S. Как бы Вы отнеслись к интернет-магазину, который для того, чтобы воспользоваться его услугами потребовал бы установки специфического Unix-приложения? :)

iscrafmзачем для этого новый класс систем. Типовой DevTrack и его братья с этим справляются прекрасно.Если Вы о версионности, то в BPM она нужна для других целей - для обеспечения непрерывности бизнеса. Прочитайте пожалуйста мой комментарий про .NET фреймворк чуть выше. Он как раз на эту тему.

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

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

blindedРеспект... :)

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


Это почему же? Обычное асинхронное программирование.
Бизнес аналитики все равно не могут идти дальше квадратиков. :)
Чем больше квадратиков, тем больше программистов.Не понял, при чем тут синхронное программирование? Вы попросили выписать счет Вашего партнера и отправили ему заявку. Счет может прийти через 2 часа, а может через 2 недели. Какое "синхронное программирование" позволяет реализовать алгоритм, который "заснет" на 2 недели, выдержит 14 перезагрузок компьютера и по получению счета автоматгом направит его тому, кто сформировал заявку? Или еще лучше - если счет не получен в течении 2 дней, крикнет "караул" тому, кто отправлял заявку (потому что сработал таймаут) и принудит его выполнить дополнительные шевеления, чтобы счет все-таки был выписан (зарегистрировав при этом, какие именно шевеления были предприняты).

blindedЕсть пропасть между пониманием основополагающих идей BMP бизнесом(аналитиками) и IT - шниками (программистами)Для первых важен сценарий (квадратики и стрелочки) для других их наполнение. И BPMS отнюдь не сближает края этой пропастиВот тут я позволю себе возразить, или уточнить. Пропасть между IT-специалистами и "людьми бизнеса" действительно есть. Это не следствие плохости или хорошести тех или иных программных продуктов, это объективная реальность, с которой приходится реально иметь дело. Но именно BPMS позволяет хотя бы уменьшить разрыв между ними. Она дает "человеку бизнеса" тот инструментарий, который ему понятен и позволяет взять на себя формализацию как всего БП, так и отдельные его операций. Да, всего лишь "позволяет", а не "заставляет". Но для тех компаний, руководство которых реально хочет взять свой бизнес именно в свои руки, BPMS предоставляют "прибрать к своим рукам" больше, нежели без них.

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

Применение процессного менеджмента сопряжено с серьезными подвижками в сознании менеджеров, в желании применять новые методы управления. И отсутствие такого желания - это главный тормоз в расширении практики внедрения BPMS.

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

Мы говорим BPMS - подразумеваем SOA! Мы говорим SOA - подразумеваем BPMS! (гим современных пионеров)

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