Siebel UCM

spidershow

Siebel UCM概述UCM就是Universal Customer Master。 众所周知，SIEBEL的CRM是业界领先的客户关系管理系统。所以SIEBEL自然而然就想到了利用CRM系统里的客户数据来发展成为企业的客户主数据模型。UCM就是在这样的想法里产生。一些独立的机构在2006年的时候认为SIEBEL的UCM是业界最领先的客户主数据模型，本文和今后的一系列文章将仔细讨论这个客户数据模型。

UCM基本组成UCM包含三个模块：

1. Universal Customer Master(UCM): 存储和维护完整的客户主数据模型，分发客户数据给别的应用使用。

2. Siebel Data Quality(SDQ)：对主数据进行数据质量的控制，这是所有主数据管理中非常重要和必不可少的一节，比如客户邮编，可以使用SDQ去校验是否真的存在该邮编等等。

3. Universal Application Network(UAN)：UAN提供了额外的集成工具。

UCM的核心：SDH表结构UCM是MDM企业解决方案中客户数据的主数据，MDM的本质在于维护和提供企业里的终极真实数据，然后把该数据给企业里别的应用系统使用，为了达到这样的目的，UCM首先必须提供相应的客户数据结构来存储客户数据，然后还需要提供接口来维护该客户数据（比如客户数据的增加，修改，删除），最后还需要提供集成结构让别的应用可以使用该客户数据。SIEBEL通过扩展CRM的客户数据模型来满足客户主数据的这些要求，扩展的核心数据结构就是SDH（Source Data and History）表。所有的应用都需要通过SDH来修改和访问客户主数据模型。

其他系统和UCM的关系因为UCM管理着企业的客户主数据，任何其他需要用得客户数据的系统都需要和UCM打交道，在这些系统能够访问UCM数据之前，他们必须在UCM系统里注册并且被授予相应的权限。这些权限可以分为只读访问，增加记录权限，修改权限，删除权限等，这些系统必须根据实际的访问要求来注册相应的权限。比如一个负责增加客户的系统就需要被授予增加记录权限等等。

Siebel UCM数据结构概述
UCM作为企业里客户的主数据，维护着企业里客户的最准确的信息，本篇文章介绍UCM用于主数据管理数据结构的设计。UCM的表结构构成UCM包含四种类型的表：
1. Base Table（基础表）：基础表的设计的原来是SIEBEL归纳出来的客户数据模型，也即“客户主数据”，用于存储客户的各种信息。
2. SDH Table：SDH表是针对主数据管理的特点设计的表结构，数据进入基础表之前需要进行各种数据质量的检查，和现有数据是否重复，还需要把该数据的旧一个版本存储起来等工作，这些表称为源，数据，历史表（Source， Data and History），是主数据管理的整个流程里非常重要的表结构。这些表采用和基础表相似的命名方式，但是增加UCM在命名里以S_UCM_*的方式命名。如基础表是S_ORG_EXT的时候，SDH表则是S_UCM_ORG_EXT。
3. Interface Table(接口表): 接口表是对外暴露的表结构，对外暴露的目的是因为可以根据具体情况使用各种不同工具来把数据导入接口表。接口表以EIM_UCM_*来命名。其中EIM是EntERPrise Integration Manager的缩写。
4. SDH子表：第四种类型的表和数据流处理关系不大，但是也是UCM处理关键的一部分，称之为SDH表的子表。这种类型的表的命名规则是S_UCM_*_CHLD，从关系上来说该表是SDH相对应的表的子表。这种类型的表可以很容易支持客户自定义的存储数据，包含了50个预先定义的列来存储客户所需要的其他信息。

这几种类型表的数据流处理流程是（如上图）使用外部工具（如Oracle sqlldr或者sybase bcp或者任何能够把数据写入到表的方式如insert into select*）根据接口表的规定格式把数据导入到接口表，然后使用EIM模块来把接口表里的数据导入SDH表,最后调用批处理程序把SDH里的数据再导入到基础表。

基础表SDH表的变化
上面的数据流程描述数据如何从外部系统导入到基础表的流程，现在我们通过一个小例子来更详细地看看一条记录是如何通过SDH表进入到基础表的。
由上图可见，当需要使用一条记录来替换原来基础表的记录的时候，图的上半部分解释了基础表的相应记录会被替换成新的记录。图的下面的部分解释了这两条记录在SDH表的变化。即在替换前原来的记录A同时也在SDH表里，但是它的类型属性是Source，替换后这条为A的记录类型会变化为History；而新的记录A’原来在SDH表的状态是Queued，而替换了基础表的记录后就变为Source了。

数据质量概述
主数据维护着企业里该种类型数据的最值得信任的数据，所以使用质量管理技术来保证这些数据的准确是主数据管理里非常重要的一环。
数据质量管理主要包含两种类型的管理：
1. 数据清洗：数据清洗是对数据进行校验和标准化，比如地址邮编是否存在等等。
2. 数据匹配：数据匹配是找出有可能重复的记录。UCM系统里有两个阈值是用于控制数据匹配的流程，第一个阈值是高分阈值，对于数据匹配分值高于高分阈值的记录将会使用数据存活规则进行自动合并；第二个阈值是中分阈值，数据匹配得分在高分阈值和中分阈值之间的记录将会进入人工判断工作流，由管理员或者其他指定的人决定合并还是作为新记录。低于中分阈值的记录都将会被作为新记录。
数据存活规则（Survivorship rules）
一般而言，企业里的主数据来源于企业里的各个系统，当不同系统的同一个属性值有不同的值的时候，就需要决定哪一个系统的值是准确的。数据存活规则指定各种规则来决定新的数据进入到主数据库或者当新数据和旧有主数据冲突的时候的处理方法。数据存活规则主要有三种：
1. Recent规则：当相同的数据进入主数据系统的时候，以后来的数据为准，后来数据替换原来的数据。比如contact（联系人）信息，缺省是以后来的更新为主。
2. History规则：当相同的数据进入主数据系统的时候，以原来的数据为准，不接受后来数据的更新。
3. Source规则: 当相同的数据进入主数据系统的时候，以数据来源系统的可信度为作为使用哪个数据最后存活的规则。比如当源系统有A，B，C三个系统的时候，我们需要在主数据管理系统里注册这三个系统的时候，同时给这些源系统评分，则当使用source规则的时候，则以后的数据将以评分高的系统为准。比如我们有三个系统，CRM,财务，物流，对于客户信息而言，我们认为CRM系统里的客户信息应该是最准的，我们应该给于CRM系统较高的分值，则这个时候对于客户数据我们将使用Source规则，则以后所有的CRM系统相应客户的更新会覆盖原来不是CRM系统的更新。
数据质量管理流程
综合上述内容，可以总结出数据质量的大致控制流程（见上图），即当记录进入主数据系统时，先会在主数据系统里寻找可能匹配的记录，如果结果认为是不匹配，则将进入处理不匹配流程来增加一条新记录；如果是分值足够高，则进入自动匹配流程把该记录和原有记录进行数据存活规则处理并合并记录；如果是分值不足够高，则需要人工来决定该记录是新记录还是需要和原有记录合并。

UID和交叉引用
因为UCM的客户数据来源于不同的源系统，而不同的源系统维护同一个客户的时候很可能使用完全不同的ID标志规则，UCM为了在一个企业范围内维护最准确的用户信息，就有必要重新使用一个ID规则来标识整个企业范围内唯一的客户信息，这个ID称之为UUID（Universal Unique ID）。为了达到客户信息象别的系统发布，同步等需求，UCM还需要存储UID和其他源系统里客户ID的对应关系（Cross Referencing），来识别UCM的一个客户对应着别的系统的什么客户，这种信息就称之为交叉应用
如下图是一个UID和交叉引用的例子：上图表示了UCM的一个编号为1ASCLSCC的客户在不同的源系统里对应的客户的ID，需要重点说明的是，这种对应关系支持1对多的方式，如图上的前两条记录实际上是一个UID客户对应了Legacy系统里的两个编号的客户。

订阅和发布
实现UCM系统作为企业内客户主数据的其中一种方式是通过订阅和发布机制来实现，当数据从不同的源系统通过数据质量管理被UCM最终接受认可后，该数据的更新信息需要及时的推送到对客户数据感兴趣的其他系统，所有这些系统需要先在UCM系统里注册和订阅感兴趣的更新数据，还需要指定是接受实时更新还是批次更新（UCM支持近乎实时的数据更新，也支持24小时的批次更新），当然，更重要的是还要指定更新的协议和方式（比如是通过JMS方式，通过HTTP方式还是通过MQ方式等等）。则当UCM的数据有更新的时候，这些更新就可以通过系统里注册的这些订阅信息及时把更新推送到其他系统。下图是一个订阅和发布的示意图：

CRMML
CRMML是其他系统用来和UCM系统交互使用的XML数据格式，对于UCM新客户数据的增加，删除，更新都可以使用CRMML来表示，同时UCM数据对于外部系统数据的请求的响应以及UCM对于更新数据对外的发布也是以CRMML数据格式来表示。下图是一个其他系统和UCM系统交互的示意图：

Integration Object（集成对象）简介
Siebel Integration Object其实并不是属于UCM里面的概念，而是属于传统Siebel集成平台里面的概念（Siebel EAI），UCM在和其他系统交互时也延用了Siebel EAI的这个概念。什么是Integration Object呢？举个例子来说，我自己用C/java语言编一个程序，则我在我自己本系统内部的处理并不会使用XML，比如我如果要选出一个客户的信息来处理，则我在自己程序里会声明一个java对象（或者一个C数据结构）来处理客户信息，这个对象里会包含这个客户的名称，ID等各种属性值的集合（Property Set）； 但是当我需要和其他系统交换客户信息的时候，一个很自然的交换方式是我先从数据库里选出客户的信息放在我这个java对象里（可能使用某种O/R mapping），然后我通过读取这个对象的属性值来构造出一个XML文档来传给别的系统来达到交换的目的，而别的系统如果要给我的系统传数据也可以给我一个这样的XML文档，然后我解析这个文档后把相应的属性值都赋值给我的java对象，最后通过O/R mapping把这个客户的数据存在数据库里。这个java对象就是Siebel的Integration Object（当然这个只是一个最简单的说明），Siebel的Integration Object的功能远要比这里说得更加丰富，但是完成的最基本功能则是一样的。如下图

CRMML和Integration Object的转换
CRMML消息进出UCM系统都先要转换成相对应的Integration Object进行处理，UCM消息的CRMML本身没有DTD来规定它的格式，CRMML能够写什么内容是由3个预先定义的Integration Object来规定的。我们通过一个简单的例子来看看他们的格式。
<CRMML>
    <CRMHeader>
        <FromSystem>
            <SystemInfo>    <SystemId>11i financial</SystemId>
                    <SystemName>External App</SystemName>
            </SystemInfo>
        </FromSystem>
        <ToSystem> &iexcl;&shy; </ToSystem>
        <MessageDescriptor> &iexcl;&shy; </MessageDescriptor>
    </CRMHeader>
    <CIFPartyPackage>
        <InsertContactProfile>
            <Contact>
                <FirstName>Daniel</FirstName>
                <LastName>Li</LastName>
                &iexcl;&shy;
            </Contact>
        </InsertContactProfile>
    </CIFPartyPackage>
</CRMML>
从上面的CRMML消息例子可以看到，UCM的消息主要由3部分组成1.        Header部分，主要用于标记源系统和目的系统的信息，如果是源系统的请求，UCM会检查该系统是否已经在UCM里已经注册，UCM只处理在UCM里注册的源系统的请求。
2.        操作部分（InsertContactProfile），这部分主要描述一个需要UCM执行的操作，如例子是要求UCM执行一个Insert Contact的操作。
3.        操作的参数值，即操作所带的具体的值，如例子要求插入的是一个Daniel，Li的contact信息。规定这个CRMML消息结构的相应的Integration Object分别是：如下图

UAN(Universal Application Network)简介
其实UAN不是UCM的一部分，所以本篇的话题是有点离题了，但是UCM的确使用UAN来和Oracle 11i，PSFT，SAP等应用系统之间进行客户信息的集成和发布。UAN本身是为了在各种应用产品间同步和集成信息而建立的一个应用集成框架。在2004年发布的4.0产品里包含了64个通用对象（Common Objects）,146个流程，也就是它支持64种基本对象在各种商业应用里的同步，总共预先建立了146个流程。举个例子来说，通过CRM接收到一个订单之后，订单需要转到ERP(11i,JD,PSFT等)，这个就是一个商业流程，而订单就是一个通用对象，则通过预先定义的集成流程就可以让订单从CRM系统流转到ERP系统。要是客户自己开发这个数据同步应用的话，得让好多人皱眉头的。这个就是UAN使用的最简单的一个例子。
下图是这个例子的示意图：

一个需要说明的是UAN是建立在集成服务器上的一个产品，UAN可以兼容多种集成服务器，除了大家熟知的IBM/BEA产品外，还可以是微软的bizTalk或者TIBCO等等，兼容性可真是够强的！
除了产品本身带了许多预先定制的商业流程外，用户也可以直接使用相应的服务器的图形设计界面直接修改原来的流程或者建立新的流程来符合自己的需要。
下图是一个使用Webmethod的Developer来开发Siebel商业流程的界面：

Siebel真是一个具有先进理念的公司
大家看着UAN的材料，会不会突然觉得有似曾相识的感觉，怎么感觉和AIA（Application Integration Architecture请参考本人昨天的文章http://lichuliang.itpub.net/post ... 的东西哦，UAN的Best Practices Business Processes以及Common Objects 和AIA Reference Business Model里的process以及EntERPrise Objects是类似的，而预先建立好的商业流程则是和SOA流程是对应的。要记住，UAN是2002年就发布了，那时候甚至没有SOA/BPEL，你不能不佩服SIEBEL真是一个很有创造力的公司。虽然Oracle收购了Siebel，但是看起来Siebel的理念和产品在Oracle得到了很大的重视，这可以从BIEE, BI Applications，CRM，和UAN类似的AIA看出来。Oracle也很果断，能够放弃以前的一些主意而吸收Siebel里先进的理念，这在很多公司根本是不可能的，希望Siebel的创造力能够在Oracle里延续下去！

结束语
学习UCM还是有不少收获，虽然还是有不少东西还没有交代清楚，还是决定要结束UCM的介绍了，因为接下去要进入MDM下一个题目的内容：如何使用技术产品建立自己的主数据管理。