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

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