能否将ERP、CRM及SCM同构到一个单一的数据库上，是十分需要重视的。因为有些商务环节，特别容易被忽视。比如作为CRM末端的“询报价”及“合同”环节，也正是ERP订单处理的前道环节。如果企业拥有孤立的CRM或ERP系统，那么一条从“市场活动－营销－磋商报价－合同－订单－发运－帐单－售后”的完整流程就会人为撕开，并且一方数据库的变化根本不能触发另一方同步变化。管理层看到的就永远只是客户关系的一个不完整部分，而非360°的理解。一样的道理，SCM作为协同商务管理部分也必然需要与ERP、CRM同构到一个数据库才能实现信息的同步化。
在 Oracle 体系结构中，当任一应用的用户实施了一项导致数据库更新的操作时，中央数据库的一个相关数据库表或数个相关数据库表中就会做出相应的更新；然后这些更新过的信息就立即提供给需要这些信息的其他应用。这一体系就是Oracle Trading Community Architecture (Oracle 交易社区构架)，它指令交易社区 (trading community) 中的每名成员提供统一的记录结构，这些成员包括客户、员工、供应商和商务合作伙伴。
在互不相关的应用拼凑在一起所产生的混合体系结构中，事情就没有这么简单。设想在此体系结构中，一名销售员使用ＣＲＭ营销应用输入数据，而这些数据将更新一张或多张销售数据表。但事情并未就此结束。例如，如果这些数据涉及到一名联系人，那么，混合体系将面临两难处境：它要么必须让相应的更新在所有包含联系人数据的其他数据表中生效，而不管这些数据表属于哪个应用（或许是ＥＲＰ），要么它就只能让那些数据表脱离同步，从而变得不可靠。
此外，设想某些此类数据表为每一名联系人记录了属性 A ——但另一些数据表无此记录。现在，系统必须知道哪些数据表需要更新。即使此类复杂性能够解决，当一些数据表已经被更新而另一些未被更新时，仍然存在一定的危险，因为这会使差异“溜”进公司数据中。即使这样的更新体系能够被完善，它也将需要一个消息中介器 (message broker)，中介器需要花费时间忙乱地来回传递、更新消息，并且，在此过程中，它还要优先占用宝贵的处理时间。而在类似 Oracle 的系统中，这些处理时间就可以用于其他目的。当然，从理论上讲，所有这些复杂性能够避免。然而，这样做的话，在系统能够开始工作之前，势必要付出很大一笔费用并导致长时间拖延。
我们认为一切局部的应用如ERP、CRM或SCM其实都因其管理对象一致而应被当作一个整体看待。Oracle将自己的所有应用同构到一个单一数据库上并称其为“电子商务应用套件“，其目的当然是让企业可以更容易地实现完整的商务流程。
来源： asiaec
