
我們在這里討論的技術架構,更多的是強調系統架構而非技術和網絡的實現架構。當然,基于技術和網絡的因素,技術架構模式對于應用部署的影響很重要。目前的CRM系統技術架構模式大體分為:C/S、B/S、R/S、ASP(OnDemand)等四種主流模式。
C/S:客戶端/服務器模式,又可以細分為二層C/S、多層C/S、瘦客戶端等,適用于局域網或者網絡速度與質量俱佳的廣域網,互動性較好,與系統應用結合較緊密,系統的安全性和可靠性較強。
B/S:瀏覽器/服務器,也可以細分為單層、多層架構的B/S等,適應于因特網上的應用,集團內部網也有良好的表現,適合遠程登陸、異地辦公、客戶現場展示等,同時部署簡便,維護工作量較少。
R/S:可以歸類于C/S與B/S之間。技術性質是C/S的,但是離線操作,也可以通過網絡連接進行實時同步,實現了B/S的遠程登陸、異地辦公、客戶現場展示等,還有B/S沒有的離線操作的功能,這對于隨時在外拜訪客戶而且國內網絡普及不理想的情況下最有效的方式之一。
ASP(OnDemand):國外應用已經越來越成熟,但是國內因先天的信用機制不健全而對這種軟件租賃的模式不是很感興趣,尤其是ASP的Host(主機)安置在遙遠的國外。Siebel最近推出的OnDemand類似于ASP模式但又有不同,不同之處就是支持企業在本地設立Host,這樣數據安全性、備份可靠性和歸屬感就有保障了。
技術架構
基于不同的技術部署架構,采用的技術也是各自不一我們不妨線簡單來看一下CRM系統所涉及的部分技術,簡述如下:
面向對象:不僅僅從技術層面,還要從業務層面體現OO的思想。
UML的應用:普遍用來描述業務對象,流程,實體,ERD等,也有系統有自己的業務模型設計工具,比如SAP的Business Engineer。
平臺:國外大部分先做平臺,后做應用。一般國外的CRM平臺都是解釋性語言平臺,有自己的語法解釋器和函數庫等,實現業務源碼開放和靈活定制。
業務對象(BO):從業務架構移植的時候,業務對象、實體、類等在業務分析、技術研發、應用集成等領域反復應用。
業務流程(BF):包括工作流、序列圖、柔性可配置流程等技術,還貫徹著業務對象、語義定義等功能。
業務角色(BR):業務角度、用戶等,通過用例角色來融合近業務藍圖。其權限、流程觸發、任務分配等等,涉及很精密的計算。
CS實現模式:組件化、編碼封裝、中間件等技術使CRM系統實現平臺化。
BS實現模式:web中間件、模板、語法標簽、業務對象定義、功能函數、XML、DHTML等技術是基于瀏覽器模式的CRM系統的靈活性和互動性有了很大提高。
消息系統:消息傳遞、接口通信、數據傳遞等都需要一個強大的消息系統。
隊列機制:無論是內部的流程隊列還是客戶服務、電話外撥的隊列處理,都是體現客戶價值或者客戶優先級的隊列引擎。
自動腳本:在呼入(inbound)和呼出(outbound)的時候,標準化、規范化和智能化的自動腳本將提高業務效率和客戶滿意度,并有效降低培訓成本。
從理論上講,國外軟件系統如Siebel能夠實現的技術架構國內廠商也能實現,但是業務架構的差距直接拉大了國內與國外CRM的距離,所謂追求技術先進性并不是最好的,只有業務領先才可能吸引更多的企業用戶。國內CRM軟件廠商要把精力放在認真研究國內企業用戶的需求和趨勢,建立起具有本地特色的有本土領先優勢的業務架構和業務模型;而不是去強調Java開發的純B/S模式的領先技術的“唯技術論”。
如果我們再仔細研究Siebel的數十個跨行業最佳實踐方案和行業最佳實踐方案,以及經過無數個世界五百強企業實踐過的最佳流程等,我們會發現在業務上國內CRM廠商已經落后很多,目前國內廠商只有TurboCRM有自己的咨詢模式庫,但也僅僅只是有,其規模和深度還遠遠不及Siebel。
對于國內企業用戶而言,適應帶有中國特色的業務需求的CRM才是最好的。這才是國內CRM系統的真正訴求點!
(c113)
CIO頻道人物視窗
CIO頻道方案案例庫
大數據建設方案案例庫
電子政務建設方案案例庫
互聯集成系統構建方案案例庫
商務智能建設方案案例庫
系統集成類軟件信息研發企業名錄