主数据管理论文

《主数据管理论文》由会员分享，可在线阅读，更多相关《主数据管理论文（19页珍藏版）》请在装配图网上搜索。

1、MDM 介绍一主数据是指在整个企业范围内各个系统(操作/事务型应用系统以及分析型系统)间要共享的数据，比如，可以 是与客户(customers),供应商(suppliers),帐户(accounts)以及组织单位(organizational units)相关的 数据。主数据通常需要在整个企业范围内保持一致性(consistent)、完整性(complete)、可控性 (controlled)，为了达成这一目标，就需要进行主数据管理(Master Data Management，MDM)。什么是主数据管理(Master Data Management，MDM)主数据是指在整个企业范围内各个系统

2、(操作/事务型应用系统以及分析型系统)间要共享的数据，比如， 可以是与客户(customers),供应商(suppliers),帐户(accounts)以及组织单位(organizational units)相 关的数据。主数据通常需要在整个企业范围内保持一致性(consistent)、完整性(complete)、可控性 (controlled)，为了达成这一目标，就需要进行主数据管理(Master Data Management，MDM)。需要注 意的是,主数据不是企业内所有的业务数据,只是有必要在各个系统间共享的数据才是主数据,比如大部分的 交易数据、帐单数据等都不是主数据，而像描述核心业

3、务实体的数据，而像客户、供应商、帐户、组织单位、 员工、合作伙伴、位置信息等都是主数据。主数据是企业内能够跨业务重复使用的高价值的数据。这些主数据 在进行主数据管理之前经常存在于多个异构或同构的系统中。主数据管理(Master Data Management，MDM)是指一组约束和方法用来保证一个企业内主题域和系 统内相关数据和跨主题域和系统的相关数据的实时性、含义和质量。这是从深层次来说来说明主动主数据管理 (MDM )的深度和复杂性，简单的说，主数据管理(MDM)保证你的系统协调和重用通用、正确的业务数据(主 数据)。通常，我们会把主数据管理作为应用流程的补充，通过从各个操作/事务型应用以

4、及分析型应用中分离 出主要的信息，使其成为一个集中的、独立于企业中各种其他应用核心资源，从而使得企业的核心信息得以重 用并确保各个操作/事务型应用以及分析型应用间的核心数据的一致性。通过主数据管理，改变企业数据利用 的现状，从而更好地为企业信息集成做好铺垫。主数据管理(MDM)可以帮助我们创建并维护整个企业内主数据的单一视图(Single View)，保证单一视 图的准确性、一致性以及完整性，从而提供数据质量，统一商业实体的定义，简化改进商业流程并提供业务的 响应速度。从变化的频率来看，主数据和日常交易数据不一样，变化相对缓慢，另外，主数据由于跨各个系统， 所以对数据的一致性、实时性以及版本控

5、制要求很高。主数据管理其实在很早之前就一直存在，只不过现在随着业务发展以及监管的需要，对主数据的实时性、 准确性、一致性有了更高的要求，才被业界广泛接受，各个厂商相应的推出了一系列的主数据管理集成与基础 套件以及特定领域的解决方案。近年来最明显的变化是，客户在以前的时候经常问的问题是：“主数据管理是 什么？”，而现在客户经常问的问题演变成了：“我们的业务的确存在一些问题，主数据管理正好可以解决这个 问题，我们怎么开始？ ”。与以前相比，客户对主数据管理(MDM)的认识有了巨大的进步，并开始尝试用主数 据管理(MDM)解决他们在整个企业范围内进行跨业务、跨主题域时遇上的各种挑战和问题：比如税务行

6、业， 税务局在按纳税人在一些分析统计时，就发现关于纳税人的基本信息分布在核心征收管理系统、发票管理系统、 个人所得税系统、增值税管理系统等多达几十个系统中，使得统计分析变得困难起来，在比如在医疗设备公司， 由于没有按照供应商进行产品层次的分类，各个产品的描述也很不一样，使得产品目录的维护十分困难。随着 业务的发展，对各行各业来说，生成并维护一个统一的主数据系统变的十分迫切和必要，特别是对一些跨国公 司，如何在不同的地区(各个国家和地区) 的业务系统之间维护关于客户、产品目录、供应商等信息的单一视 图更是重要。需要注意的是，主数据(Maste r Data)和元数据(Meta Data )是两个

7、完全不同的概念。元数据是指表示 数据的相关信息，比如数据定义等，而主数据是指实例数据，比如产品目录信息等。比如，某省地税开发了一 套征收管理软件，以市为单位部署了 17 套，每套征收管理软件中的元数据都是一样的，但是主数据还是需要 进行管理的。主数据管理和传统数据仓库解决方案不是一个概念，数据仓库会将各个业务系统的数据集中在一 起在进行业务的分析，而主数据管理系统不会把所有数据都管理起来，只是把需要在各个系统间共享的主数据 进行采集和发布。相对于传统数据仓库解决方案的单向集成，主数据管理正注重将主数据的变化同步发布到各 个关联的业务系统中(主数据管理数据是双向的)。主数据管理问题存在的根源对于

8、大多数的企业都存在主数据管理的问题，个人以为这是由于业务发展的渐进性以及IT技术发展的渐 进性造成的，正是由于这种渐进性，各大企业的业务系统从经历了从无到有，从简单到复杂，从而形成了一个 又一个的业务竖井。从根本上来说，不可能只使用一个业务系统就能覆盖企业的所有业务，即便对一些国际大 型的公司提供的套件来说也是一个不可能完成的任务(即便对套件来说，经常也存在一个跨国企业在不同的国 家或地区部署多个实例的现象，也就是没有集中部署该套件，而是在很多地方分散部署了该套件)。对企业来 说，业务系统的构建更多是以项目为中心，从下而上的构建系统，而不是至上而下的构建系统，必然缺乏整个 企业范围内的统一规划

9、，从而使得一些需要在各个业务中共享的数据(主数据)被分散到了各个业务系统进行分 别管理。分散管理的主数据由于没有不具备一致性、准确性、完整性，使得各个企业普遍存在着产品管理不力、 供应商管理不力、订单管理不力等现象。解决这一问题的根本方法就是引入主数据管理(MDM),主数据不光 指需要共享的数据，更包含需要共享的业务规则和策略。MDM介绍二主数据管理(MDM)的成熟度主数据管理(MDM )的成熟度根据主数据管理实施的复杂程度，参照Jill Dyche, Evan Levy的观点大体可以把主数据管理可以分为 五个层次，从低到高反映了主数据管理(MDM)的不同成熟度。下面我们简单介绍一下这五个层次

10、：Level 0 ：没有实施任何主数据管理 (MDM)在 Level 0 的情况下，意味着企业的各个应用之间没有任何的数据共享，整个企业没有数据定义元素存 在。比如，一个公司销售很多产品，对这些产品的生产和销售由多个独立的系统来处理，各个系统独立处理产 品数据并拥有自己独立的产品列表，各个系统之间不共享产品数据。在Level 0,每个独立的应用负责管理和 维护自己的关键数据(比如产品列表、客户信息等)，各个系统间不共享这些信息，这些数据是不连通的。Level 1 ：提供列表不管公司大还是小，列表管理是我们常用的一种方式。在公司内部，会通过手工的方式维护一个逻辑或物 理的列表。当各个异构的系统和

11、用户需要某些数据的时候，就可以索取该列表了。对于这个列表的维护，包括 数据添加、删除、更新以及冲突处理，都是由各个部门的工作人员通过一系列的讨论和会议进行处理的。业务 规则(Business Rules)是用来反映价值的一致性，当业务规则发生改变或者出现类似的情况时，这样高度手 工管理的流程容易发生错误。由于列表管理是通过手工管理的，其列表维护的质量取决于谁参加了变更管理流 程，一旦某人缺席，将会影响列表的维护。MDM Level 1比MDM Level 0的不同就是，各个部门虽然还是独立维护各自的关键数据，但会通过列 表管理维护一个松散的主数据列表，能够向其他各个部门提供其需要的数据。在 M

12、DM Level 1 中，数据变更 决定以及数据变更操作都是由人来决定的，因此，只有人完成数据变更决定后才会变更数据。在实际情况中， 虽然数据变更流程有严格的规定，但是由于缺乏集中的、基于规则的数据管理，当数据量比较大时，数据维护 的成本会变的很高，效率也会很低。当主数据，比如客户信息、产品目录信息等数量比较少时，列表管理的方 式是可行的，但是当产品目录或客户列表出现爆炸式增长以后，列表管理的变更流程将变得困难起来。 MDM Level 1依赖于人的协作。如果产品经理需要更新过后的产品价格列表，那需要联系ERP系统所有者，让其 发送邮件给她。在企业范围内实现客户或产品列表就如同维护不同部门之间

13、人们的关系一样。如果客户或产品 存在层次或分组，列表将很难提供，并且通常在 Level 1 因为过于复杂难以被管理。Level 2 ：同等访问(通过接口的方式，各个系统与主数据主机之间直接互联 )MDM Level 2与MDM Level 1相比，引入了对主数据的(自动)管理。通过建立数据标准，定义对存储 在中央知识库(Cent ral Reposit ory)中详细数据的访问和共享，为各个系统间共享使用数据提供了严密的支 持。中央知识库(Cent ral Reposit ory)通常会被称为主数据主机(Maste r Data Host)。这个知识库可以是 一个数据库或者一个应用系统，通过在

14、线的方式支持数据的访问和共享。创建、读取、更新和删除(CRUD)是处理基本功能的典型编程术语。即便在MDM中，CRUD处理也是 基本功能。你的数据库如果仅仅支持CRUD处理并不意味着你实现了 MDM。MDM Level 2引入了同等访 问”(peer-based access)，也就是说一个应用可以调用另一个应用来更新或刷新需要的数据。当CRUD处 理规则定义完成后，MDM Level 2需要客户或同等”应用格式化请求（和数据）,以便和MDM知识库保持一 致。MDM知识库提供集中的数据存储和供应（provisioning）。在这个阶段，规则管理、数据质量和变更管理 必须在企业范围内作为附加功能

15、定制构建。比如，一个数据库或一个打包应用（比如一个销售自动化系统）对外部应用提供数据访问功能。当一个外部 应用（比如呼叫中心应用）需要增加一个客户，这个外部应用将提交一个事务，请求数据所有者增加一个客户条 目。主数据主机（Master Data Host）将增加数据并告知外部应用。CRUD处理方式比纸上办公有了很大提高, 其是基于会话的数据管理。在MDM Level 1数据变更是基于手工的方式。在MDM Level 2,数据变更是 自动完成的通过由具体技术实现的标准流程，允许多应用系统修改数据。 MDM Level 2可以支持不同的应 用使用和变更单一、共享的数据知识库。 MDM Level

16、2 需要每个同等应用理解基本的业务规则以便访问主列 表、与主列表进行交互。因此，每个同等应用必须正确恰当地创建、增加、更新和删除数据。授权应用有责任 坚持数据管理原则和约束。Level 3 ：集中总线处理与MDM Level 2相比，MDM Level 3打破了各个独立应用的组织边界，使用各个系统都能接受的数据 标准统一建立和维护主数据（MDM Level 2的主数据主机上存储的数据还是按照各个系统分开存储的，没有 真正的整合在一起）。集中处理意味着为MDM构建了一个通用的、基于目标构建的平台。大多数公司发现MDM正在挑战他们 现有的 IT 架构：他们拥有太多的独立平台处理主数据。 MDM L

17、evel 3 集中数据访问、控制跨不同应用和系 统使用数据。这极大的降低了应用数据访问的复杂性，大大简化了面向数据规则的管理，使MDM比一个分散 环境具有更多的功能和特点。企业主数据面临一致性的挑战。数据在不同的地方存在，数据所代表的含义也是 不同的，数据的规则各个系统之间也是不一样的。集中MDM处理-通过一个公共的平台作为一个总线（HUB）- 说明一个共识，从多个系统整合主题域数据，意味着使用集中、标准化的方法转换异构操作数据，不管其在源 系统中是什么样子，都会被整合起来。在MDM Level 3,公司对主题域内容采用集中管理方式。这意味着应 用系统，作为消费者或使用主数据，拥有一个共识就是

18、数据是主题数据内容的映像，打破了各个独立应用的组 织边界。 MDM Level 3 支持分布主参考数据的存在。MDM 的核心之一就是保证所有系统都能接受数据表示的唯一公认方法。这有点类似于语言翻译，通过其 他语言的翻译，英语已经称为一个全球性的语言。在MDM Level 3, 一个公司可以让任意两个系统共享数据 和说对方的语言。 MDM Level 3 还降低了等同访问的复杂性。 消费应用不再需要支持系统定位和操作逻辑。 任何与源系统数据相关的分布式细节都会被MDM总线集中处理。在MDM Level 3自动数据标准意味着：建 立目标数据值表示和通过必要的步骤提供精确的主数据值捕获。在所有的分类

19、中从MDM Level 3开始第一次 支持一致性的企业数据视图。数据质量规则在这里进行数据清洗和错误纠正。Level 4 ：业务规则和政策支持一旦数据从多个数据源整合在一起，主题域视图超越单独的应用并表现为一个企业视图，你将获得事实的 单一版本。当事实的单一版本已经能够提供出来时，来自业务主管和执行人员的必然反应经常是： 证明它”。 MDM Level 4 可以保证主数据反映一个公司业务规则和流程，并证实其正确性。 MDM Level 4 通过引入主 数据来支持规则，并对 MDM 总线以及其它外部系统进行完整性检查。由于多数公司相对比较复杂，影响业务 数据访问和操作的规则以及策略（r ules

20、 and policies）相对也比较复杂。假定任何一个单一系统可以包含并管 理与主参考数据相关的各种类型的规则是不切实际的。因此，如果一个MDM总线真正打算提供企业范围内数 据的精确性，工作流和流程整合的支持是必不可少的。举例来说，在一个HMO内，需要多个应用来支持一个病人的护理。一个单一的访问（visit）可能包括入院、 房间和床位分配、监控设备、化验、身体检查以及其他程序等。一旦一个病人准备离开医院，出院流程需要确 保和这个病人相关的所有活动、资源都被结清。 MDM 技术在召集多个应用系统一起保证病人辨识方面是十分 有效的，处理是正确的。虽然病人辨识很重要，业务规则整合同样重要。临床系统

21、依靠一系列的业务流程和数 据规则来辨别所有显著的病人详细资料。这包括返回所有基于房间的资源（监护设备、床位等）以得到有用的详 细目录，当病人要出院时分解其所有的费用。 MDM 保证当 John Smith 出院时，正确的房间和设备放入到该 John Smith的详细目录中，而不是其他的John Smith（正在另一个楼层做身体治疗）。MDM 系统必须不仅支持基于规则的整合，还要能够整合外部的工作流。这些规则可能包括通过总线与临 床系统交互或等待另一个系统或者人（有权限做出改变的人）审批。通过一个MDM总线，规则定义可以不仅局 限在逻辑上，还可以依赖于其他系统的输入。当然，协调和审计数据意味着可

22、以回退其他系统（或业务流程）来 保证数据变化经过严格的审批，这样错误可以被发现并且事务在需要的时候可以被回滚。 MDM Level 4 提出 对规则和策略扩展性的支持。通过总线以一个灵活可持续的方式支持任何面向业务的规则集合这很重要。比如，如果一个商店经理更新一个产品的价格，总线系统需要能够和一个可信系统（比如，商品管理系统） 进行协商以便使规则生效。详细规则将支持另一个系统中存在产品价格的变更总线需要能够理解能够处理和 批准变更的权限系统或方法。这些规则可能涉及到复杂性或隐私限制，禁止它们直接在总线上存在。在 MDM Level 4，一个企业可以支持一套步骤或任务，在一个特殊的创建、读取、更

23、新和删除任务被允许之前这些步 骤或任务必须遵守。工作流自动化经常用来支持发生在总线上的事件或活动的授权。但是变更管理远远不仅仅 是工作流：它可以包括基于逻辑的流程和基于人的决策。变更管理的存在可以支持动态业务，允许变更。举例 说明，在 911 之前，任何人都可以在美国国内的航空公司运载货物。没有规定以外的其他某种形式的鉴定和 付款方式。911之后，美国联邦航空协会(FAA)指导建立了一个更加全面的规定，指示一个人是否被允许运 载货物。在这个特殊的例子中，要求各个系统都部署FAA对托运人的要求是不现实的。部署一个规则管理系 统，为所有的系统(包括 MDM 总线)集中托运人批准规则，更加容易实现(

24、也更现实)。集中数据定义和标准化 在 MDM Level 2 就已经引入，与 MDM Level 4 的集中规则管理相比，相对简单。业务流程越复杂、业务流 程越多，对总线的需求就越多，以便对针对共同数据的跨职能、异构规则进行更好的支持。重要的是 MDM Level 4支持集中规则管理，但是规则本身和相关的处理是可以分开的。换句话说，MDM总线需要保证规则 是集中应用的，即便这个规则是在总线外居住的。Level 5 ：企业数据集中在 MDM Level 5 ，总线和相关的主数据被集成到独立的应用中。主数据和应用数据之间没有明显的分 隔。他们是一体的。当主数据记录详细资料被修改后，所有应用的相关数

25、据元素都将被更新。这意味着所有的 消费应用和源系统访问的是相同的数据实例。这本质上是一个闭环的MDM:所有的应用系统通过统一管理的 主数据集成在一起。在这个级别，所有在系统看起来都是事实的同一个版本。操作应用系统和 MDM 内容是同 步的，所以当变更发生时，操作应用系统都将更新。在那些熟悉的 MDM 架构风格中，持久总线架构，当一个 总线更新所有的操作应用系统将体现这种变更，形成改变的直接操作视图。在注册环境中，当数据数据更新时 总线将通过Web服务连接相关系统应用事务更新。因此，MDM Level 5提供一个集成的，同步的架构，当 一个有权限的系统更新一个数据值时，公司内所有的系统将反映这个

26、变更。系统更新完数据值后不要单选其他 系统中相应值的更新: MDM 将使这种更新变的透明。从MDM Level 4到MDM Level 5意味着MDM功能性不是在一个应用内被特殊设计或编码的。这还意 味着主数据传播和供应不需要源系统专门的开发或支持。所有的应用清楚的知道他们并不拥有或控制主数据。 他们仅仅使用数据来支持他们自己的功能和流程。由于MDM总线和支持的IT基础架构，所有的应用可以访 问主参考数据。一个公司在完成 MDM Level 5 后将使他们所有的应用连在一起既包括操作的也包括分析的 所有访问主数据是透明的。举例说明，当一个客户更新她的状态不要管注册该变更的系统数据变更将被 广播

27、到所有的应用平台(因此一致起来)。MDM Level 5是把数据概念作为一种service来实现。MDM Level 5 保证了一个一致的主数据主题域企业映像。定义“客户”和其他应用接受客户主数据业务规则变化实际 上是一回事。 MDM Level 5 移走了主数据的最后一个障碍:统一采用数据定义、授权使用和变更传播。构建一个主数据管理(MDM)的解决方案如何构建一个主数据管理(MDM )的解决方案在开始构建主数据管理(MDM)解决方案之前，首先需要明确我们当前的数据管理现状是什么样子的，而 我们的目标是什么，具体可以参照上一小节：主数据管理(MDM)的成熟度。第二步，需要确定我们的每个主数据域

28、的范围(这也是前期需求分析的一部分)。常见的主题域有:Party ：可以反映任何合法的实体，无论是个体还是组织。Product ：既包括物理存在的货物，也可以是任何服务。Account ：包括期限和条件，以及相关的各种关系。Location ：既可以独立存在，也常常与其他主数据域共存。第三步，进行数据管理系统的设计，在设计时要注意以下几点： 数据采集和发布是否实时，最小的响应时间是多少。 数据转换规则能否让客户定制，而不是硬编码。如果根据数据质量标准清理主数据域中的主数据。权限控制。主数据的历史版本控制以及变更监控控制（当主数据变化时，要能记录该变化，另外还要对主数据形成层 次并记录其不同的版

29、本值）。第四步，开发部署测试。最常见的13种主数据管理（MDM）词汇和定义简单而言，主数据管理（MDM ）是公司权衡和重用常见、和准确业务数据的一种全面的方法。然而，它同时 也是一种不只有助于组织做表面工夫的快速改进数据管理的策略。MDM系统是为维护公司数据主版本而设计 的，它可以通过将其影射到业务规则上来让组织自由处理数据，这种方法比以前的数据管理方法更加的主动。 公司之所以关注MDM的其中一个主要的原因是为了从不同的资源和应用上协调功能。不管你是否考虑实现新的 MDM 系统还是评估可能的工具和软件来帮助你目前的数据管理和数据整合主动 性，了解目前市场的趋势，包括最新的 MDM 定义和产业词

30、汇都是至关重要的。为了便于你学习（熟悉）MDM，我们编排了市场上最常见的13种词汇，包括数据管理、产品信息管理 （PIM）、企业主索引（EMPI）、MDM集线器等等。如果没有原数据，那么将不存在MDM，依Forresters Rob Karel看来。他说道任何激活MDM的，包 括定义、业务规则、政策、数据关系和质量优点都是通过使用原数据类维护的。 “换言之，原数据是主数据真 正值得信任的唯一方式， ”他说道。产品信息管理（PIM）在一个唯一的位置上管理组织的产品数据，因此产品数据是一致的，不管系统或 者应用是否需要它。Gartner定义PIM为通过产品主数据的语义调和来支持不同数据来源的全局产

31、品信息认 证、连接和同步软件产品;创建和管理一个关于记录的中央数据系统；（向所有stakeholders）提供单个产品 视图;通过监控和校正技术支持数据质量和规范。 ”Enterprise master patient index （EMPI），是针对于医疗行业CDI的一种形式。一些医疗组 织正在使用EMPI来合并系统之间的病人标识并将这些数据充实到更优分析的数据仓库中。EMPI目录一般包 括病人人口统计和病人所使用的器械，并且它们通常能够根据Gillogley Ser vices确定来自其它器械的信息 是否应该与已经存在的目录信息相匹配。数据管治（Data Governance）指的是企业使

32、用的数据的有效性、可用性、一致性和安全性的总体管 理。一个强大的数据管治程序将包括一个中央实体或委员会来创建管治规则、一套流程和一个完成这些流程的 规划。与数据管理不同的是，数据管理是数据管治主体策略的一次战术执行。客户数据整合（CDI）是整合和管理不同来源的客户信息的过程。客户信息可能包括合同细节、客户评 估数据和通过交互收集的信息（如，直接销售）。如果实施恰当， CDI 可以保证组织中所有相关部门能够持 续访问最新和最完整的客户信息。因此CDI是客户关系管理（CRM）的一个至关重要的元素。MDM 中心是一个数据库及管理数据库中主数据的软件并保持它与使用主数据的事务系统同步。关于 MDM中心

33、的最常见问题是“MDM中心是否能够同时处理客户和产品数据？。根据MDM专家Jill Dyche的观点，不同类型的MDM体系结构都有特定的优点和缺点。MDM体系结 构风格包括持久化、注册、混合、共存和事务。根据MDM专家意见，诸如协作的和“分析的MDM的词汇都只会混淆MDM的功能。开发MDM的 动因是主数据是如何存储、访问和传播到企业中的。而且，如果数据用法给MDM增加了复杂性时，第二个动 因就是组织使用和管理它的主数据的方式。在实现MDM系统后，专家建议不要太担心MDM投资回报（ROI）。相反，重要的是你的实现是如何 解决公司的数据管理问题，以及MDM系统是否有助于节省业务规划的开支。MDM

34、项目可能是一项复杂的工作，但如果有合适的专业人员可以使项目变得很顺利。主要的 MDM 人员 包括以下MDM角色：高级管理、业务客户、应用负责人、信息架构师、数据管治和数据质量人员、元数据 分析师、系统开发人员和运营人员。企业组织管理（Enterprise hierarchy management）是公司更新、建模和维护信息层次（如， 客户和/或产品信息）的地方。以前，当业务发生变化，如收购或重组，有关的组织层次必须在不同的分析系 统中更新以使报告精确。然而，新产品提供了一个独立部分来完成所有必需的修改，这些修改被发布到多个商 业智能(Business Intelligence, BI)或企业绩

35、效管理(Corporate Performance Management, CPM) 软件系统。开发一套MDM 度量来测量和演示MDM对于一个公司的影响是MDM项目成功的关键。然而，根据 Gartner Inc.分析师John Radcliffe的观点，这些度量应该关注于业务，而不是IT。比如，显示MDM有助 于增加客户数据 10%准确性的度量是不太可能影响到管理的;然而，显示客户保有和/或越区销售率增加的度 量将会产生很大的影响，因为它们是业务成功的关键。数据职能中心，或者称为数据管理职能中心，是一个组织内的一个小组(一般是一组以数据为中心和有 数据处理能力的专家)，它为MDM制定策略和流程

36、，并帮助在公司内部实施这些MDM规则。主数据管理和实施前言企业主数据是用来描述企业核心业务实体的数据，比如客户、合作伙伴、员工、产品、物料单、账户等；它是 具有高业务价值的、可以在企业内跨越各个业务部门被重复使用的数据，并且存在于多个异构的应用系统中。 本文将针对主数据管理的概念以及主数据管理解决方案的实施等方面跟大家作一个探讨。主数据和主数据管理的概念企业主数据可以包括很多方面，除了常见的客户主数据之外，不同行业的客户还可能拥有其他各种类型的主数 据，例如：对于电信行业客户而言，电信运营商提供的各种服务可以形成其产品主数据；对于航空业客户而言 航线、航班是其企业主数据的一种。对于某一个企业的

37、不同业务部门，其主数据也不同，例如市场销售部门关 心客户信息，产品研发部门关心产品编号、产品分类等产品信息，人事部门关心员工机构，部门层次关系等信 息。数据管理的范畴和主数据管理的概念图 1.数据管理的范畴如图所示，企业数据管理的内容及范畴通常包括交易数据、主数据以及元数据。 交易数据：用于纪录业务事件，如客户的订单，投诉记录，客服申请等，它往往用于描述在某一个时 间点上业务系统发生的行为。 主数据：主数据则定义企业核心业务对象，如客户、产品、地址等，与交易流水信息不同，主数据一 旦被记录到数据库中，需要经常对其进行维护，从而确保其时效性和准确性；主数据还包括关系数据 用以描述主数据之间的关系

38、，如客户与产品的关系、产品与地域的关系、客户与客户的关系、产品与 产品的关系等。 元数据：即关于数据的数据，用以描述数据类型、数据定义、约束、数据关系、数据所处的系统等信 息。主数据管理是指一整套的用于生成和维护企业主数据的规范、技术和方案，以保证主数据的完整性、一致性和 准确性 ( “ The set of disciplines, technologies, and solutions used to create and maintain consistent, complete, contextual and accurate business data for all stakeho

39、lders (users, applications, data warehouses, processes, companies, trading partners, customers, etc.) across and beyond the enterprise ” ) 。主数据管理的典型应用有 Customer Data Integration 客 户数据管理和 Product Information Integraiton 产品数据管理。图 2.主数据管理的信息流一般来说，主数据管理系统从 IT 建设的角度而言都会是一个相对复杂的系统，它往往会和企业数据仓库 / 决 策支持系统以及企

40、业内的各个业务系统发生关系，技术实现上也会涉及到 ETL、EAI、EII 等多个方面，如图 2 所示，一个典型的主数据管理的信息流为：1. 某个业务系统触发对企业主数据的改动；2. 主数据管理系统将整合之后完整、准确的主数据分发给所有有关的应用系统；3. 主数据管理系统为决策支持和数据仓库系统提供准确的数据源。因此对于主数据管理系统的建设，要从建设初期就考虑整体的平台框架和技术实现。 以客户主数据为例，常见的主数据域包括： Party:参与方。参与方包含的范围是所有与企业发生了或者发生过正式业务关系的任何合法的实体, 比如填写了投保单的参与方。 Party 是分类别的，可以是个人、机构和团体。

41、对于 Party 来说，因 为开展业务的需要，可能要对他们进行分级、分类，比如VIP，黑名单等。个人包括个人基本属性、 个人名称、职业、性别、教育等自然属性；机构是指在法律上有登记的组织实体，可以分为政府机构、 商业机构、非盈利机构等类别；团体可以有多种形态，比如他们可以是家庭、兴趣小组、某个大机构 中的一部分，或者通过某种数据分析技术得出的客户细分群体。 Party Role:参与方在业务中扮演的角色。例如，对于保险行业而言，可以有：投保人，被保人， 受益人，担保人，报案人，核保人，查勘员，核赔人等。 Relationship: Party 与 Party 之间的关系 ,例如可以是:夫妻关系

42、、父子关系、母女关系、兄弟 姐妹关系、总 （ 母 ） 公司分 （ 子 ） 公司关系、企业事业单位隶属、上下级关系等。 Account：帐户是客户使用企业服务的付费实体。 Location: Location 记录的是每个 Party 可能拥有的所有联系地址，地址的类别包括邮寄地址、 email 地址、电信联络地址等。 Contract： Party 与企业之间的契约。主数据有几个鲜明的特点，其中包括：它是准确的、集成的，其次它是跨业务部门的，再有就是它是在各个业 务部门被重复使用的。主数据管理的意义图 3.主数据管理的要素如图 3 所示：集成、共享、数据质量、数据治理是主数据管理的四大要素，主

43、数据管理要做的就是从企业的 多个业务系统中整合最核心的、最需要共享的数据（主数据），集中进行数据的清洗和丰富，并且以服务的方 式把统一的、完整的、准确的、具有权威性的主数据分发给全企业范围内需要使用这些数据的操作型应用和分 析型应用，包括各个业务系统、业务流程和决策支持系统等。主数据管理使得企业能够集中化管理数据，在分散的系统间保证主数据的一致性，改进数据合规性、快速部署 新应用、充分了解客户、加速推出新产品的速度。从 IT 建设的角度，主数据管理可以增强 IT 结构的灵活性 构建覆盖整个企业范围内的数据管理基础和相应规范，并且更灵活地适应企业业务需求的变化。以客户主数据为例，客户主数据是目前

44、企业级客户普遍面临的一个问题，在大多数企业中，客户信息通常分散 于 CRM 等各个业务系统中，而每个业务系统中都只有客户信息的片断，即不完整的客户信息，但却缺乏企业 级的完整、统一的单一客户视图，结果导致企业不能完全了解客户，无法协调统一的市场行为，导致客户满意 度下降，市场份额减少。因此，建立客户主数据系统的目的在于： 整合并存储所有业务系统和渠道的客户及潜在客户的信息：一方面从相关系统中抽取客户信息，并完 成客户信息的清洗和整合工作，建立企业级的客户统一视图；另一方面，客户主数据管理系统将形成 的统一客户信息以广播的形式同步到其他各个系统，从而确保客户信息的一致； 为相关的应用系统提供联机

45、交易支持，提供客户信息的唯一访问入口点，为所有应用系统提供及时和 全面的客户信息；服务于 OCRM 系统，充分利用数据的价值，在所有客户接触点上提供更多具有附 加价值的服务； 实现 SOA 的体系结构：建立客户主数据系统之前，数据被锁定在每一个应用系统和流程中，建立主 数据管理系统之后，数据从应用系统中被释放出来，并且被处理成为一组可重用的服务，被各个应用 系统调用。主数据管理系统与数据仓库系统的关系 主数据管理系统与数据仓库系统是相辅相成的两个系统，但二者绝不是重复的，也不是互斥的。它们有很多共 同之处： 首先二者对企业都具有相同的价值，可以减少数据冗余和不一致性、提升对数据的洞察力，二者都

46、是 跨部门的集中式系统； 其次二者都依赖很多相同的技术手段，都会涉及到 ETL 技术、都需要元数据管理、都强调数据质量 第三就是二者建设手段类似，都需要数据治理的规范作为指导、都需要不同系统、不同部门的协作、 需要统一的安全策略。但是，主数据管理系统和数据仓库 / 决策支持系统二者之间也存在很多不同： 处理类型不同：主数据管理（MDM）系统是偏交易型的系统，它为各个业务系统提供联机交易服务， 系统的服务对象是呼叫中心、B2C、CRM等业务系统；而数据仓库是属于分析型的系统，面向的是 分析型的应用，是在大量历史交易数据的基础上进行多维分析，系统的使用对象是各层领导和业务分 析、市场销售预测人员等

47、； 实时性不同：与传统的数据仓库方案的批量ETL方式不同，主数据管理系统在数据初始加载阶段要 使用ETL,但在后续运行中要大量依赖实时整合的方式来进行主数据的集成和同步； 数据量不同：数据仓库存储的是大量的历史数据和各个维度的汇总数据，可能会是海量的，而 MDM 存储的仅仅是客户和产品等信息。虽然主数据管理系统和数据仓库系统异同共存，但是二者却有着紧密的联系，并且可以互为促进、互为补充。 举例而言，数据仓库系统的分析结果可以作为衍生数据输入到MDM系统，从而使MDM系统能够更好地为 操作型 CRM 系统服务。以航空公司为例，客户的主数据模型大致可以分为三部分：首先包括客户基本信息和偏好信息。

48、客户基本信息： 个人及公司信息 消费者市场状况 常旅客会员卡号，状态，及累计里程等 客户间关系 （ 个体 - 个体，个体 - 公司 ） 联系地址，包括电话，电子邮件等 客户偏好信息： 餐食偏好 是否吸烟 座位偏好 机型偏好 公务舱位偏好 旅行舱位偏好 休息室服务偏好除了这两部分之外，我们还可以从数据仓库系统中提取相关的信息，作为客户主数据的衍生信息部分，从而更 好地、全方位地描述客户特征，这些可以包括： 衍生信息： 本月飞行里程 年度飞行里程（最近 12 个月内） 提前预订倾向 习惯预订模式 使用自主服务倾向 上次预订使用的信用卡号 累计 / 本月转签 / 取消航班次数 转签航班倾向 取消航班

49、倾向 No Show 倾向等。主数据管理系统和 ODS 的关系在某些情况下，主数据管理系统和 ODS 系统可能容易被混淆，的确，从实时上来看，主数据管理系统和 ODS 系统存储的都是实时数据，但是二者存储的数据内容是全然不同的，主数据管理系统中不存储交易数据 比如银行客户的交易流水信息是不应该放在主数据管理系统中进行管理的，这与 MDM 与 ODS 的一个很大 区别。举一个航空公司的例子，比如某个客户在电子商务网站上定了一张机票，产生一个订单，然后他又通过 呼叫中心要求改签，这个场景中，两个系统之间要实现客户信息和订单信息的共享，其中客户信息共享通过 MDM 系统来实现，而订单信息则需要采用

50、ODS 或其它手段进行共享，我们是不推荐把此类信息交由 MDM 系统来管理的。主数据管理解决方案介绍目前业界比较常见的主数据管理解决方案主要可以分为三类： 第一是依托专业套装软件来实现主数据管理，这类方案是作为套装软件的一部分，主要是为套装软件 的其它模块提供服务的，因此，通常功能都缺乏完善性。 还有一类是侧重于分析型应用的主数据管理，这类方案在数据实时同步以及面向交易型应用时通常缺 乏整体方案的完整性。 再有一类就是专注于主数据管理的中立的、完整的解决方案，这一类应用独立于套装软件，不仅具有 整体架构的完整性和先进性，从功能上讲往往也最为完善，除了具有比较完整的数据模型 (Data Mode

51、l) 之外，还会提供广泛的集成性，具备先进的机制实现数据同步，并且可以对外提供多种预置 的主数据服务被外部交易系统调用，从而使系统具有很强的实时操作性，同时还强调主数据管理、主 数据质量控制以及主数据维护的手段和规范性。企业主数据管理系统逻辑架构一个完整的主数据管理解决方案的逻辑架构应如下图所示：图 4.主数据管理系统逻辑架构Partnersunnnhrtidl & hcrymentjl LojdsLQBU.I.EadibbBrtiEHalt r DJta Haigemeitae nticfExternal ParticipantsSi Parbiar. Cu ctoniBr; Eupply

52、Oialn Data. ein.邓myERF；日upplf Chain. CF3I. B-b.UU.ptBTBiktsrmsDdi litegistbi dulcetEO*HlSc nite在一个完整的主数据管理解决方案中，除了主数据管理的核心服务组件之外通常还会涉及到企业元数据管理、 企业信息集成、ETL、数据分析和数据仓库以及EAI/ESB等其他各种技术和服务组件。其中主数据管理服务又包括如下一些主要的服务组件： Interface Services：为企业中需要主数据的所有业务系统提供各种服务接口，通过实时的、批 量的接口可以读取或者修改主数据，这些接口包括 Batch, Web Ser

53、vices, XML Interface, Messaging Interface, Publish/Subscribe, Import/Export Services, Data Standardization Interface, Directory Integration 等。除了这些标准的技术接口之外 , 对于某些专有系统还提供适 配器 (Adapter) 接口 , 通过适配器接口可以和一些特有的系统做接口，例如企业中的传统 (Legacy) 应用系统或者 SAP 等打包应用。 Lifecycle Management Services: 履行针对主数据的 CRUD 操作，执行对主数据

54、存储库中的 数据进行更新、存取和管理时的业务逻辑，除此之外，它还负责维护主数据的衍生信息，例如客户之 间的关系、客户的偏好、客户在各种客户服务渠道上的行为轨迹等。 Lifecycle Management Services 贯穿整个主数据管理的生命周期，它利用 Data Quality Management Services 来确保 数据质量、利用 Master Data Event Management Services 来捕获各种主数据变化等相关的事 件，以及利用 Hierarchy and Relationship Management Services 用来维护数据实体之间的关 系和层

55、次。 Data Quality Management Services：确保主数据的质量和标准化，这在主数据管理解决方 案中一个非常重要的组件，在我们从各个业务系统获取数据之后，要对数据进行清洗和验证，例如对 于地址而言，要弥补地址的缺失、地市的缺失、邮编的缺失、进行地址的标准化等。对于其他数据要 进行非空检查、外键检查、数据过滤等。然后要对数据进行匹配 / 重复识别、自动进行基于规则的合 并 /去重、交叉验证等，并且还要遵从企业的数据管控规范和流程。它可以是 Master Data Management Services 的一个内部组件，也可以调用整个企业的 Information Inte

56、grity Services 来实现。 Authoring Services：依据数据管控流程，定义和扩展企业的主数据模型。 Hierarchy Relationship and Management Services ：定义数据实体的层次 (Hierarchy), 分组 (Grouping), 关系 (Relationship), 版本 (Version) 等。 Master Data Event Management Services ：捕获事件并且触发相应的操作，包括事件发现 事件管理和通知功能，它在主数据管理系统和业务系统之间进行数据同步时起到至关重要的作用。 Base Service

57、s：提供通用服务，包括安全控制、错误处理、交易日志、事件日志等功能。 Master Data Repository:主数据存储库，包括 Metadata, Maste r Data, Histo ry Data, Reference Data 等。下面我们介绍两个这些逻辑组件之间的协作场景：图5.场景1-初始数据加载_wl“QJEL Sh 咼=”_.-Erfract 邑ILOB SystemI fC ustcirn. I_已gac1 & Fackagsdj_T. !Im i ori.m vt.F LI,0址ICent ent M anagH-errt !u i i uu nUhstFUEtUF

58、QdD at日 Q ualtyM 鬥 口 門口 enE ntstegi ng S H场景 1：初始数据加载：1. 源数据从外部业务系统及 EDW 系统中通过批处理方式拷贝到磁带；2. 数据被加载到Staging DB,进行数据质量分析；3. Data Quality Management Services 对数据进行清洗、匹配、标准化等；4. ETL Transform and Load services 对合格数据进行转换并准备好加载数据；5. Master Data Interface Services 接收批处理更新请求,调用 Lifecycle Management Update Se

59、rvice 进行数据的批量更新；6. Lifecycle Management Update Service 调用 Hierarchy & Relationship Management Services 和 Base Services 更新主数据库。图6.场景2-主数据库更新，然后同步到各业务系统场景 2：主数据库更新，然后同步到各业务系统1. 某业务系统发起一个创建主数据的交易，该业务系统将交易数据以消息的形式发送到消息队列；2. MDM Interface Services 捕获该消息，进行消息解析，并调用 Security and Privacy Services 进行权限验证；3.

60、MDM Interface Services 调用 Lifecycle Mgmt. Update Service ；4. Lifecycle Mgmt. Update Service 再调用 Data Quality Management Services 进行数据的清 洗和标准化；5. Update Service 调用 Search Services 发现该主数据已经存在，确认这是对已有主数据的更新操 作；6. Update Service 通过调用外部系统对数据进行扩充；7. Update Service 在更新主数据库之前调用 Event Management Services ；8.

61、 Event Management Services 确认是否需要涉及数据管控方面的处理；9. Update Service 调用 Hierarchy & Relationship Management Services 并且更新主数据库；10. Audit Logging Services 纪录相应交易日志和历史数据；11. MDM Lifecycle Management Service 调用 MDM Interface Services 返回更新处理请求；12. 源业务系统接收到处理请求之后，利用 MDM 系统发回来的数据对本地的应用系统数据库进行更新 操作；13. 其他所有需要主动被更

62、新的相关的业务系统都会接收到更新后的最新数据。IBM 主数据管理解决方案IBM 的主数据管理解决方案 InfoSphere Master Data Management 是 IBM 信息管理大家族的一员。manage evertsActionKnowiedae Master ProfileIntBflritvMaintains sine record尸ne nt Se rverIBM Master Data图 7. IBM InfoSphere MDM Server 产品构成I: DotH Cover rance Rules o1y ability如上图所示， IBM MDM Server 包

63、含： Knowledge（知识层）：知识层包括当事方（人员和组织）、角色、地址位置、当事人属性（统计 学信息）、关系、财务简档、多渠道集成、协议和产品、事件等。 Action （交互层）：MDM Server本身就是按照SOA的体系结构设计的，它提供700多个开箱 既有的服务接口，这些服务可划分为多个主题范围，如下图所示：图 8 MDM Server Business Services店FrVCferrngraphc&rvic：e3+：+：* *-Rotei-iHlataj S&McegEiirini 访Hilf占HdHUUmFBtrnrirawiirvtvnriDHtavniTritnriD

64、HEMBtfl fhdvuihrrirtrH*匚尽乜 %a.vaidahipSarvicesF 占 rty FfelsticirBHpte-rvicea I 11D IKOvWS?Wv-WHinrtEMkHBmuBMtonMHiiia卩 血fRikRiMnMpLlHlFnAEBETnmmnTTffffTTmTrFrtijf FirBreBl Phofite隹i rvfceatTrWTIMTWtTtffltfiTtTtTtTtTtTrrtTtStTtWtTFsrty Idmntifcartio n 哉Di recto ry Efervic册U* MmirtCu ntidi：f 屈rvi 吕.friiat.rrtfict w HkrwtfvErtHtLmHUriiaLDVVMHt UftlElFiltJiHriEntri rf F* ihiJ f Eq