企業(yè)全面信息化時(shí)代的到來--集成創(chuàng)造價(jià)值，集成產(chǎn)生智能(6)

　　 　　 能否將ERP、CRM及SCM同構(gòu)到一個(gè)單一的數(shù)據(jù)庫(kù)上，是十分需要重視的。因?yàn)橛行┥虅?wù)環(huán)節(jié)，特別容易被忽視。比如作為CRM末端的“詢報(bào)價(jià)”及“合同”環(huán)節(jié)，也正是ERP訂單處理的前道環(huán)節(jié)。如果企業(yè)擁有孤立的CRM或ERP系統(tǒng)，那么一條從“市場(chǎng)活動(dòng)－營(yíng)銷－磋商報(bào)價(jià)－合同－訂單－發(fā)運(yùn)－帳單－售后”的完整流程就會(huì)人為撕開，并且一方數(shù)據(jù)庫(kù)的變化根本不能觸發(fā)另一方同步變化。管理層看到的就永遠(yuǎn)只是客戶關(guān)系的一個(gè)不完整部分，而非360°的理解。一樣的道理，SCM作為協(xié)同商務(wù)管理部分也必然需要與ERP、CRM同構(gòu)到一個(gè)數(shù)據(jù)庫(kù)才能實(shí)現(xiàn)信息的同步化。 　　 在 Oracle 體系結(jié)構(gòu)中，當(dāng)任一應(yīng)用的用戶實(shí)施了一項(xiàng)導(dǎo)致數(shù)據(jù)庫(kù)更新的操作時(shí)，中央數(shù)據(jù)庫(kù)的一個(gè)相關(guān)數(shù)據(jù)庫(kù)表或數(shù)個(gè)相關(guān)數(shù)據(jù)庫(kù)表中就會(huì)做出相應(yīng)的更新；然后這些更新過的信息就立即提供給需要這些信息的其他應(yīng)用。這一體系就是Oracle Trading Community Architecture (Oracle 交易社區(qū)構(gòu)架)，它指令交易社區(qū) (trading community) 中的每名成員提供統(tǒng)一的記錄結(jié)構(gòu)，這些成員包括客戶、員工、供應(yīng)商和商務(wù)合作伙伴。 　　 在互不相關(guān)的應(yīng)用拼湊在一起所產(chǎn)生的混合體系結(jié)構(gòu)中，事情就沒有這么簡(jiǎn)單。設(shè)想在此體系結(jié)構(gòu)中，一名銷售員使用ＣＲＭ營(yíng)銷應(yīng)用輸入數(shù)據(jù)，而這些數(shù)據(jù)將更新一張或多張銷售數(shù)據(jù)表。但事情并未就此結(jié)束。例如，如果這些數(shù)據(jù)涉及到一名聯(lián)系人，那么，混合體系將面臨兩難處境：它要么必須讓相應(yīng)的更新在所有包含聯(lián)系人數(shù)據(jù)的其他數(shù)據(jù)表中生效，而不管這些數(shù)據(jù)表屬于哪個(gè)應(yīng)用（或許是ＥＲＰ），要么它就只能讓那些數(shù)據(jù)表脫離同步，從而變得不可靠。 　　 此外，設(shè)想某些此類數(shù)據(jù)表為每一名聯(lián)系人記錄了屬性 A ——但另一些數(shù)據(jù)表無此記錄。現(xiàn)在，系統(tǒng)必須知道哪些數(shù)據(jù)表需要更新。即使此類復(fù)雜性能夠解決，當(dāng)一些數(shù)據(jù)表已經(jīng)被更新而另一些未被更新時(shí)，仍然存在一定的危險(xiǎn)，因?yàn)檫@會(huì)使差異“溜”進(jìn)公司數(shù)據(jù)中。即使這樣的更新體系能夠被完善，它也將需要一個(gè)消息中介器 (message broker)，中介器需要花費(fèi)時(shí)間忙亂地來回傳遞、更新消息，并且，在此過程中，它還要優(yōu)先占用寶貴的處理時(shí)間。而在類似 Oracle 的系統(tǒng)中，這些處理時(shí)間就可以用于其他目的。當(dāng)然，從理論上講，所有這些復(fù)雜性能夠避免。然而，這樣做的話，在系統(tǒng)能夠開始工作之前，勢(shì)必要付出很大一筆費(fèi)用并導(dǎo)致長(zhǎng)時(shí)間拖延。 　　 我們認(rèn)為一切局部的應(yīng)用如ERP、CRM或SCM其實(shí)都因其管理對(duì)象一致而應(yīng)被當(dāng)作一個(gè)整體看待。Oracle將自己的所有應(yīng)用同構(gòu)到一個(gè)單一數(shù)據(jù)庫(kù)上并稱其為“電子商務(wù)應(yīng)用套件“，其目的當(dāng)然是讓企業(yè)可以更容易地實(shí)現(xiàn)完整的商務(wù)流程。