全球顶级CRM产品的“技术架构”揭密
全球顶级CRM产品的“技术架构”揭密 ● E.piphany E.6 ● Oracle E-Business Suite 11i ● PeopleSoft 8 ● mySAP CRM 3.0 ● Siebel 7 一、研究意义和研究方法 （一）CRM技术架构是决定客户体验的最重要因素 在2001年底，我们就开始了一项对CRM技术架构的研究。我们感觉 此项目具有非常重要的价值，因为客户在实施CRM应用系统时将直接面对软件 的技术架构。而且，软件技术架构的实用性、直觉性、功能性、可测量性和可管 理性将直接决定企业客户对产品的体验，因此CRM技术架构将决定CRM产品如 何简易的定制到你的特定的业务需求中。而且CRM技术架构也是决定CRM应用 软件能够与为客户提供重要信息的后台系统进行集成的关键因素。（二）结构化的评估和对比 此次研究开始于一个评估体系的开发，该体系的建立首先需要我们建 立一套评估单个产品和对比多种产品的标准。该标准将决定我们后面的工作开展。
我们曾经使用过这种方法来评价和对比许多类型的产品，例如局域网 管理工具、C/S应用软件开发工具、目标数据库管理系统等。这种结构化方法已 经被我们证实是非常有效的。尤其当被评价的软件/工具对企业至关重要，而且 企业需要从难以区分的众多产品中进行选择的时候，这种方法就显得更加有效。
（三）五家CRM供应商的选择 一旦我们的体系建立好，我们就可以开始进行技术架构的评估了。到 目前为止，我们已经评估了全球顶级的五种产品（上文所提到的五种产品）的技 术架构的评估结果。
至于我们为什么选择这五个软件厂商的产品，是因为这五家厂商，无 论是在客户的数量、市场的影响力，还是公司的规模上，都是世界上数一数二的 CRM供应商。另外，这些供应商的产品套件都包括营销、销售和服务功能模块。（四）持续研究 我们的研究不会随着这次报告的产生而结束。还有其他厂商的产品结 构也非常值得我们去研究，例如Kana、Onyx和Pivotal，它们在CRM领域也取得 了相当大的成功。而且微软也快要加入 “CRM圈”。因此我们的工作远没有结束， 我们将持续研究下去。
二、研究内容和研究结果 这份报告的核心将围绕我们的评估体系。对于每一种产品的技术架构， 我们都将围绕以下6大标准来评估：
环境、 组织、基础结构、结构、客户化、 集成性。
对于每一个评估标准，我们将简要的描绘相应的标准，并根据评估标 准来对比各种技术架构的优势和劣势，然后给出一定的排名。
（一）环境 环境是企业在选择软件的过程中最简单的技术架构的评估标准，而且 是最容易区分的。最重要的环境就是CRM产品所支持的服务器平台和数据库。
在你选择CRM产品时，最好不要改变你现有的服务器平台和数据库标准，否则 你将会增加很多投资。因此一个CRM产品最好要支持你的企业原有环境。下表 列出了那5家产品的技术架构的环境。
（1）“必须的”环境 有些环境是软件所必须要支持的。技术架构必须要支持Microsoft NT/2000、Sun Solaris服务器平台、IBM DB2、Microsoft SQL Server和Oracle Server 管理系统。这些都是世界领先的系统环境，而且也是企业最可能要使用到的系统。
因此如果产品不能支持这些环境显然会产生很大的局限性。从上表我们可以看出， 除了Oracle外都能够支持这些“必须的“环境。（因为Oracle必须要支持自己的数 据库。） （2）“必备的”环境 当我们认为支持领先的环境是“必须的”时候，支持第二层环境则是 “必备的”。第二层环境例如：HP-UX 和IBM AIX服务器平台、IBM和Sybase服务器管理系统。通过对比第二层环境，我们可以看出谁具备更广的安装环境。从上 表我们可以看出，除了Oracle外都能够支持一些“必备的”环境。Siebel和E.piphany 支持“必备的”环境相对较少，而SAP最广。
（3）“环境”比较结果排名 ① mySAP CRM 3.0。mySAP CRM 3.0支持“必须的”环境，并且能够 支持“必备的”环境的范围最广。
② PeopleSoft Internet Architecture. PeopleSoft Internet Architecture支 持“必须的”环境，并且能够支持“必备的”环境的范围比较广。
③ Siebel 7. Siebel 7支持“必须的”环境，并且能够支持一些“必备的” 环境。
④ E.piphany E.6. E.piphany E.6支持“必须的”环境，并且能够支持部 分“必备的”环境。
⑤ Oracle E-Business Suite 11i.由于Oracle公司自身拥有功能强大的 数据库，因此它主要 支持自己的数据库环境。
（二）组织 产品的“组织”主要用来反映各组分的配置方式，以及组分间接口和通 信协议。它也是描绘技术架构的标准之一。企业通过调查产品组分的数量、类型， 以及组分间的通信协议，就可以获得一个对产品实用性、可测量性和可控性的总 体认识。
我们所评估的五种技术架构都执行三层Web应用。在它们的三层组织 中都包括以下类型的组分：
● 客户端 ● 应用服务器 ● 数据库 根据以上组分对比五种产品的组织难以看出差异性，但是我们如果将 组分进行细化，也是能够找到许多不同点的。在客户端的组织中存在一些不同点。支持无线和移动客户端这方面就 有很大的不同点。例如，E.piphany E.6、Oracle E-Business Suite 11i和Siebel 7在 移动客户端执行的是统一用户Web服务器界面。这是一种很好的思想，可以确保 你的客户和你的呼叫中心客服人员、销售人员和现场服务人员拥有统一的用户界 面。而其他两种产品技术架构，PeopleSoft Internet Architecture和mySAP.com执行 的则是不同于Web用户界面的“桌面多用户界面”。这种界面的优势在于丰富性和 交互性。它们的缺点在于用户界面容易出现不协调。
与其他软件相比，Oracle E-Business Suite 11i在应用服务器上有很大 的不同。各种软件的数据库方面的差异性表现在：软件访问和共享外部数据的能 力存在很大的不同。E.piphany E.6和Siebel 7在访问外部数据的能力方面显著强于 其他软件。而且企业可以通过配置不同的选项来确定外部的数据源。这是一种比 较灵活的方式。
“组织”比较结果排名 根据上面所描述的差异性，以及其他一些因素，我们根据“组织”这个 要素将厂商排名如下：
① E.piphany E.6和Siebel 7. E.piphany E.6和Siebel 7拥有最好的组织。
在各种类型的客户端拥有统一的用户界面。
② PeopleSoft Internet Architecture和mySAP CRM 3.0.这两种技术架 构在客户端都缺乏统一的用户界面。相对E.piphany E.6和Siebel 7而言，存在一定 的劣势。
③ Oracle E-Business Suite 11i. 拥有统一的用户界面的优势，但是它 只兼容Oracle Forms技术，并且它需要使用Java 和PL/SQL，导致了产品的“组织” 相对比较复杂。
（三）基础结构 基础结构用来为多个用户和共享的资源系统（例如CRM应用系统） 提供系统级、独立应用的中间层服务。服务包括基本的请求处理、队列排序、流 程管理、记忆管理、数据库管理和事务管理等。所有服务都需要CRM和其他应 用软件的正确运作来实现。Portals是近来在基础结构中开发的一种形式。Portals用来提供附加的 应用服务器，用户通过这种应用服务器可以访问更大范围的应用软件和数据。这 对于CRM系统而言是一个很重要的优势，因为用户可以在某一个环境下，访问 多个CRM应用系统，看到多种报表，或者在不同维度上来检查企业的业绩。Portals 在用户界面层级上提供应用系统和数据的集成。所有的CRM套件供应商和电子 商务供应商都会提供基于用户界面的Portals。
“基础结构”比较结果排名 在基础结构方面，这五家软件厂商存在很大的差异性。差异性并不是 表现在基础结构所提供的服务上，而是表现在基础结构自身被执行的方式上。执 行方式的不同是由于让传统的技术适应Web而造成的。
而适应的方法存在很大的不同，并且都是基于特定的技术。E.piphany E.6是最新的技术架构，它的传统技术最早只能追溯到20世纪90年代末期，而 Siebel 7追溯到20世纪90年代早期；
Oracle E-Business Suite 11i和PeopleSoft Internet architecture所用的传统技术都可追溯到20世纪80年代末期；
mySAP可追 溯到20世纪70年代中期。另外，由于专有技术的不同特征导致了一些差异性。因 为这种技术差别非常大，因此我们不能以对比“环境”和“组织”的方式来对比“基 础结构”。我们将独立讨论每一种CRM产品的基础结构。以下是我们研究的排名 结果，以及相应的详细解释。
① E.piphany E.6 E.piphany E.6在“基础结构”方面排在第一位。
E.piphany在E.6的技术架构上投入了大量的研发资金，以集成不同的内部开 发的应用软件，并确保在Java技术上部署软件，然后在J2EE基础结构上配置它们。
这种基础结构不带有任何专有的成分，并且没有使用传统的技术。E.6是我们所 评估的五种产品中具有最清晰的基础结构。
E.piphany E.6在一个标准的J2EE Web应用服务器（或者是BEA WebLogic产品，或者是IBM WebSphere产品）上部署。该技术架构没有客户端基 础结构，也没有一个Portals。但是我们可以通过任何支持Java Server Pages、E.6 客户端结构的Portals访问E.6应用软件。
在E.6中的数据访问是通过一个基于元数据的企业信息目标（BIOs） 抽象层来实现。BIOs用来实现对多种类型的多种数据源的管理。而能够集成多种类型的多种数据源是一个非常重要的优势。集成通过元数据可以非常容易而灵活 地实现。
② PeopleSoft Internet Architecture PeopleSoft Internet Architecture (PIA)基础结构可以很好的兼容 PeopleSoft的技术。这是一个源于BEA系统的商业基础结构，它包括面向Internet 的PeopleSoft的C/C++应用技术。一个J2EE Web应用服务器为PeopleSoft 8基础结 构提供了处理表示层的能力。PeopleSoft 8应用系统的传统技术和C/C++程序逻辑 都是在BEA Tuxedo上部署。
在很多方面，PeopleSoft比较幸运。BEA产品完成了兼容PeopleSoft 传统技术的工作。当PeopleSoft起初在Tuxedo基础结构上实施时，Internet和J2EE 并不在技术规划范畴内。令PeopleSoft感到欣慰的是，Tuxedo是一种商业基础结 构。在Tuxedo上要比在专有基础结构上（很多竞争对手所使用的方法）部署软件 更理想。BEA处于基础结构业务领域。当然，为了保持竞争力，它的产品必须变 革需求，吸纳新技术。
PeopleSoft 8 Portal是PIA基础结构的中间层部分。所有的PeopleSoft 8 应用软件，与外部的应用系统和信息系统一样，都能够通过标准的Portals被访问。
它支持HTML、WML和XML的请求，并使用BEA JOLT的工具把它们安排到相应 的PeopleSoft 8应用软件中。PeopleSoft Internet Architecture客户端应当遵守J2EE 标准。
在PIA上的数据访问可以通过一个统一的、集中化的称之为SQL Access Manager的组分来实现。它使用本地的RDBMS 的SQL Dialect来存储 PeopleSoft 8的数据。
③ mySAP CRM 3.0 mySAP CRM的基础结构含有商业和专有的成分。新的Web应用服务 器既兼容SAP的传统ABAP技术，也支持J2EE应用软件，并可以共享这两者间的 资源。遗憾的是，这个基础结构的专有成分是一种新成分。
mySAP CRM包括使用SAP的传统ABAP技术建立起来的应用软件，也 包括使用最新的现代Internet技术建立起来的应用软件。因此，整个套件在一个混 合技术的基础结构的基础上进行部署。在2002年6月，SAP推出了它自己的Web应用服务器，称之为SAP Application Server，并在提供共享的、集成的后台资源 访问的同时，支持ABAP和J2EE应用软件。我们认为，兼容SAP传统的技术，并 能够集成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的一个组分，用来 提供一个开发环境，并服务于mySAP.com Web应用的表示层。Web Dynpro是一 种新技术，设计来作为Java Server Page表示层模型之上的附加层，以改进产品的 实用性和性能。
④ Siebel 7 Siebel 7基础结构包括中间层应用服务器和客户端的成分。所有的成 分都是专有的。Siebel的基础结构是它的技术架构的重要缺陷。
在中间层，Siebel 7在Siebel Server上部署。使用C++，Siebel Server有 利于服务于下层服务器平台，但是没有能够使用J2EE或.NET的工具。
Siebel 7用户界面可以通过Siebel Portal Framework来实现。这个Portals 提供一种性能，来满足我们在Portals处所期望实现的单一签名、验证、定期交叉 的需求，还可以基于浏览器来集成运营型和分析型应用软件。如果你已经实施了 一个Portals，你将能够通过Siebel XML Web界面来访问Siebel应用软件和数据。
那是一种优势。但是当有更多的交互式SmartWeb用户界面时，这不是一个统一 的用户界面。那又是一种劣势。用户访问Siebel 7应用系统（不是通过一个Portals） 是通过客户端的基础结构来实现的。
数据库访问是通过Siebel Database Manager（Siebel Server的组分之一） 来实施的。Siebel Database Manager使用数据库产品的SQL语言来执行数据库，完 成访问。使用这种基础结构，外部的数据库也能够从Siebel 7应用软件上得到访 问。
⑤ Oracle E-Business Suite 11iOracle E-Business Suite（EBS）基础结构包括Internet标准和公司的传 统技术。在客户端、应用服务器，以及数据库中都有基础结构成分。客户端和数 据库成分是专有的。
EBS 11i在J2EE和Oracle Forms、PL/SQL的混合成分的基础结构上部 署。它的程序逻辑为：客户端以applets形式，应用服务器端以Java形式，而在数 据库中使用触发和存储程序。因此在客户端、应用服务器端和数据库中都有基础 结构。而这种结构的最大缺点在于：使得EBS的客户化、集成、实施和管理变的 非常复杂而艰难。
不过，我们已经发现，Oracle的基础结构正在处于变化之中。在最近 的产品版本中，公司声称只有25%的CRM应用系统是采用的传统技术，并且所有 新的开发都是基于Java和J2EE的。EBS 11i的用户界面能够通过Oracle9iAS Portal 来实现。Oracle9iAS Portal能够具备大多数Portal所具有的能力：Portals用户界面 开发、应用软件的集成、报表、安全性和个性化等。
我们这里所讲的结构是指，CRM产品组织中的主要内部成分是什么， 以及它们如何被建立，由什么组成。典型的CRM产品主要是三层基于Web的组织， 因此我们使用三种类型的成分来定义和描绘它们的结构：
● 网页/表示层 ● 程序逻辑（用于应用软件功能和应用服务功能） ● 数据模型 知道一个产品的结构，有助于你实施、定制、支持和维护产品，以及 CRM与其他应用系统的集成。当一个产品的网页、程序逻辑和数据模型建立在 标准的、大众化的技术上时，你的工作会简单很多。
对比“结构” 对比我们所要评估的五种技术架构的“结构”，我们发现两个相似点和 许多不同点。
所有相似处都表现在数据结构方面：整体数据模型和客户数据模型。
总之，所有的技术架构都已经预先定义好，并且灵活的数据模型代表了所有的关 键CRM业务实体。对于客户数据模型，所有的技术架构都拥有丰富的、开放的 和一致的客户数据。所有类型的客户和所有类型的客户关系都能够表示出来。除了Siebel 7限制了客户化范围外，客户数据在所有的技术结构中都具有灵活性。
因此，我们不能在客户数据的基础上对软件产品的技术架构进行排名。
差异性主要出现在其他的评估尺度中：元数据、网页、程序逻辑和 Web服务。许多不同点是由于传统的专有技术引起的。通常情况下，兼容传统的 技术容易导致专有结构。在下面的内容中，我们将在各种尺度上分别讨论产品的 优越性、差异性。
（1）元数据 E.piphany E.6、PeopleSoft Internet Architecture和Siebel 7是完全基于元 数据的。从这一点而言，这三种产品要比其他两种产品更具有优越性。
Oracle EBS 11i和mySAP.com产品的只有某些方面是基于元数据的。
因此它们不能完全获得元数据在品质、客户化和实施中所具有的优势。
（2）网页 E.piphany E.6和PeopleSoft 8 拥有由HTML和javascript（作为JSPs来执 行）建立起来的网页。JSP标准的使用让网页结构比其他产品更具有优势。
Oracle EBS 11中的大多数网页也是由HTML和javascript建立起来 的；
但是它兼容传统的技术，基于表单的网页是通过applets来实现的。EBS的网 页也将基于JSPs。但是，Oracle Forms基于applet的网页结构在产品保留了很长一 段时间，这种结构就成为一种缺点。
mySAP.com网页也是由HTML和Script建立而成的，而Script可以是 javascript，或者是兼容SAP传统的技术，ABAP Objects。使用传统的技术使得技 术架构显露出缺陷，并且不同于Oracle的是，SAP没有衔接好一个移植规划。
Siebel 7的网页是建立在一个可视化的目标模型的基础上，类似于客 户端/服务器用户界面。这种结构设法来改进视觉效果和Web用户界面的交互活 动。这是一种新技术，并不能兼容传统的Siebel系统。当这些网页拥有很好的视 觉效果和高度交互性的时候，它们的专有结构，以及与JSP很大的差异性，都会 成为缺点。
（3）程序逻辑程序逻辑的结构是一种能够反映产品差异性的重要标准。以下我们将 简单概括每一种技术架构下的程序逻辑：
A、E.piphany E.6的程序逻辑基于元数据，并作为一种应用服务的综 合来执行，每一种应用服务执行是一套无规定的Session Enterprise Java Beans (Session Beans)和完全规定的Business Information Objects (BIOs)的结合。BIOs表 示了用于CRM应用系统的实体。应用服务类似于组分。E.piphany E.6把最好的程 序逻辑方法用于很多基于Web的应用软件中。
B、Oracle EBS 11i有两种类型的程序逻辑。一种类型的程序逻辑是基 于Oracle Forms，这种类型是用PL/SQL来执行的。第二种类型是以Java作为标准， 并在中间层作为Java组分来部署。PL/SQL逻辑的存储程序部署是一种劣势，并且 拥有技术架构上的局限。程序逻辑应当根据实际的程序语言来确定。它应当在中 间层交付，并且在Web应用服务器控制下执行。
C、PeopleSoft 8应用软件的程序逻辑基于以C++形式的元数据，并以 一套Tuxedo服务来部署。Tuxedo服务是模块化程序， D、mySAP.com的程序逻辑有一个目标导向的结构，使用了一种组分 和业务目标的目标模型。组分和业务目标的丰富的、模块化的界面称之为BAPIs (Business APIs)。BAPIs在组织mySAP.com应用软件过程中发挥了重要的作用， 并可以“躲避”一些在SAP传统的ABAP技术中建立目标的复杂性。
E、Siebel 7的程序逻辑有一个专有结构。它是建立在称之为业务目标 模型（BOM）的目标模型的基础上，根据元数据来确定。与Siebel文件目标模型 （DOM）一样，BOM是一个带有五种类型抽象目标的目标等级：业务目标、业 务组分、可视化业务组分、业务服务和集成目标。每一种类型的目标都已经事先 定义好一套属性事件和脚本。企业组分和可视化企业组分是Siebel 7结构的核心 类型。
业务组分代表Siebel 7数据库中的实体。可视化业务组分代表外部数 据库中的实体。它们的属性标注在数据库表格的列中。它们的事件与相应的数据 库操作对应。它们的脚本执行Siebel 7的程序逻辑。脚本定义事件发生时所采取 的活动。Siebel 7技术架构的程序逻辑结构存在一个很大的缺陷，因为它是使用 专有脚本语言来详细描述的，它是以数据库为中心，并且它不是基于元数据的。（4）Web服务 Web服务已经成为一种具有吸引力的交互方式。Web服务的标准化目 录和查询功能、界面说明，以及通信协议使得集成复杂性和成本的降低成为可能。
我们所评估的五种技术架构都意识到支持Web服务的重要性。我们发现， E.piphany的E.6 and PeopleSoft的PIA能够支持Web服务，而其余三种计划在未来 要支持Web服务。以下简单介绍一下目前的状况。
A、E.6提供一些性能来实现Web服务。它的软件支持HTTP、XML和 SOAP. WSDL，并为下层的Web应用服务器层提供UDDI支持。
B、Oracle的EBS 11i目前没有实现正式的Web服务，因为EBS并没有 能通过所有的Web服务标准来展示功能。但是，Oracle已经开始努力通过 XML/SOAP服务来增强EBS PL/SQL功能的实用性。XML/SOAP服务目前主要用 于PL/SQL软件包的实施中。以后，Oracle将实施WSDL和UDDI标准用于这些服 务中，从而使得这些服务成为真正的Web服务。
C、PeopleSoft的PIA能够实现Web服务功能。并且Web服务可用于所 有发布的集成组分的界面中。它支持XML、HTTP和SOAP。在BEA WebLogic Web 服务环境下，WSDL和 UDDI将能够获得支持。
D、在目前发布的版本来看，mySAP.com还没有实现Web服务。但是 SAP计划把所有的BAPIs转为Web服务。这些界面已经执行XML；
SAP应用服务 器支持必要的通信协议：HTTP、SOAP和一个称之为CRM中间件的组分。在SAP 应用服务器Web服务环境下，WSDL和 UDDI将能够获得支持。
E、Siebel 7目前也不支持Web服务。但是Siebel正计划快速实现对Web 服务支持。Siebel 7.5计划实现Web服务。公司没有公开有关实施Web服务的详情。
但是我们了解到，Siebel 7.5中实现的Web服务并不是基于J2EE来部署的。据我们 所知，Siebel将继续它的专有技术架构和结构。
（五）客户化 显然，所有的CRM应用软件都可以实现定制化。事实上，所有的运 营型应用软件定制化多少都会反映公司业务流程和信息结构的特征和细微差异。
一个CRM产品套件客户化时有两个方面的结构因素。一方面，元数据的角色；
另一方面，使用标准化技术还是专有技术。当一个产品的结构基于元 数据时，客户化可以通过元数据来实现。不要使用低层级结构和编码工具，你应 当使用高层级元数据和可视化工具，这样可以确保客户化更加容易、快速和可控 制。
当一个CRM产品的结构以标准化、大众化的技术建立时，就会有许 多用于客户化的工具。当一个CRM产品建立在专有结构基础上时，你被迫使用 供应商的客户化工具。
对比“客户化” 我们对比“客户化”的焦点在于：什么能够获得客户化，以及执行客户 化时所使用的机制。我们已经在“结构”部分讨论了元数据。E.piphany E.6、 PeopleSoft的PIA和Siebel 7都完全是基于元数据的，这非常有助于定制应用软件。
因此，这对于E.piphany E.6、PeopleSoft的PIA和Siebel 7而言是一个非常好的优点， 而对于Oracle的EBS和mySAP.com而言则是一大缺点。例如，因为EBS是在Java 技术和Oracle Forms技术的基础上建立起来的，客户化可能既需要工具，又需要 技能。定制mySAP CRM的程序逻辑甚至会更加复杂。它需要修改实施BAPIs所 需的方法。依据你所定制的应用软件，你将使用不同的开发工具——ABAP工具， 由SAP提供，用于客户交互中心；
Java 用于Internet销售，以及C++用于移动销售 和移动服务。开发方法必须能够支持BAPI界面结构和正确的访问界面的SAP协议。
当我们调查“什么能够获得客户化”时，发现存在一个重要的差异：除 了Siebel 7之外，其他产品的定制都没有限制。在实施E.piphany的E.6、Oracle的 EBS 11i、PeopleSoft的PIA和mySAP.com应用软件时，你能够修改、增加或删除 网页、程序逻辑和数据。这并不是说你一定能够将应用系统定制到何种程度，而 是说你的定制讲没有限制。而且我们也并不是说这种定制非常容易。例如，增加 一个新的数据库表将影响程序逻辑和网页，也会影响数据库和数据访问技术架构。
Siebel 7限制了“什么能够获得客户化”。在它的DOM和BOM中，元目 标模型代表了Siebel 7应用系统的网页、程序逻辑和数据，你不能在预先定义好 的目标中增加新的属性，并且你也不能增加新的类型。Siebel 7不仅限制了产品 定制，而且增加了定制的复杂性。因此总的来说，在所需的客户化过程中，Siebel 7的缺陷比那些缺乏元数据支撑的产品更严重。
（六）集成性CRM系统主要用来为企业提供一种广泛与客户“打交道”的工具和方 法。CRM产品必须要定制来反映企业的业务流程和信息结构。更为重要的是， 产品也需要与内部和外部的业务系统进行集成，以自动化业务流程。内部业务系 统主要包括其他运营型CRM应用系统和后台系统，以及数据仓库和分析型应用 软件；
外部系统主要指销售和营销业务合作伙伴的CRM系统，以及你的供应商 的后台系统。最有意义的是，CRM产品应当提供一种集成的客户视图，收集不 同种类来源的客户信息，并能够提供对所有应用系统的统一的访问。
集成是一项关键而复杂的任务 集成是企业在实施CRM的过程中所遇到的最困难的任务之一。为了 解决这个问题，业界衍生了一个系统集成行业。目前在市场上有很多集成技术和 产品可以利用。同时也出现很多种信息协议和业务流程标准。当企业受益于相应 的客户服务和供应链管理的时，意识到集成正变的越来越容易。但是，你千万不 要低估了集成本身的复杂性。
“集成性” 比较结果排名 我们对5家CRM软件厂商技术架构中的集成方法的进行了对比。对比 和分析的排名结果如下：
①PeopleSoft Internet Architecture PeopleSoft Internet Architecture在五家产品中具有最好的集成性。集成 性是完整PeopleSoft 8应用套件的技术架构重要特征。CRM、ERP、HR和SCM应 用软件都会影响相应的集成能力，合称为开放集成体系（OIF）。OIF支持以下 五种集成方法：
A、 通过HTTP或IBM MQSeries，应用系统提供一种基于Web的异步 XML编码讯息。
B、 通过开放的、已发布的APIs，组分接口提供一种同步的“程序对 程序”集成方法。这种方法支持COM、CORBA、EJB和HTTP/XML。
C、 企业链接提供一种同步的“程序对程序”集成方法。这种方法可以 让PeopleSoft应用软件通过所支持的APIs来调用外部应用软件。D、通过批处理，应用系统引擎提供一种基于文件的集成方法。
E、 Java集成提供与Java应用软件进行双向的、同步的“程序对程序” 集成。
PeopleSoft的OIF支持最广泛的集成方法。PeopleSoft应用软件的结构 不仅不会限制你所要使用的集成方法，也不会使得集成的实施变的复杂。
②mySAP CRM 与客户化一样，mySAP CRM的集成是通过BAPIs来实现的。BAPIs 是开放的，所有的功能和数据都可以访问。它们可以称之为实时同步性。在SAP Application Server部署可以使用ABAP应用、Java应用或者是HTTP/XML讯息。另 外，BAPIs是双方向的，支持mySAP com应用系统的集成。也就是说，BAPIs为 所有的集成方法提供工具。然而，BAPIs隐藏的低层级工具是非常复杂的。而那 正是企业需要完成集成工作的地方。
③E.piphany E.6 E.piphany E.6应用系统的J2EE技术架构，以及标准化结构，有利于集 成。在大多数情况下，你会使用Java、J2EE和Internet技术标准来把E.6系统与其 他外部系统进行集成。唯一的缺点在于：有一些低层级的工具非常复杂。例外， 正如我们上面所讨论的，E.6也包括一种业务流程自动化的集成方法。而且，因 为E.6是一种新的技术架构，并且E.piphany拥有的客户群体并不是很大；
因此你 不能从EAI供应商那里购买集成工具，并且E.piphany也没有投资来开发集成工具 与大众后台系统的组装程序。我们可以说，缺乏组装集成的支持也是一大缺陷。
④Oracle EBS 11i EBS 11i支持同步和异步的集成方法，可以集成内部应用系统和外部 应用系统，并使用大众化的标准。异步集成是一种很好的方法，并且具有很高的 灵活性，但是低层级工具将更加复杂。同步集成也受到复杂性的限制。另外，EBS 11i并没有得到外部EAI产品的广泛支持。这部分是因为集成在数据库层级最容易 实现，并且数据库集成比“程序对程序”方法更容易实现，通常不需要额外的集成 产品。
讯息集成是EBS的“主打”。首先，讯息工具非常强大。它们包括XML 编码，支持J2EE JMS标准，支持工作流。其次，把程序逻辑的实施看作储存程序的EBS的结构往往使得同步的“程序对程序”方法变的难以实行。
⑤Siebel 7 Siebel 7支持同步的、实时“程序对程序”集成，也支持异步讯息导向 和数据库导向的集成。它支持的集成协议范围很广：用于“程序对程序”集成的 COM、CORBA和Java (data) Bean 协议；
用于异步讯息导向集成的XML/HTTP、 IBM MQSeries和Microsoft MSMQ协议。
另外，Siebel 7还支持特定的外部业务流程集成，以及企业应用集成 （EAI）的实施，包括Microsoft BizTalk、SeeBeyond、TIBCO、Vitria和web-Methods。
而且也支持与SAP R/3、Oracle E-Business Suite和PeopleSoft 8的集成。以上都是 可能的集成方法和途径。
这广泛的集成方法能够得到外部应用软件和Siebel 7应用软件的支持。
但是，一旦你进入Siebel 7环境，这些方法必须能够适应Siebel 7的结构。而且为 了实现Siebel 7与外部应用软件的集成，你必须改变Siebel 7的结构，以运用相应 的集成方法。例如，Siebel 7的大多数程序逻辑是以事件触发的脚本来实现的， 这与数据的操作关系非常密切。因此，同步的、“程序对程序”集成方法可以使用， 但是不能准确的获得。你不能创建一个脚本，并且你也难以同步获得一个脚本。
Siebel用户曾经告诉我们，大多数集成是通过Siebel数据库或者批ETL来实现的。
通过以上我们所使用的结构化评估体系可以看出，五大公司的技术架 构在环境、组织、基础结构、结构、客户化、集成性六个方面各有千秋，每一家 公司都存在美中不足之处。因此这也反映了CRM的技术架构有待进一步的提高、 发展和完善。