iscrafmТесная интеграция конечно достоинство.Я так не считаю. Достоинство - это как раз НЕ тесная интеграция. Когда вы одним легким движением можете заменить почтовый протокол на HTML или на COM-вызов, или включить шифрацию и электронную подпись (если часть приложений оказались за пределами локальной сети), или задействовать очередь MSMQ, если на противоположной стороне начали возникать отказы в обслуживании из-за пиков одновременного обращения от множества взаимодействующих приложений,... и выполнить кучу других действий в зависимости от изменяющихся обстоятельств. "Тесная" же интеграция - это жёсткая интеграция.

isfarmНе использование XML - просто пример того, что все это делается без XML.Совсем не обязательно на BizTalk передавать информацию в виде XML. Он может "скушать" и плоский файл. В XML он его переведет сам - для внутренней обработки. Если нужно информацию также передать в виде плоского файла, но другой структуры, то выходной XML легко в него преобразуется внутри BizTalk перед отправкой. Таким образом, BizTalk получает и отправляет НЕ XML, а то, что внутри оно преобразуется в XML - я в этом никакой проблемы не вижу.

iscrafmВтолкуйте лучше пользователям информационной системы, что они должны на листочке выписывать номера счетов, а чтобы посмотреть отчетность - запускать какие-то процедуры.Не понял... :( Зачем их выписывать? В InfoPath есть поле "список", в котором реально прошедшие счета могут отобразиться. Выбрал из списка, нажал кнопку "показать"... :)

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

Тем же, кто хочет видеть результаты хозяйственной деятельности, предоставляется возможность смотреть отчеты какие угодно и как угодно - но это НЕ заслуга BPMS. Это заслуга Reportin Services или любого инструментария, который может крутить кубики OLAP. Задача BPMS совместно с теми системами, которые она объединяет - обеспечить наличие информации в этих кубиках.

Сахават ЮсифовЗачем какая-та надстройка для синхронизации, если и так есть очереди и система уведомления у каждого объекта?Если они просто ЕСТЬ и никогда не изменяются, то, вроде бы и незачем... :) Настроил их в ERP / MES - системе, подождал, пока "бетон застынет" - и погнал по застывшей бетонной дорожке быстрые тачанки. А случится вдруг понять, что нужно изменить алгоритмы НЕ ОСТАНАВЛИВАЯ ПРОИЗВОДСТВО , и бац - приплыли. Бетон-ссс.... Оказывается, дорожки должны были быть "резиновыми", если мы их собираемся всё время гнуть, пристраивать, перенастраивать...

Сахават ЮсифовА моделирование БП не такая простая вещь. Рассматривается ли там динамические компонуемые модели? Например: Есть технологический граф (описание производства), есть не связанные процессы с входами, выходами и механизмами описанными параметрами. Сможет ли БПМС генерировать оптимальные потоки с динамической привязкой процессов к технологическому графу с частотой , допустим, 1 минута?В BPMS заранее не заложены какие-либо конкретные алгоритмы оптимизации или решения задачи комивояжера методом ветвей и границ, оптимального рассовывания нескольких грузовиков по нескольким магазинам методами линейного программирования и т.п.. Но... Реализовать их можно. В BizTalk можно, вооружившись языком программирования VB, запрограммировать всё, что душе угодно - и завернуть этот программный модуль в кастомизированный "кирпичик", который включен в работу более крупной схемы бизнес-процесса. И желательно четко разобраться, где "кирпич", а где "здание", которое из подобных "кирпичей" собирается.
Однако, разработка таких тяжеловесных "кирпичей" в BPMS, хотя и возможна, однако, не особенно приветствуется. Лучше наваять отдельное приложение, представляющее WEB-сервис, и к нему обратиться. Разумеется, если есть такая возможность. В общем, "кирпич" - это "куркулятор", выполняющий один элементарный бизнес -расчет. И не важно, что в процессе этого расчета вычисляется дивергенция и ротор, выполняется свертка функций, преобразование Котельникова и транспонирование матриц. С точки зрения бизнеса это одно телодвижение "лобной мышцей" с целью получения одного ответа на один вопрос. BPMS - это скелет, на котором такие "лобные мышцы" могут держаться, составляя единую конструкцию. Они могут заставить эту конструкцию двигаться, быть непротиворечивой, быстро реагировать на изменение направление ветра, на возникновение луж под ногами и т.д. и т.п. Можно быстро менять форму тела, оставляя "кирпичи"-мышцы, из которых оно состоит, неизменными. Вот было сердце слева. Решили переместить его направо. Бац - и переместили. При этом не возникает никаких кровотечений из-за того, что часть крови направили по новой траектории. Та кровь, которая "еще не знает", что сердце переместилось, спокойно идет старым путем. Сердце как бы временно возникает в двух местах - в старом и в новом. Старая кровь идет к старому сердцу, новая - к новому. Когда цикл закончится, постепенно вся кровь переключится на новую траекторию. А можно всю сразу переключить на новую траекторию (это какой вариант больше менеджмент устраивает). Но главное - такие "микрохирургические операции" можно делать одна за одной, непрерывно, не останавливаясь. Часть организма еще живет как хордовая, часть - как птица, часть как млекопитающее... Развитие организма не тормозится его текущими формами существования. В ЭТОМ - ОСНОВНОЕ ДОСТОИНСТВО BPMS. В ДВИЖЕНИИ!!! . А Вы берете один застывший кадр (например, состояние "хордовое" в столько-то минут, столько-то секунд) и говорите "а из чугуна его вылить лучше полчится". Да, получится лучше. Только птицей оно уже не станет!

iscrafmGarya, Вы идеалист. Мне еще не встречались люди, которые бы доверяли ответам ИС типа: 'спокойно, у тебя все хорошо'.Да нет, не идеалист... :) Мне хорошо известны ситуации, в которых обойтись без человека невозможно. Однако же и доля таких операций, в которых человека вполне может заменить компьютер, довольно высока.
Типичный пример, который рассматривается в BizTalk в связи с появлением бизнес-правил - это бизнес процесс, в котором в случае превышения суммы контракта выше заданного порога контракт должен утверждаться топ-менеджером, ниже заданного порога контракт утверждается менеджером более низкого звена. Так вот, совсем не обязательно человеку оценивать, больше или меньше сумма контракта задонного порога. Человек может ошибиться, заболеть, прохлопать ушами... Бизнес-процесс же просто делает то, что в нем нарисовано. Проверить - проверили, в зависимости от результата пустили согласование по одной или по другой траектории. Никаких исключений, если они специально не прописаны в бизнес-процессе. И, соответственно, гораздо меньше всяких неожиданностей.
Если руководитель надумал изменить величину порога, бизнес-аналитик заходит в бизнес-правило и изменяет его - программист нафиг не нужен для подобной операции.