Цитата:
Сообщение от
Pavel
В итоге имеем заказную разработку, уникальную систему и жизненный цикл решения, привязанный исключительно к Васе (упаси Господь 'снег в башка попадет'). Под одним названием (типа, решение для...) на самом деле будут скрываться разные сущности. PS. или я что-то упустил, или это новый тренд, типа... 'антиотраслевые решения' или 'бизнес-процессы не помешают вашему бизнесу'.
Георгий, прости за небольшой стеб, настроение уже праздничное
Да так обычно и происходит, к сожалению. Я же специально вставил слово "правильно разработать". Кода ядро выполняет основные функции, а код его гармонично дополняет, следуя логике системы.
Смотри, на примере Oracle - им пришлось OEBS на кусочки разобрать, переносить все на интергационную шину Oracle Fusion Middleware, через которую, например, CRM общается с закупками.
Или SAP - и так перегруженный, но архитекторам хватило ума не пихать туда еще Demand Planning / EWM (WMS) / SNP и тд.
Сделали отдельный модуль - SAP SCM APO, в нем куча дополнительной функциональности. Но как она работает? На примере EWM - она берет основные настройки из SAP (номенклатура / вес / габариты), все остальные настройки, характерны для WMS - карта склада, ячейки, маршруты комплектации - все хранится в отдельной системе. Из SAP приходит заказ на отгрузку, WMS дает задание на подбор и комплектацию заказа и обратно присылает статус - все отгружено. Модуль действует автономно, интеграция - через CIF (Core Infrastructure Framework). Гениально.
То же самое многие делали к DAX - использовали как основные справочники и механизмы разноски, и дополняли функциональностью. Вот про что я говорил. Тогда и обновления накатывать можно, и функциональность можно безболезненно наращивать, и доработки отчуждать. И в "партнерские решения 1С" не превращать, когда берется 1С Бухгалтерия и на этой платформе пишется черт те чё, превращая ее в просто в самопал, который к бухгалтерии имеет столько же отношения как морская свинка к морю.
С Уважением,
Георгий