
如果在CRM設計中就充分考慮到了哪些數據需要不斷和ERP進行同步更新,上述麻煩就會大大減少。這也是為什么像Siebel這樣的行業領先的前端辦公軟件開始提供與SAPR/33.1以上版本的ERP進行完全兼容的中間軟件(middle ware)。
在這個名為Siebel Enterprise Connector的中間軟件中,這種整合通過兩個方法來實現。一是通過中間文件(Intermediate Document IDoc)實現的整合,它可以把SAP中的基本信息輸入到Siebel中,其中IDocs接收器接收從SAP服務器中存儲的關于客戶戶口、聯系人、產品和價格等信息,然后把這些信息存入IDocs界面中,這個界面是Siebel的整合管理(Enterprise Integration Manager,EIM)的一部分,于是這些信息就可以完全傳入到Siebel中。這樣的整合不僅在CRM最初啟動的時候可以用來進行數據轉化,而且在ERP和CRM的同步運行中還能不斷地把最新調整的產品目錄、價格和折扣等信息輸入到前端軟件中,讓銷售人員可以及時地給出正確的報價。
第二種整合是通過BAPI進行的即時數據支持。在這種整合中,Siebel運用SAP提供的即時界面,包括BAPI(Business API)和遠程功能呼叫RFC界面(Remote Function Call)組合成即時整合管理器,通過它可以把同一時間在Siebel中生成的定單立即傳輸到SAP中。如果在SAP中運行SAP BAPI處理器,還可以完成同期的多個請求的并行處理。
如果前端軟件和后端軟件需要進行如此精細的整合,而市場上提供的中間軟件又不能完全滿足需要的話,那么以Oracle為代表的ERP提供商們則是在它們原有的ERP客戶基礎上努力推動CRM的發展。與Siebel不同,Oracle CRM并不需要另外增設服務器,而是在原有的Oracle ERP服務器上增設一個或多個CRM模塊。像定單號碼這樣的數據,Oracle的CRM可以直接到ERP的定單管理模塊(Order Management)中取得而不需要麻煩的轉接或同步更新的程序。對于已經運用了Oracle ERP的客戶來說,這一優勢無疑是其他CRM提供商所不具備的。
無論通過中間軟件還是在原有基礎上增設模塊,只要企業內部的前后端整合可以無縫進行,實現網絡化的定單輸入和報價也就容易多了。因為這只相當于原來對銷售人員開放的前端軟件延伸到了網絡上而已。企業的現存或潛在客戶只要能夠從網絡界面上獲得如下信息:產品目錄、單價、折扣率和庫存信息之后,就可以決定是否下定單。而客戶從網絡上輸入的定單正如銷售人員輸入的定單一樣,這些信息可以立刻傳輸到后臺ERP,后臺ERP在接受之后經過計算,把定單總價、定單號碼和折扣金額等信息再傳回到網絡界面上,客戶記錄下這些信息,就可以隨時通過呼叫中心,或與銷售人員聯系,繼續追蹤這筆定單。
現在,國內的網絡公司多數可以提供的僅僅是建立"電子小冊子"式的網頁,因而在談到實現即時互動的雙向數據流的時候就會心存顧忌。這不難理解。網絡公司通常是憑借網絡概念和基礎的html語言、java語言建立的,要實現與ERP的聯合,還要求他們必須了解后臺數據庫的設計和安裝。而每個行業,每個企業的后臺數據庫都有著自身的復雜性和規范,一個航空公司的信息系統和一個銀行的信息系統就可能大相徑庭。可以把個人網頁做得很漂亮的技術人員,不一定能夠把一個銀行的所有客戶余額查詢實現網絡化。網絡經濟的所有后臺支撐點在于大規模的數據整合,在這個基礎上,經過"網絡化"的改造,"傳統"企業因為本身已經具備大規模物流、生產線和客戶服務的"水泥"設施,將比那些完全依靠"虛擬經濟"生存的"純網絡公司"具有更強大的競爭實力。當企業對網絡的理解突破了"電子小冊子"的階段,能夠主動把單個客戶的需求與每一筆定單的完成相對應的"傳統"企業,完全可以提供更快、更全面和更個人化的產品與服務。無論這種整合是否需要讓企業經歷諸如ERP安裝那樣"脫胎換骨"的痛苦過程,只有進行了改造的企業資源數據庫才可以為下一步的行業垂直整合和跨行業數據交換作好準備。如果我們把網絡經濟從單純的"上市"這個短期目標中推遠一些,我們就會發現,"新經濟"實際上是在數據快速交流的基礎上創建一個完全圍繞顧客需求的精細的社會資源交換體系.
CIO頻道人物視窗
CIO頻道方案案例庫
大數據建設方案案例庫
電子政務建設方案案例庫
互聯集成系統構建方案案例庫
商務智能建設方案案例庫
系統集成類軟件信息研發企業名錄