- 相關推薦
全球頂級CRM產(chǎn)品的“技術架構”揭密
我們將創(chuàng)建一個結構化方法來協(xié)助你評估和對比分析應用軟件。我們將對以下五種世界著名的CRM軟件廠商的產(chǎn)品進行深入的細化分析，它們按字母順序排列如下： ● E.piphany E.6
● Oracle E-Business Suite 11i
● PeopleSoft 8
● mySAP CRM 3.0
● Siebel 7
一、研究意義和研究方法
（一）CRM技術架構是決定客戶體驗的最重要因素
在2001年底，我們就開始了一項對CRM技術架構的研究。我們感覺此項目具有非常重要的價值，因為客戶在實施CRM應用系統(tǒng)時將直接面對軟件的技術架構。而且，軟件技術架構的實用性、直覺性、功能性、可測量性和可管理性將直接決定企業(yè)客戶對產(chǎn)品的體驗，因此CRM技術架構將決定CRM產(chǎn)品如何簡易的定制到你的特定的業(yè)務需求中。而且CRM技術架構也是決定CRM應用軟件能夠與為客戶提供重要信息的后臺系統(tǒng)進行集成的關鍵因素。
�。ǘ┙Y構化的評估和對比
此次研究開始于一個評估體系的開發(fā)，該體系的建立首先需要我們建立一套評估單個產(chǎn)品和對比多種產(chǎn)品的標準。該標準將決定我們后面的工作開展。
我們曾經(jīng)使用過這種方法來評價和對比許多類型的產(chǎn)品，例如局域網(wǎng)管理工具、C/S應用軟件開發(fā)工具、目標數(shù)據(jù)庫管理系統(tǒng)等。這種結構化方法已經(jīng)被我們證實是非常有效的。尤其當被評價的軟件/工具對企業(yè)至關重要，而且企業(yè)需要從難以區(qū)分的眾多產(chǎn)品中進行選擇的時候，這種方法就顯得更加有效。
（三）五家CRM供應商的選擇
一旦我們的體系建立好，我們就可以開始進行技術架構的評估了。到目前為止，我們已經(jīng)評估了全球頂級的五種產(chǎn)品（上文所提到的五種產(chǎn)品）的技術架構的評估結果。
至于我們?yōu)槭裁催x擇這五個軟件廠商的產(chǎn)品，是因為這五家廠商，無論是在客戶的數(shù)量、市場的影響力，還是公司的規(guī)模上，都是世界上數(shù)一數(shù)二的CRM供應商。另外，這些供應商的產(chǎn)品套件都包括營銷、銷售和服務功能模塊。
�。ㄋ模┏掷m(xù)研究
我們的研究不會隨著這次報告的產(chǎn)生而結束。還有其他廠商的產(chǎn)品結構也非常值得我們去研究，例如Kana、Onyx和Pivotal，它們在CRM領域也取得了相當大的成功。而且微軟也快要加入 “CRM圈”。因此我們的工作遠沒有結束，我們將持續(xù)研究下去。
二、研究內容和研究結果
這份報告的核心將圍繞我們的評估體系。對于每一種產(chǎn)品的技術架構，我們都將圍繞以下6大標準來評估： 環(huán)境、 組織、基礎結構、結構、客戶化、集成性。
對于每一個評估標準，我們將簡要的描繪相應的標準，并根據(jù)評估標準來對比各種技術架構的優(yōu)勢和劣勢，然后給出一定的排名。
�。ㄒ唬┉h(huán)境
環(huán)境是企業(yè)在選擇軟件的過程中最簡單的技術架構的評估標準，而且是最容易區(qū)分的。最重要的環(huán)境就是CRM產(chǎn)品所支持的服務器平臺和數(shù)據(jù)庫。在你選擇CRM產(chǎn)品時，最好不要改變你現(xiàn)有的服務器平臺和數(shù)據(jù)庫標準，否則你將會增加很多投資。因此一個CRM產(chǎn)品最好要支持你的企業(yè)原有環(huán)境。下表列出了那5家產(chǎn)品的技術架構的環(huán)境。
�。�1）“必須的”環(huán)境
有些環(huán)境是軟件所必須要支持的。技術架構必須要支持Microsoft NT/2000、Sun Solaris服務器平臺、IBM DB2、Microsoft SQL Server和Oracle Server管理系統(tǒng)。這些都是世界領先的系統(tǒng)環(huán)境，而且也是企業(yè)最可能要使用到的系統(tǒng)。因此如果產(chǎn)品不能支持這些環(huán)境顯然會產(chǎn)生很大的局限性。從上表我們可以看出，除了Oracle外都能夠支持這些“必須的“環(huán)境。（因為Oracle必須要支持自己的數(shù)據(jù)庫。）
�。�2）“必備的”環(huán)境
當我們認為支持領先的環(huán)境是“必須的”時候，支持第二層環(huán)境則是“必備的”。第二層環(huán)境例如：HP-UX 和IBM AIX服務器平臺、IBM和Sybase服務器管理系統(tǒng)。通過對比第二層環(huán)境，我們可以看出誰具備更廣的安裝環(huán)境。從上表我們可以看出，除了Oracle外都能夠支持一些“必備的”環(huán)境。Siebel和E.piphany支持“必備的”環(huán)境相對較少，而SAP最廣。
�。�3）“環(huán)境”比較結果排名
�、� mySAP CRM 3.0。mySAP CRM 3.0支持“必須的”環(huán)境，并且能夠支持“必備的”環(huán)境的范圍最廣。
② PeopleSoft Internet Architecture. PeopleSoft Internet Architecture支持“必須的”環(huán)境，并且能夠支持“必備的”環(huán)境的范圍比較廣。
�、� Siebel 7. Siebel 7支持“必須的”環(huán)境，并且能夠支持一些“必備的”環(huán)境。
�、� E.piphany E.6. E.piphany E.6支持“必須的”環(huán)境，并且能夠支持部分“必備的”環(huán)境。
�、� Oracle E-Business Suite 11i.由于Oracle公司自身擁有功能強大的數(shù)據(jù)庫，因此它主要 支持自己的數(shù)據(jù)庫環(huán)境。
（二）組織
產(chǎn)品的“組織”主要用來反映各組分的配置方式，以及組分間接口和通信協(xié)議。它也是描繪技術架構的標準之一。企業(yè)通過調查產(chǎn)品組分的數(shù)量、類型，以及組分間的通信協(xié)議，就可以獲得一個對產(chǎn)品實用性、可測量性和可控性的總體認識。
我們所評估的五種技術架構都執(zhí)行三層Web應用。在它們的三層組織中都包括以下類型的組分：
● 客戶端
● 應用服務器
● 數(shù)據(jù)庫
根據(jù)以上組分對比五種產(chǎn)品的組織難以看出差異性，但是我們如果將組分進行細化，也是能夠找到許多不同點的。
在客戶端的組織中存在一些不同點。支持無線和移動客戶端這方面就有很大的不同點。例如，E.piphany E.6、Oracle E-Business Suite 11i和Siebel 7在移動客戶端執(zhí)行的是統(tǒng)一用戶Web服務器界面。這是一種很好的思想，可以確保你的客戶和你的呼叫中心客服人員、銷售人員和現(xiàn)場服務人員擁有統(tǒng)一的用戶界面。而其他兩種產(chǎn)品技術架構，PeopleSoft Internet Architecture和mySAP.com執(zhí)行的則是不同于Web用戶界面的“桌面多用戶界面”。這種界面的優(yōu)勢在于豐富性和交互性。它們的缺點在于用戶界面容易出現(xiàn)不協(xié)
調。
與其他軟件相比，Oracle E-Business Suite 11i在應用服務器上有很大的不同。各種軟件的數(shù)據(jù)庫方面的差異性表現(xiàn)在：軟件訪問和共享外部數(shù)據(jù)的能力存在很大的不同。E.piphany E.6和Siebel 7在訪問外部數(shù)據(jù)的能力方面顯著強于其他軟件。而且企業(yè)可以通過配置不同的選項來確定外部的數(shù)據(jù)源。這是一種比較靈活的方式。
“組織”比較結果排名
根據(jù)上面所描述的差異性，以及其他一些因素，我們根據(jù)“組織”這個要素將廠商排名如下：
① E.piphany E.6和Siebel 7. E.piphany E.6和Siebel 7擁有最好的組織。在各種類型的客戶端擁有統(tǒng)一的用戶界面。
�、� PeopleSoft Internet Architecture和mySAP CRM 3.0.這兩種技術架構在客戶端都缺乏統(tǒng)一的用戶界面。相對E.piphany E.6和Siebel 7而言，存在一定的劣勢。
�、� Oracle E-Business Suite 11i. 擁有統(tǒng)一的用戶界面的優(yōu)勢，但是它只兼容Oracle Forms技術，并且它需要使用Java 和PL/SQL，導致了產(chǎn)品的“組織”相對比較復雜。
�。ㄈ┗A結構
基礎結構用來為多個用戶和共享的資源系統(tǒng)（例如CRM應用系統(tǒng)）提供系統(tǒng)級、獨立應用的中間層服務。服務包括基本的請求處理、隊列排序、流程管理、記憶管理、數(shù)據(jù)庫管理和事務管理等。所有服務都需要CRM和其他應用軟件的正確運作來實現(xiàn)。
Portals是近來在基礎結構中開發(fā)的一種形式。Portals用來提供附加的應用服務器，用戶通過這種應用服務器可以訪問更大范圍的應用軟件和數(shù)據(jù)。這對于CRM系統(tǒng)而言是一個很重要的優(yōu)勢，因為用戶可以在某一個環(huán)境下，訪問多個CRM應用系統(tǒng)，看到多種報表，或者在不同維度上來檢查企業(yè)的業(yè)績。Portals在用戶界面層級上提供應用系統(tǒng)和數(shù)據(jù)的集成。所有的CRM套件供應商和電子商務供應商都會提供基于用戶界面的Portals。
“基礎結構”比較結果排名
在基礎結構方面，這五家軟件廠商存在很大的差異性。差異性并不是表現(xiàn)在基礎結構所提供的服務上，而是表現(xiàn)在基礎結構自身被執(zhí)行的方式上。執(zhí)行方式的不同是由于讓傳統(tǒng)的技術適應Web而造成的。
而適應的方法存在很大的不同，并且都是基于特定的技術。E.piphany E.6是最新的技術架構，它的傳統(tǒng)技術最早只能追溯到20世紀90年代末期，而Siebel 7追溯到20世紀90年代早期；Oracle E-Business Suite 11i和PeopleSoft Internet architecture所用的傳統(tǒng)技術都可追溯到20世紀80年代末期；mySAP可追溯到20世紀70年代中期。另外，由于專有技術的不同特征導致了一些差異性。因為這種技術差別非常大，因此我們不能以對比“環(huán)境”和“組織”的方式來對比“基礎結構”。我們將獨立討論每一種CRM產(chǎn)品的基礎結構。以下是我們研究的排名結果，以及相應的詳細解釋。
�、� E.piphany E.6
E.piphany E.6在“基礎結構”方面排在第一位。
E.piphany在E.6的技術架構上投入了大量的研發(fā)資金，以集成不同的內部開發(fā)的應用軟件，并確保在Java技術上部署軟件，然后在J2EE基礎結構上配置它們。這種基礎結構不帶有任何專有的成分，并且沒有使用傳統(tǒng)的技術。E.6是我們所評估的五種產(chǎn)品中具有最清晰的基礎結構。
E.piphany E.6在一個標準的J2EE Web應用服務器（或者是BEA WebLogic產(chǎn)品，或者是IBM WebSphere產(chǎn)品）上部署。該技術架構沒有客戶端基礎結構，也沒有一個Portals。但是我們可以通過任何支持Java Server Pages、E.6客戶端結構的Portals訪問E.6應用軟件。
在E.6中的數(shù)據(jù)訪問是通過一個基于元數(shù)據(jù)的企業(yè)信息目標（BIOs）抽象層來實現(xiàn)。BIOs用來實現(xiàn)對多種類型的多種數(shù)據(jù)源的管理。而能夠集成多種類型的多種數(shù)據(jù)源是一個非常重要的優(yōu)勢。集成通過元數(shù)據(jù)可以非常容易而靈活地實現(xiàn)。
② PeopleSoft Internet Architecture
PeopleSoft Internet Architecture (PIA)基礎結構可以很好的兼容PeopleSoft的技術。這是一個源于BEA系統(tǒng)的商業(yè)基礎結構，它包括面向Internet的PeopleSoft的C/C++應用技術。一個J2EE Web應用服務器為PeopleSoft 8基礎結構提供了處理表示層的能力。PeopleSoft 8應用系統(tǒng)的傳統(tǒng)技術和C/C++程序邏輯都是在BEA Tuxedo上部署。
在很多方面，PeopleSoft比較幸運。BEA產(chǎn)品完成了兼容PeopleSoft傳統(tǒng)技術的工作。當PeopleSoft起初在Tuxedo基礎結構上實施時，Internet和J2EE并不在技術規(guī)劃范疇內。令PeopleSoft感到欣慰的是，Tuxedo是一種商業(yè)基礎結構。在Tuxedo上要比在專有基礎結構上（很多競爭對手所使用的方法）部署軟件更理想。BEA處于基礎結構業(yè)務領域。當然，為了保持競爭力，它的產(chǎn)品必須變革需求，吸納新技術。
PeopleSoft 8 Portal是PIA基礎結構的中間層部分。所有的PeopleSoft 8應用軟件，與外部的應用系統(tǒng)和信息系統(tǒng)一樣，都能夠通過標準的Portals被訪問。它支持HTML、WML和XML的請求，并使用BEA JOLT的工具把它們安排到相應的PeopleSoft 8應用軟件中。PeopleSoft Internet Architecture客戶端應當遵守J2EE標準。
在PIA上的數(shù)據(jù)訪問可以通過一個統(tǒng)一的、集中化的稱之為SQL Access Manager的組分來實現(xiàn)。它使用本地的RDBMS 的SQL Dialect來存儲PeopleSoft 8的數(shù)據(jù)。
③ mySAP CRM 3.0
mySAP CRM的基礎結構含有商業(yè)和專有的成分。新的Web應用服務器既兼容SAP的傳統(tǒng)ABAP技術，也支持J2EE應用軟件，并可以共享這兩者間的資源。遺憾的是，這個基礎結構的專有成分是一種新成分。
mySAP CRM包括使用SAP的傳統(tǒng)ABAP技術建立起來的應用軟件，也包括使用最新的現(xiàn)代Internet技術建立起來的應用軟件。因此，整個套件在一個混合技術的基礎結構的基礎上進行部署。在2002年6月，SAP推出了
它自己的Web應用服務器，稱之為SAP Application Server，并在提供共享的、集成的后臺資源訪問的同時，支持ABAP和J2EE應用軟件。我們認為，兼容SAP傳統(tǒng)的技術，并能夠集成Java 應用和ABAP應用是一件偉大的事情。
帶有ABAP和Java特性的SAP Application Server改變了mySAP.com的基礎結構。對于CRM，中間層的基礎結構讓ABAP SAP客戶交互中心能夠更加有效的與Java SAP Internet Sales共存。從一個更廣的角度來看，在部署mySAP.com應用軟件時實施Java應用套件變的更加容易。
mySAP.com基礎結構的中間層包含獨立客戶端的基礎結構。這種基礎結構稱之為Web Dynpro。Web Dynpro是SAP Application Server的一個組分，用來提供一個開發(fā)環(huán)境，并服務于mySAP.com Web應用的表示層。Web Dynpro是一種新技術，設計來作為Java Server Page表示層模型之上的附加層，以改進產(chǎn)品的實用性和性能。
�、� Siebel 7
Siebel 7基礎結構包括中間層應用服務器和客戶端的成分。所有的成分都是專有的。Siebel的基礎結構是它的技術架構的重要缺陷。
在中間層，Siebel 7在Siebel Server上部署。使用C++，Siebel Server有利于服務于下層服務器平臺，但是沒有能夠使用J2EE或.NET的工具。
Siebel 7用戶界面可以通過Siebel Portal Framework來實現(xiàn)。這個Portals提供一種性能，來滿足我們在Portals處所期望實現(xiàn)的單一簽名、驗證、定期交叉的需求，還可以基于瀏覽器來集成運營型和分析型應用軟件。如果你已經(jīng)實施了一個Portals，你將能夠通過Siebel XML Web界面來訪問Siebel應用軟件和數(shù)據(jù)。那是一種優(yōu)勢。但是當有更多的交互式SmartWeb用戶界面時，這不是一個統(tǒng)一的用戶界面。那又是一種劣勢。用戶訪問Siebel 7應用系統(tǒng)（不是通過一個Portals）是通過客戶端的基礎結構來實現(xiàn)的。
數(shù)據(jù)庫訪問是通過Siebel Database Manager（Siebel Server的組分之一）來實施的。Siebel Database Manager使用數(shù)據(jù)庫產(chǎn)品的SQL語言來執(zhí)行數(shù)據(jù)庫，完成訪問。使用這種基礎結構，外部的數(shù)據(jù)庫也能夠從Siebel 7應用軟件上得到訪問。
�、� Oracle E-Business Suite 11i
Oracle E-Business Suite（EBS）基礎結構包括Internet標準和公司的傳統(tǒng)技術。在客戶端、應用服務器，以及數(shù)據(jù)庫中都有基礎結構成分�？蛻舳撕蛿�(shù)據(jù)庫成分是專有的。
EBS 11i在J2EE和Oracle Forms、PL/SQL的混合成分的基礎結構上部署。它的程序邏輯為：客戶端以applets形式，應用服務器端以Java形式，而在數(shù)據(jù)庫中使用觸發(fā)和存儲程序。因此在客戶端、應用服務器端和數(shù)據(jù)庫中都有基礎結構。而這種結構的最大缺點在于：使得EBS的客戶化、集成、實施和管理變的非常復雜而艱難。
不過，我們已經(jīng)發(fā)現(xiàn)，Oracle的基礎結構正在處于變化之中。在最近的產(chǎn)品版本中，公司聲稱只有25%的CRM應用系統(tǒng)是采用的傳統(tǒng)技術，并且所有新的開發(fā)都是基于Java和J2EE的。EBS 11i的用戶界面能夠通過Oracle9iAS Portal來實現(xiàn)。Oracle9iAS Portal能夠具備大多數(shù)Portal所具有的能力：Portals用戶界面開發(fā)、應用軟件的集成、報表、安全性和個性化等。
我們這里所講的結構是指，CRM產(chǎn)品組織中的主要內部成分是什么，以及它們如何被建立，由什么組成。典型的CRM產(chǎn)品主要是三層基于Web的組織，因此我們使用三種類型的成分來定義和描繪它們的結構：
● 網(wǎng)頁/表示層
● 程序邏輯（用于應用軟件功能和應用服務功能）
● 數(shù)據(jù)模型
知道一個產(chǎn)品的結構，有助于你實施、定制、支持和維護產(chǎn)品，以及CRM與其他應用系統(tǒng)的集成。當一個產(chǎn)品的網(wǎng)頁、程序邏輯和數(shù)據(jù)模型建立在標準的、大眾化的技術上時，你的工作會簡單很多。
對比“結構”
對比我們所要評估的五種技術架構的“結構”，我們發(fā)現(xiàn)兩個相似點和許多不同點。
所有相似處都表現(xiàn)在數(shù)據(jù)結構方面：整體數(shù)據(jù)模型和客戶數(shù)據(jù)模型�？傊�，所有的技術架構都已經(jīng)預先定義好，并且靈活的數(shù)據(jù)模型代表了所有的關鍵CRM業(yè)務實體。對于客戶數(shù)據(jù)模型，所有的技術架構都擁有豐富的、開放的和一致的客戶數(shù)據(jù)。所有類型的客戶和所有類型的客戶關系都能夠表示出來。除了Siebel 7限制了客戶化范圍外，客戶數(shù)據(jù)在所有的技術結構中都具有靈活性。因此，我們不能在客戶數(shù)據(jù)的基礎上對軟件產(chǎn)品的技術架構進行排名。
差異性主要出現(xiàn)在其他的評估尺度中：元數(shù)據(jù)、網(wǎng)頁、程序邏輯和Web服務。許多不同點是由于傳統(tǒng)的專有技術引起的。通常情況下，兼容傳統(tǒng)的技術容易導致專有結構。在下面的內容中，我們將在各種尺度上分別討論產(chǎn)品的優(yōu)越性、差異性。
�。�1）元數(shù)據(jù)
E.piphany E.6、PeopleSoft Internet Architecture和Siebel 7是完全基于元數(shù)據(jù)的。從這一點而言，這三種產(chǎn)品要比其他兩種產(chǎn)品更具有優(yōu)越性。
Oracle EBS 11i和mySAP.com產(chǎn)品的只有某些方面是基于元數(shù)據(jù)的。因此它們不能完全獲得元數(shù)據(jù)在品質、客戶化和實施中所具有的優(yōu)勢。
�。�2）網(wǎng)頁
E.piphany E.6和PeopleSoft 8 擁有由HTML和javascript（作為JSPs來執(zhí)行）建立起來的網(wǎng)頁。JSP標準的使用讓網(wǎng)頁結構比其他產(chǎn)品更具有優(yōu)勢。
Oracle EBS 11中的大多數(shù)網(wǎng)頁也是由HTML和javascript建立起來的；但是它兼容傳統(tǒng)的技術，基于表單的網(wǎng)頁是通過applets來實現(xiàn)的。EBS的網(wǎng)頁也將基于JSPs。但是，Oracle Forms基于applet的網(wǎng)頁結構在產(chǎn)品保留了很長一段時間，這種結構就成為一種缺點。
mySAP.com網(wǎng)頁也是由HTML和Script建立而成的，而Script可以是javascript，或者是兼容SAP傳統(tǒng)的技術，ABAP Objects。使用傳統(tǒng)的技術使得技術架構顯露出缺陷，并且不同于Oracle的是，SAP沒有銜接好一個移植規(guī)劃
。
Siebel 7的網(wǎng)頁是建立在一個可視化的目標模型的基礎上，類似于客戶端/服務器用戶界面。這種結構設法來改進視覺效果和Web用戶界面的交互活動。這是一種新技術，并不能兼容傳統(tǒng)的Siebel系統(tǒng)。當這些網(wǎng)頁擁有很好的視覺效果和高度交互性的時候，它們的專有結構，以及與JSP很大的差異性，都會成為缺點。
�。�3）程序邏輯
程序邏輯的結構是一種能夠反映產(chǎn)品差異性的重要標準。以下我們將簡單概括每一種技術架構下的程序邏輯：
A、E.piphany E.6的程序邏輯基于元數(shù)據(jù)，并作為一種應用服務的綜合來執(zhí)行，每一種應用服務執(zhí)行是一套無規(guī)定的Session Enterprise Java Beans (Session Beans)和完全規(guī)定的Business Information Objects (BIOs)的結合。BIOs表示了用于CRM應用系統(tǒng)的實體。應用服務類似于組分。E.piphany E.6把最好的程序邏輯方法用于很多基于Web的應用軟件中。
B、Oracle EBS 11i有兩種類型的程序邏輯。一種類型的程序邏輯是基于Oracle Forms，這種類型是用PL/SQL來執(zhí)行的。第二種類型是以Java作為標準，并在中間層作為Java組分來部署。PL/SQL邏輯的存儲程序部署是一種劣勢，并且擁有技術架構上的局限。程序邏輯應當根據(jù)實際的程序語言來確定。它應當在中間層交付，并且在Web應用服務器控制下執(zhí)行。
C、PeopleSoft 8應用軟件的程序邏輯基于以C++形式的元數(shù)據(jù)，并以一套Tuxedo服務來部署。Tuxedo服務是模塊化程序，每一個模塊化程序執(zhí)行一個小型的應用功能或服務。程序邏輯的C++說明和Tuxedo部署是PeopleSoft傳統(tǒng)技術的核心。程序上的程序邏輯將被認為是一種重要的缺陷，但是它基于元數(shù)據(jù)，并在Tuxedo下部署，這樣就彌補了部分缺陷。
D、mySAP.com的程序邏輯有一個目標導向的結構，使用了一種組分和業(yè)務目標的目標模型。組分和業(yè)務目標的豐富的、模塊化的界面稱之為BAPIs (Business APIs)。BAPIs在組織mySAP.com應用軟件過程中發(fā)揮了重要的作用，并可以“躲避”一些在SAP傳統(tǒng)的ABAP技術中建立目標的復雜性。
E、Siebel 7的程序邏輯有一個專有結構。它是建立在稱之為業(yè)務目標模型（BOM）的目標模型的基礎上，根據(jù)元數(shù)據(jù)來確定。與Siebel文件目標模型（DOM）一樣，BOM是一個帶有五種類型抽象目標的目標等級：業(yè)務目標、業(yè)務組分、可視化業(yè)務組分、業(yè)務服務和集成目標。每一種類型的目標都已經(jīng)事先定義好一套屬性事件和腳本。企業(yè)組分和可視化企業(yè)組分是Siebel 7結構的核心類型。
業(yè)務組分代表Siebel 7數(shù)據(jù)庫中的實體�？梢暬瘶I(yè)務組分代表外部數(shù)據(jù)庫中的實體。它們的屬性標注在數(shù)據(jù)庫表格的列中。它們的事件與相應的數(shù)據(jù)庫操作對應。它們的腳本執(zhí)行Siebel 7的程序邏輯。腳本定義事件發(fā)生時所采取的活動。Siebel 7技術架構的程序邏輯結構存在一個很大的缺陷，因為它是使用專有腳本語言來詳細描述的，它是以數(shù)據(jù)庫為中心，并且它不是基于元數(shù)據(jù)的。
�。�4）Web服務
Web服務已經(jīng)成為一種具有吸引力的交互方式。Web服務的標準化目錄和查詢功能、界面說明，以及通信協(xié)議使得集成復雜性和成本的降低成為可能。我們所評估的五種技術架構都意識到支持Web服務的重要性。我們發(fā)現(xiàn)，E.piphany的E.6 and PeopleSoft的PIA能夠支持Web服務，而其余三種計劃在未來要支持Web服務。以下簡單介紹一下目前的狀況。
A、E.6提供一些性能來實現(xiàn)Web服務。它的軟件支持HTTP、XML和SOAP. WSDL，并為下層的Web應用服務器層提供UDDI支持。
B、Oracle的EBS 11i目前沒有實現(xiàn)正式的Web服務，因為EBS并沒有能通過所有的Web服務標準來展示功能。但是，Oracle已經(jīng)開始努力通過XML/SOAP服務來增強EBS PL/SQL功能的實用性。XML/SOAP服務目前主要用于PL/SQL軟件包的實施中。以后，Oracle將實施WSDL和UDDI標準用于這些服務中，從而使得這些服務成為真正的Web服務。
C、PeopleSoft的PIA能夠實現(xiàn)Web服務功能。并且Web服務可用于所有發(fā)布的集成組分的界面中。它支持XML、HTTP和SOAP。在BEA WebLogic Web服務環(huán)境下，WSDL和 UDDI將能夠獲得支持。
D、在目前發(fā)布的版本來看，mySAP.com還沒有實現(xiàn)Web服務。但是SAP計劃把所有的BAPIs轉為Web服務。這些界面已經(jīng)執(zhí)行XML；SAP應用服務器支持必要的通信協(xié)議：HTTP、SOAP和一個稱之為CRM中間件的組分。在SAP應用服務器Web服務環(huán)境下，WSDL和 UDDI將能夠獲得支持。
E、Siebel 7目前也不支持Web服務。但是Siebel正計劃快速實現(xiàn)對Web服務支持。Siebel 7.5計劃實現(xiàn)Web服務。公司沒有公開有關實施Web服務的詳情。但是我們了解到，Siebel 7.5中實現(xiàn)的Web服務并不是基于J2EE來部署的。據(jù)我們所知，Siebel將繼續(xù)它的專有技術架構和結構。
（五）客戶化
顯然，所有的CRM應用軟件都可以實現(xiàn)定制化。事實上，所有的運營型應用軟件定制化多少都會反映公司業(yè)務流程和信息結構的特征和細微差異。
一個CRM產(chǎn)品套件客戶化時有兩個方面的結構因素。一方面，元數(shù)據(jù)的角色；另一方面，使用標準化技術還是專有技術。當一個產(chǎn)品的結構基于元數(shù)據(jù)時，客戶化可以通過元數(shù)據(jù)來實現(xiàn)。不要使用低層級結構和編碼工具，你應當使用高層級元數(shù)據(jù)和可視化工具，這樣可以確保客戶化更加容易、快速和可控制。
當一個CRM產(chǎn)品的結構以標準化、大眾化的技術建立時，就會有許多用于客戶化的工具。當一個CRM產(chǎn)品建立在專有結構基礎上時，你被迫使用供應商的客戶化工具。
對比“客戶化”
我們對比“客戶化”的焦點在于：什么能夠獲得客戶化，以及執(zhí)行客戶化時所使用的機制。我們已經(jīng)在“結構”部分討論了元數(shù)據(jù)。E.piphany E.6、PeopleSoft的PIA和Siebel 7都完全是基于元數(shù)據(jù)的，這非常有助于定制應用軟件。因此，這對于E.piphany E.6、PeopleSoft的PIA和Siebel 7而言是一個非常好的優(yōu)點，而對于Oracle的EBS和mySAP.com而言則是一大缺點。例如，因為EBS是在Java技術和Oracle Forms技術的基礎上建立起來
的，客戶化可能既需要工具，又需要技能。定制mySAP CRM的程序邏輯甚至會更加復雜。它需要修改實施BAPIs所需的方法。依據(jù)你所定制的應用軟件，你將使用不同的開發(fā)工具——ABAP工具，由SAP提供，用于客戶交互中心；Java 用于Internet銷售，以及C++用于移動銷售和移動服務。開發(fā)方法必須能夠支持BAPI界面結構和正確的訪問界面的SAP協(xié)議。
當我們調查“什么能夠獲得客戶化”時，發(fā)現(xiàn)存在一個重要的差異：除了Siebel 7之外，其他產(chǎn)品的定制都沒有限制。在實施E.piphany的E.6、Oracle的EBS 11i、PeopleSoft的PIA和mySAP.com應用軟件時，你能夠修改、增加或刪除網(wǎng)頁、程序邏輯和數(shù)據(jù)。這并不是說你一定能夠將應用系統(tǒng)定制到何種程度，而是說你的定制講沒有限制。而且我們也并不是說這種定制非常容易。例如，增加一個新的數(shù)據(jù)庫表將影響程序邏輯和網(wǎng)頁，也會影響數(shù)據(jù)庫和數(shù)據(jù)訪問技術架構。
Siebel 7限制了“什么能夠獲得客戶化”。在它的DOM和BOM中，元目標模型代表了Siebel 7應用系統(tǒng)的網(wǎng)頁、程序邏輯和數(shù)據(jù)，你不能在預先定義好的目標中增加新的屬性，并且你也不能增加新的類型。Siebel 7不僅限制了產(chǎn)品定制，而且增加了定制的復雜性。因此總的來說，在所需的客戶化過程中，Siebel 7的缺陷比那些缺乏元數(shù)據(jù)支撐的產(chǎn)品更嚴重。
�。┘尚�
CRM系統(tǒng)主要用來為企業(yè)提供一種廣泛與客戶“打交道”的工具和方法。CRM產(chǎn)品必須要定制來反映企業(yè)的業(yè)務流程和信息結構。更為重要的是，產(chǎn)品也需要與內部和外部的業(yè)務系統(tǒng)進行集成，以自動化業(yè)務流程。內部業(yè)務系統(tǒng)主要包括其他運營型CRM應用系統(tǒng)和后臺系統(tǒng)，以及數(shù)據(jù)倉庫和分析型應用軟件；外部系統(tǒng)主要指銷售和營銷業(yè)務合作伙伴的CRM系統(tǒng)，以及你的供應商的后臺系統(tǒng)。最有意義的是，CRM產(chǎn)品應當提供一種集成的客戶視圖，收集不同種類來源的客戶信息，并能夠提供對所有應用系統(tǒng)的統(tǒng)一的訪問。
集成是一項關鍵而復雜的任務
集成是企業(yè)在實施CRM的過程中所遇到的最困難的任務之一。為了解決這個問題，業(yè)界衍生了一個系統(tǒng)集成行業(yè)。目前在市場上有很多集成技術和產(chǎn)品可以利用。同時也出現(xiàn)很多種信息協(xié)議和業(yè)務流程標準。當企業(yè)受益于相應的客戶服務和供應鏈管理的時，意識到集成正變的越來越容易。但是，你千萬不要低估了集成本身的復雜性。
“集成性” 比較結果排名
我們對5家CRM軟件廠商技術架構中的集成方法的進行了對比。對比和分析的排名結果如下：
①PeopleSoft Internet Architecture
PeopleSoft Internet Architecture在五家產(chǎn)品中具有最好的集成性。集成性是完整PeopleSoft 8應用套件的技術架構重要特征。CRM、ERP、HR和SCM應用軟件都會影響相應的集成能力，合稱為開放集成體系（OIF）。OIF支持以下五種集成方法：
A、 通過HTTP或IBM MQSeries，應用系統(tǒng)提供一種基于Web的異步XML編碼訊息。
B、 通過開放的、已發(fā)布的APIs，組分接口提供一種同步的“程序對程序”集成方法。這種方法支持COM、CORBA、EJB和HTTP/XML。
C、 企業(yè)鏈接提供一種同步的“程序對程序”集成方法。這種方法可以讓PeopleSoft應用軟件通過所支持的APIs來調用外部應用軟件。
D、通過批處理，應用系統(tǒng)引擎提供一種基于文件的集成方法。
E、 Java集成提供與Java應用軟件進行雙向的、同步的“程序對程序”集成。
PeopleSoft的OIF支持最廣泛的集成方法。PeopleSoft應用軟件的結構不僅不會限制你所要使用的集成方法，也不會使得集成的實施變的復雜。
�、趍ySAP CRM
與客戶化一樣，mySAP CRM的集成是通過BAPIs來實現(xiàn)的。BAPIs是開放的，所有的功能和數(shù)據(jù)都可以訪問。它們可以稱之為實時同步性。在SAP Application Server部署可以使用ABAP應用、Java應用或者是HTTP/XML訊息。另外，BAPIs是雙方向的，支持mySAP com應用系統(tǒng)的集成。也就是說，BAPIs為所有的集成方法提供工具。然而，BAPIs隱藏的低層級工具是非常復雜的。而那正是企業(yè)需要完成集成工作的地方。
�、跡.piphany E.6
E.piphany E.6應用系統(tǒng)的J2EE技術架構，以及標準化結構，有利于集成。在大多數(shù)情況下，你會使用Java、J2EE和Internet技術標準來把E.6系統(tǒng)與其他外部系統(tǒng)進行集成。唯一的缺點在于：有一些低層級的工具非常復雜。例外，正如我們上面所討論的，E.6也包括一種業(yè)務流程自動化的集成方法。而且，因為E.6是一種新的技術架構，并且E.piphany擁有的客戶群體并不是很大；因此你不能從EAI供應商那里購買集成工具，并且E.piphany也沒有投資來開發(fā)集成工具與大眾后臺系統(tǒng)的組裝程序。我們可以說，缺乏組裝集成的支持也是一大缺陷。
④Oracle EBS 11i
EBS 11i支持同步和異步的集成方法，可以集成內部應用系統(tǒng)和外部應用系統(tǒng)，并使用大眾化的標準。異步集成是一種很好的方法，并且具有很高的靈活性，但是低層級工具將更加復雜。同步集成也受到復雜性的限制。另外，EBS 11i并沒有得到外部EAI產(chǎn)品的廣泛支持。這部分是因為集成在數(shù)據(jù)庫層級最容易實現(xiàn)，并且數(shù)據(jù)庫集成比“程序對程序”方法更容易實現(xiàn)，通常不需要額外的集成產(chǎn)品。
訊息集成是EBS的“主打”。首先，訊息工具非常強大。它們包括XML編碼，支持J2EE JMS標準，支持工作流。其次，把程序邏輯的實施看作儲存程序的EBS的結構往往使得同步的“程序對程序”方法變的難以實行。
�、軸iebel 7
Siebel 7支持同步的、實時“程序對程序”集成，也支持異步訊息導向和數(shù)據(jù)庫導向的集成。它支持的集成協(xié)議范圍很廣：用于“程序對程序”集成的COM、CORBA和Java (data) Bean 協(xié)議；用于異步訊息導向集成的XML/HTTP、IBM MQSeries和Microsoft MSMQ協(xié)議。
另外，Siebel 7還支持特定的外部業(yè)務流程集成，以及企業(yè)應用集成（EAI）的實施，包括Microsoft BizTalk、SeeBeyond、TIBCO、Vitria和web-Methods。而且也支持與SAP R/3、Oracle
E-Business Suite和PeopleSoft 8的集成。以上都是可能的集成方法和途徑。
這廣泛的集成方法能夠得到外部應用軟件和Siebel 7應用軟件的支持。但是，一旦你進入Siebel 7環(huán)境，這些方法必須能夠適應Siebel 7的結構。而且為了實現(xiàn)Siebel 7與外部應用軟件的集成，你必須改變Siebel 7的結構，以運用相應的集成方法。例如，Siebel 7的大多數(shù)程序邏輯是以事件觸發(fā)的腳本來實現(xiàn)的，這與數(shù)據(jù)的操作關系非常密切。因此，同步的、“程序對程序”集成方法可以使用，但是不能準確的獲得。你不能創(chuàng)建一個腳本，并且你也難以同步獲得一個腳本。Siebel用戶曾經(jīng)告訴我們，大多數(shù)集成是通過Siebel數(shù)據(jù)庫或者批ETL來實現(xiàn)的。
通過以上我們所使用的結構化評估體系可以看出，五大公司的技術架構在環(huán)境、組織、基礎結構、結構、客戶化、集成性六個方面各有千秋，每一家公司都存在美中不足之處。因此這也反映了CRM的技術架構有待進一步的提高、發(fā)展和完善。
【全球頂級CRM產(chǎn)品的“技術架構”揭密】相關文章：
漫談CRM產(chǎn)品設計的指導思想08-05
產(chǎn)品架構師求職簡歷模板07-07
防止全球變暖的發(fā)電技術08-06
CRM的前世今生08-05
CRM的過去與未來08-05
包裝化·產(chǎn)品化·全球化08-05