企業全面信息化時代的到來--集成創造價值，集成產生智能(6)

　　 　　 能否將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將自己的所有應用同構到一個單一數據庫上并稱其為“電子商務應用套件“，其目的當然是讓企業可以更容易地實現完整的商務流程。