Совершенно перестал понимать, чему возражающие возражают (простите за тавтологию). Такое впечатление, что дискуссия идет с глухими и немыми.
Например, Проц:
"самое правильное, интегрировать БД разных подсистем, т.е собирать единую распределенную БД КИС, возможно на разных СУБД." - да кто же спорит. Это одно из опробованных направлений, хотя уже и не самое актуальное. А далее:
"В этом случае один БП может затрагивать транзакционно данные разных подсистем без файлового обмена, напрямую." - извините, уже натяжка. Если СУБД разные, то боюсь без файлового обмена не обойтись. Ведь форматы данных мы не ограничиваем, и как быть с .pdf, .gif, и пр."
А дальше: "И управлять такими БП проще." - почему это? Вот как раз управление и может быть от типа данных полностью отвязано (см.
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?)
Это еще не конец, далее: "Ну а мы уж как-нибудь уж по старинке через direct link, gateway и прочие ODBC (иногда и так приходится) - работать то надо не дожидаясь прихода вебсервисов " - ну зачем эти возражения, касающиеся используемых средств, если нет договоренности по сути БП? Это только запутывает читателей.

Кто-то хочет интегрироваться на основе единой БД - правильно ли это? Бесспорно! Перспективно ли? До определенного уровня интеграции, пока не начнем заглатывая хвост сжирать самих себя. Не ясно? Для непонятливых: Пока затраты на модернизацию ПО не превысят возможностей предприятия. Надеюсь все здесь знают, что производительность внесения изменений в 5-10 раз ниже, чем новых разработок. Особенно при нашей дисциплине создания документации.
Проц, какую документацию Вы оставляете будущим поколениям и какую навсегда оставляете себе, забывая о ней через 2-3 меесяца? С какой производительностью Вы вносите изменения?

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

Проц:
"Чем выше степень интеграции - тем проще строить БП и управлять ими т.к. меньше технологических ограничений. Например, при 1 БП вообще часто вырождаются в одноходовки, которыми и управлять не надо."
Есть два возражения: первое - от степени интеграции сложность БП мало зависит. Предположим, что все приложения, обеспечивающие информацией процессы закупок и поставок интегрированы в некий блок, обеспечивающий службы коммерческого директора, главных специалистов (гл. механика, технолога, энергетика, металлурга, строителя...), транспортное управление. Скажите проц, у Вас в этой интегрированной схеме есть механизм управляющий взаимодействием этих служб? Вы представляете себе, как они сейчас работают? Только не ссылайтесь на их функциональные обязанности, на любом совещании у генерального директора только и идет спор о том, кто и что должен был сделать в нестандартной ситуации и почему не сделал, и кого винить и наказывать, а кому поручить исправить положение, зафиксировав это в протоколе. А на следующем совещании начинается разбор, почему не выполнен протокол, и оказывается, что кому-то, чего-то не дописали и не заставили. И далее все повторяется сначала.
Спросите тех, кто бывал на таких разборках, тех кто внедряет ERP, я думаю Сахават или iscraft этого не опровергнут.
Второе - нет при этом одноходовок (хотя, что это такое я не знаю). При высоком уровне автоматизации учета (не жесткой интеграции) возможно автоматизировать последовательное исполнение нескольких элементарных БП (ввод приходной накладной -> учет ТМЦ на складе -> данные в бухгалтерию
-> исчисление НДС -> проводки по материальным счетам). Стоп, все это так работает, если мы использовали механизм стандартных проводок. А если нужно изменить проводку? Кто и как узнает, что проводка не стандартная? И узнав это, когда этот бухгалтер нижнего уровня выполнить проводку? А кто будет следить за тем, чтобы он это сделал немедленно? Примерно такие вопросы решают и такой контроль и осуществляют 70% управленцев, которых 30% от всего персонала промышленного предприятия.
Третье - жесткая интеграция зашитая в схемы стандартных в рамках продукта БП (SAP, OEBS). Уже наелись. Это предложения один раз изменить всю организацию управления (своего рода шоковая терапия) и что же дальше? Застывшая схема.
Ваше васказывание: "Правда, приходиться изменять программный код (а для этого его надо иметь). Но изменения в рамках уже сложившейся архитектуры все-таки проще чем новая разработка." - говорит о том, что Вы сами с трудов в это верите. Изменеия в ПО - это отдельный разговор, одно понятно - их трулоемкость и надежность не соответствуют вложенным средствам.

Мне таки здается, что понятие БП не у всех спорящих одинаково. Может все-таки возвратиться к вопросу определений и примеров. Откройте тему "БП - что это такое и зачем? Объяснения и примеры". Или нечто подобное. Вы увидите, насколько это будет полезно для многих.