...починяю примусОчень часто - не возникает состояния "ожидания оплаты", даже на начальном этапе после подписания договора могут начинаться уже "телодвижения" по подключнию и началу предоставления услуг. Особенно - когда, по каким-либо соображениям, отсуствует начальный платеж(плата за подключение или что-то аналогичное). Такая ситуация - не редкость и не экзотика.Есть событие "заключение сделки". Оно может возникать по факту выписывания счета, или по факту заключения договора, или по факту поступления оплаты - через неделю позвонят и объяснят, за что. Инициировать бизнес-процесс могут документы разного вида, нужно только четко понимать, где он начинается и где заканчивается. Вы пишете, что в Вашем случае реакция на событие, на которое должен бизнес-процесс отреагировать, другая, нежели Вам написали в "например". Но это не имеет никакого значения. Можно настроить бизнес-процесс таким образом, чтобы он реагировал по-другому. И не нужно пытаться усложнить ситуацию, заведомо предполагая, что какую-то настройку бизнес-процесса уже сделать не удастся. Всё прекрасно удастся, сколько бы вы не накрутили дополнительных частностей. Просто на подробное расписывание механизмов их обработки мы изведем миллионы экстетов в базе данных форума sql.ru... :)

...починяю примусНо это все лирика. Я на что хочу обратить, еще раз, внимание участников диспута: на приципиальный, с моей точки зрения, момент разделения (насколько это окажется возможным) задач интеграции данных(приложений, сервисов) и управления безнес-процессами предприятия.На самом деле никакого принципиального разделения в этом плане не существует. Ну, разве что инструментарии, именуемые "интеграционными", могут быть более куцыми, более ограниченными, нежели BPMS, которая в своем составе кроме интеграционного сервера обязана иметь еще кое-что. Когда Вы интегрируете приложение1 с приложением2 напрямую с использованием COM или ODBC, вы так или иначе уже реализуете интерационные возможности, которые ограничены одним (или парой) интерфейсов. При этом Вы, возможно не отдавая себе в этом отчет, находитесь в весьма жестких рамках имеющейся функциональности этих двух приложений. Если ни в одном из этих приложений нет какой-то функциональности, которая требуется на промежуточных этапах при передаче информации от одного приложения к другому, то Вы будете вынуждены городить третье приложение и связывать его с двумя первыми, возможно, КРОМЕ того еще связав и первые два между собой. В случае, если схему их взаимодействия потребуется изменить, Вам придется всё нагороженное капитально перегораживать шиворот-навыворот. Если вдруг выяснится, что требуется еще какая-то функциональность, а три приложения тесно завязаны в текущей работе, то добавить ее туда так просто уже не получится.
MS BizTalk Server позиционировался раньше (когда в нем не было Orcestration) как интеграционный сервер, и продолжает позиционироваться так и сейчас. Его разработчики постепенно приходили к пониманию, что за пределами интеграционных механизмов все время что-то остается. То функциональность, ткоторая отсутствует в интегрируемых приложениях, то возможность подключения к механизмам интеграции "просто людей".
Что получилось в итоге? Интеграционный сервер развивался-развивался - и превратился в полноценную BPMS, которую можно использовать как для решения вопросов интеграции, так и в качестве инструментария для реализации принципов процессного управления. Ну так случайно получилось... :)
Вот только подходы для решения этих задач разного класса существенно разные. "Просто интеграция" не включает в себя реально работающего цикла Шухарта-Деминга. Бизнес-процессы могут быть настроены и IT-специалистом, с их помощью просто будет производиться дополнительная обработка информации за пределами интегрируемых приложений. "Просто интеграция" - это относительно жесткое решение.
Реализация процессного подхода требует отдачи BPMS непосредственно в руки "владельца бизнес-процесса", в руки менеджера, который сам обязан побеспокоиться об эфективной работе цикла Шухарта-Деминга. IT-специалист совать нос в бизнес-процессы не должен (по крайней мере, в такой стратегии это бы выглядело дико).
Вроде бы, один продукт, а заходить на него можно совершенно с разных позиций. Это нормально, потому как этот продукт - "пластилин". С его помощью можно замазать щели, а можно вылепить скульптуру. Нечему тут удивляться... :)


автор - BPMS, не обремененная обеспечением интеграционных задач, служит именно для отображения хода процессов....Ну, насчет "не обремененности" Вы явно погорячились. Не может быть приличной BPMS без подобной "обремененности".

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

процВедь напрямую всегда лучше, разве это не очевидно ?Не очевидно. Поговорите пожалуйста с испанцем, с жителем Эквадора, жителем Афганистана, армянским горцем - без переводчика, напрямую. Интересно посмотреть, как это у Вас получится.

...починяю примусЯ предлагаю бизнес-процесс вообще никак не привязывать к платежу. Неужели я настолько непонятно свот мысли излагаю ?То, о чем Вы говорите, касается "просто интеграции". Когда информация куда-то попадает отчасти путями, никак не соотносящимися с настройками бизнес-процесса. Когда нужно просто обеспечить транспортировку информации из пункта А в пункт Б, и BPMS используется как транспорт для такой доставки. Или НЕ используется, если информация может дотопать до пункта Б другой тропинкой. Только такое использование BPMS задействует его ТОЛЬКО как сервер интеграции, а не как BPMS. Если Вы намерены реализовать процессное управление, то Вы должны именно в BPMS нарисовать полную схему бизнес-процесса, не упустив никаких шевелений "за пределами". И управлять этой схемой, периодически ее модифицируя. Иначе все, что оказалось "за пределами" окажется также за пределами цикла Шухарта-Деминга.

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

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

...починяю примус GaryaКогда Вы интегрируете приложение1 с приложением2 напрямую с использованием COM или ODBC, вы так или иначе уже реализуете интерационные возможности, которые ограничены одним (или парой) интерфейсов.
О чем этот бред ? BizTalk использует для получения данных какие-то магические силы, принципиально отличающиеся по возможностям от методов доступных другим приложениям ?"Этот бред" о том, что BizTalk может "заставить" обратиться приложение1 к приложению2, хотя приложение1 само вообще ни к кому обращаться не умеет, поскольку все интерфейсы с ним - это ODBC-доступ к его данным, возможностей работы с COM в нем не предусмотрены. И тем не менее оно обращается! С помощью BizTalk, который сам лезет через этот самый ODBC в его данные, обнаруживает какую-то ситуацию, которая должна вызывать обращение к приложению2, и ЗА НЕГО лезет к приложению2 по интерфейсу COM, после чего помещает данные обратно через ODBC в БД приложения1. Если убрать BizTalk, то напрямую они взаимодействовать просто не смогут .

...починяю примусЕще раз - доказательства. Как только я начинаю говорить о реальных задачах и реальных объемах информации Вы уходите от обсуждения, объявляя что это "нетипичная ситуация".У Вас имеется не просто возможность интеграции чего-то с чем-то, но и возможность интеграции с ТЕМ, ЧЕГО НЕТ - С ТЕМ, ЧТО НАХОДИТСЯ "В ВОЗДУХЕ", а не в интегрируемых приложениях. Не всегда ведь стоит задача передать N записей из источника в приемник. Нужно еще по дороге принять 5 управляющих решений с участием человека. BizTalk интегрирует С ЧЕЛОВЕКАМИ, а не просто передает информацию из приложения1 в приложение2. Какие доказательства нужны и доказательства чего?

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

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

...починяю примусВы так и не привели ни одного обоснования для непременно совместного решения двух задач - интеграции данных/приложений внутри КИС и моделирования в реальном времени бизнес-процессов предприятия.А я и не утверждал, что они непременно должны обязательно выполняться совместно. Это Вы меня неправильо поняли. И чтобы доказать (уж очень Вы это слово любите :) ), приведу пару примеров:
1. BPMS как инструмент BPM без интеграции приложений. Приложений нет - интегрировать нечего. Есть просто InfoPath и BizTalk Server, с помощью которых отрабатываются все бизнес-процессы предприятия (судя по всему, это НЕ производственное предприятие :) ).
2. BPMS как сервер интеграции установлен на границе взаимодействия центрального офиса и нескольких филиалов, обеспечивает передачу информации в обе стороны с попаданием из всех источников во все приемники со всеми необходимыми преобразованиями форматов. А весь основной бизнес крутится, не будучи "нарисованным" в Orcestration.

процК вашему сведению: всю недостающую функциональность, все преобразования в BPMS надо программировать, по другому просто не бывает.Что такое "программировать"? Когда Вы в Excel вводите формулу "=2*2", то Вы "программируете"? Когда это делает кухарка, не знающая ни одного языка программирования, то она тоже нечаянно "программирует"?

...починяю примус- какой "видовой признак" переводит процесс из "локального" в "Enterprise" ?Решение им главной цели бизнеса.

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

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

...починяю примус - Никто из Вас (кажется) не отрицает, что моделирования бизнес-процессов предприятия есть длительный итерационный процесс; Что предприятию делать с интеграционными проблемами, пока бизнес-аналитики будут строить и отлаживать свои модели ? Ждать ?По не-русски это называется "реинжиниринг". Или "хирургия". Что делает пациент, когда его режут? Как правило, спит под наркозом. :)

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

...починяю примусгде взять таких терпеливых бизнес-аналитиков?Да, это действительно проблема... :) У нас очень много руководителей-творцов и слишком мало руководителей-ремеслеников.

...починяю примусКаким образом вы собираетесь эффективно организовать это совместное использование средством, не предусматривающим в принципе механизмов обработки информационных массивов, аналогичных имеющимся в СУБД ?Если BPMS может обращаться к СУБД, то почему она не может использовать ее механизмы?