主数据管理(Master Data Management)基础

 

什么是Master Data(主数据)?

无论是银行、零售商或者政府机构，一个机构内部总有一组核心的数据，各种应用均会使用。 此类数据我们便称为“Master Data（主数据）”。Master Data 代表着核心商业对象，商业事务会围绕着这些对象开展。常见的例子有：customer（客户）、employee（员工）、supplier（供应商）、product（产品）、location（地址）和contract（合同）。哪些种类的信息会视为masterdata，不同行业和不同机构间会存在诸多差异。

 

可以问一简单的问题来确定某类数据是否可以作为MasterData：这类数据将会有超过一个以上的transactionalapplication(事务型应用)使用吗？如果是，便可以作为Master Data。

 

什么是MDM(Master Data Management)?

在理想世界里，一个机构仅有一地存储和管理MasterData。这那里MasterData是精确和一致的，被安全且条理地维护着。所有更新只会针对此单一的MasterData。所有使用MasterData的用户只和这个权威的信息源交互。

 

MDM就是实现这个理想世界的过程和技术框架，它创建和维护一个权威的、可靠的、可持续的、精确的、安全的数据环境，形成一个一致的MasterData视图。

 

MDM的好处

在IT领域内有一股实施MDM的驱动力。通常情况下，应用程序是为支持某个业务领域的运营过程而设计的，它们拥有自己的信息技术设施，包括与应用相关的数据存储和定义。结果是：信息共享越多，我们越是发现多年来横跨业务线的分布式计算和应用已经形成了“信息孤岛”。 当依赖应用的Master Data的拷贝数量不断增加时，通过点对点连接方式同步数据会变得很复杂，整个环境也变得很难维护。与此同时，很难控制信息的一致性和数据的质量了。

 

为了解决上述问题，我们需要为机构的信息集成、管理和共享提供一个系统化的解决方案。MDM便是方案之一。

 

像其他重要的IT趋势，MDM对生产率改善、风险管理、成本降低等方面均有显著的好处。更加准确得讲，MDM通过支持依赖以下益处的业务项目来证明自己的价值：

(下面的文本来自DavidLoshin的著作, Master Data Management, by [Lobshin09])

 

 

1.      全面的客户知识

内部开发各种应用系统经常会采用不同的方式支持相同类型的客户数据功能。例如某银行可能有多种客户接触界面：支行、ATM、MAIL、Internet、电话和短信。其中的任意一个应用均会创建、更新和停用客户信息。但是在一个相互不协作的环境下，应用就无法知道准确全面的客户信息，包括：唯一客户的数量、客户与银行交互的喜好、客户是如何尝试不同的途径来完成交易的。单一的MasterData存储为所有客户的活动数据提供了单一的来源，采用统一的方式支持各种运营和分析应用。 如果一个企业拥有了完整一致的客户视图，便能提供更加丰富的个性化服务和恰当的处置。这样便能产生更好的客户体验，降低客户流失率。

 

2.      增强竞争力

在资源有限的情况下，企业需要快速产生新的业务能力，迅速抓住新的商业机会。MDM降低了集成新数据和系统的复杂性，因此能有利于提高企业的敏捷性和竞争力。

 

3.      改进运营效率，降低成本

复制相同的数据经常带动复制相关的管理数据的活动，包括：典型的日常数据管理工作（备份和维护）、增加设施的license成本（比如RDBMS, ETL产品的license和维护成本），特定的应用工具和服务。统一的数据视图能让企业降低重复出现的运营成本和任务。

 

4.      一致的报表

报表间的不一致源自信息处理流程的治理缺乏和各环节上有差异的复制和复杂转换。受治理的使用MasterData的信息处理过程能降低报表间的不一致。

 

5.      提高信息质量

由标准化模型、数值域(valuedomain)和商业规则等组成的元数据能帮助企业更加有效地监控跨越多个垂直应用的信息质量控制情况，降低信息的碎块化和重复劳动。

 

6.      提高实施速度

MDM提供了信息资产的标准化视图，这减少了抽取和转换数据的延迟， 加速了各种项目的实施进度：应用迁移、系统升级、数据仓库(datawarehouse)/数据集市(datamart)。

 

7.      简化应用系统开发

MDM的合并工作不仅仅限制在数据领域。当多个MasterData Object合并到一个主存储(MasterRepository)时,就会有可能合并与数据的生命周期相关的应用系统的功能。例如，一个企业中可能会有多个系统负责录入新产品数据到不同的产品数据库，可以把这些产品管理功能合并，提供单一创建新产品功能服务，让不同的应用调用。引入类似的数据服务层为SOA构架提供了必要的抽象。

 

8.      更好的费用分析和规划

与产品和供应商等相关的MasterData 能够帮助企业改进以下工作：采购工作、协调竞争性的外包(competitivesourcing)、预测未来的费用、改进供应商管理 等等。

 

PIM, CDI 和 Multi-Domain MDM

如果MDM只关注在产品或者服务的定义和生命周期，此类MDM也成为PIM(ProductInformation Management)。

 

如果MDM只关注在管理客户相关的信息，此类MDM也经常被称为CDI(CustomerData Integration)。实际上CDI并不局限在客户信息这个范畴，“客户customer”一词已经演变为泛指相关的人和机构，统称“party”。

 

如果MDM局限在某个一个domain(主题域)，比如PIM和CDI，称为single-domain的MDM。如果MDM要涉及多个domain，此类MDM称为 multi-domain MDM。

 

从信息集成的角度看，multi-domainMDM是需要全面信息集成的公司的最终选择，因为会覆盖到多个种类(domain)的Master Data。Single-domain方案最终会演变成multi-domain，因为其他的主题域的数据会逐渐加入进来。

什么是MDM系统?

下文主要总结自 [Dreibelbis+08].

MDM系统是MDM的技术基础。不同系统会管理不同各种类型的Master Data，而且MDM系统的实现和使用方式会有很变化。此节我们描述MDM解决方案的三个主要维度，如图1显示：

 

图1 MDM的维度

 

Master Data 类型(Domains)

不同的行业和不同的机构均可能有不同类型的MasterData。 一个MDM系统应支持一个或者多个Domain的Master Data。这些Domain应该是通用的，与行业无关，可以被裁剪或者映射到不同的行业标准或者模型。在设计和实现MDM的时候，这些Domain的定义也能被进一步定制和扩展。

Methods of Use(使用方式)

有三类关键的使用方法(模式)：CollaborativeAuthoring(协同型),Operational（操作型）和Analytical（分析型）。MDM实施初期可能会采用一个最能满足商业需求的使用模式，然后逐渐扩展到其他使用模式。

Collaborative MDM(协同型MDM)

在协同模式中，MDM系统协调一组用户和系统，对Master Data 达成一致。由于产品开发和管理的复杂性，PIM系统通常会支持此类使用方式。也许最常见的一个PIM过程便是引入一个新产品。一个简化的新产品的引入流程如图2显示。

图2 简化的新产品引入流程

 

协同模式要求MDM具备一组核心的功能，包括：工作流，任务管理和状态管理等。

 

Operational MDM(操作型MDM)

在操作型模式中，MDM参与日常的操作事务和商业流程，与其他应用系统和人员直接交互。

 

操作型MDM关注如何在提供高性能的无状态服务。这些无状态服务能被业务流程调用，或者直接被应用系统和用户界面调用。操作性MDM的服务经常会被设计成既能支持SOA 也能支持传统环境。此类MDM与现有系统的集成需要各种类型的通讯风格和协议，包括同步和异步的，也包括全局事务(globaltransaction)和单向通讯等等。

 

Analytical MDM(分析型MDM)

在分析型模式中，MDM系统是下游分析型系统的权威信息来源，很多时候MDM系统自己也会产生分析结果。

 

分析型MDM是Business Intelligence (BI) 和 MDM的交集。此处的BI是指一个宽泛的领域，包括了商业报表、数据仓库、数据集市、数据挖掘等。无一例外的，所有形式的BI均需要有意义的可信赖的数据。

 

MDM 和BI有三个主要的交集：

1.      MDM作为一可信赖的数据源：MDM的关键角色是为BI系统提供干净的一致的数据。

2.      MDM Data分析：MDM自己会集成报表和分析功能，提供Master Data的分析结果。

3.      MDM系统提供关键性的特定类型的分析：例如identityresolution(身份识别)可能成为某些MDM系统的关键特性。

MDM Implementation Styles(实现风格)

此节，我们介绍4类实现风格：

1.Consolidation Implementation Style(合并风格)

2. Registry Implementation Style(登记风格)

3. Coexistence Implementation Style(共存风格)

4. Transactional Hub Implementation Style(事务HUB风格)

 

从 Consolidation Implementation Style 到 Transactional Hub Implementation Style，功能逐渐增加，部署的复杂性也逐渐增加。不同的实现风格之间是互补和可叠加的。

下面图片显示了本节使用的图形标记的意义：

Consolidation Implementation Style(合并风格)

如图3显示，此实现风格把现存系统（包括数据库和应用）的Master Data合并到一个单一的受管理的MDM hub。在这过程中，数据被转换、清理、匹配和集成，形成完整的goldenrecord（黄金记录）。这个goldenrecord 为下游系统的报表和分析工作提供可信赖的数据来源，或者作为其他操作性应用的参照数据。MDM系统是一个只读的系统，数据改变主要来自源系统。

图3 Consolidation Implementation Style（合并风格）

 

这是一个为分析型应用提供有价值数据的解决方案，自然和简单。但是，也存在明显的缺点：

1.      MDM系统不包含最新的信息。

2.      缺乏弹性。不能加入额外的信息，除非根据需求修改现有的应用。

 

Registry Implementation Style(登记风格)

此实现风格假设源系统能够管理好自己数据的质量。如图4显示，MDM系统只管理最小量的信息，用来唯一标识MasterData，并提供在其他系统和数据库中详细数据的引用。

 

查询此类MDM系统需分两步动态装配信息。首先，在MDM系统中找到需要的信息，然后用获得的identity和引用信息，从源系统中提取详细信息。

 

图4 Registry Implementation Style(登记风格)

 

 

此实现风格有以下优点：

1.      实施快

2.      能提供实时信息

3.      适用于某些复杂的环境：如果一团体不能提供所有的数据，这个风格就特别有用。

 

在实施前必须考虑以下问题：

1.      除了基本的identity，不能解决数据质量问题。

2.      对现有系统的性能和可靠性特别敏感。

3.      需要严格管理MDM系统和源系统之间的关系，因为源系统的单方面修改会造成MDM系统产生问题。

 

Coexistence Implementation Style（共存风格）

图5显示的是共存风格的实现结构，允许在许多地方编写和存储MasterData，包括MDM系统。MDM系统使用与ConsolidationImplementation Style(合并风格)类似的方法从源系统获取并构造全局的Master Data Record。在MDM系统中可以查询和更新这个全局的MasterData Record。全局的MasterData Record的更新可以反馈到源系统中,也可以发布给下游的系统。

 

图 5 Coexistence Implementation Style(共存风格)

 

此风格的优点是能提供全部的MDM功能，但是不会大幅度改变现有的环境。缺点是存在MDM系统以外的MasterData 编写和更新，MDM系统中的数据不是最新的。

 

Transactional Hub Implementation Style(事务HUB风格)

在此风格中，MDM系统是唯一能管理Master Data的地方。现存的系统通过MDM的服务接口更新MasterData。 在MDM系统中，MasterData 被清洗、匹配和扩充，从而保证数据的质量。

 

一旦更新被接受后，MDM系统会把这些改变分发给对此感兴趣的应用和用户。可以通过消息方式，也可以批量的方式 发布这些改变信息。

 

这个风格的好处是任何Methodof Use (使用方式)均可以实施，包括：collaborative, operational 和 analytical。

 

不利的地方是：高成本和复杂度。所有的更新均会导向MDM系统，这意味着现存应用、商业流程、甚至机构结构也要相应发生变化。

 

MDM的关键功能

下文主要来自[Dreibelbis+08].

此节把MDM的主要功能分为四类：

1.      Master Data Lifecycle Management（Master Data 生命周期管理）

2.      Data Quality Management（数据质量管理）

3.      Master Data Harmonization（Master Data 谐调和统一）

4.      Analysis and InsightCapabilities（分析功能）

针对某个特定的MDM方案，需要根据业务需求和现有的IT环境，从中挑选合适的功能。

Master Data 生命周期管理

为了保证MasterData 它的生命周期内被有效管理和利用。MDM系统必须能提供以下类型的功能：

 

1.      从新建直到数据停用，MasterData均能在MDM系统得到管理。

2.      能分组和定义MasterData 实体间的层次关系。

3.      灵活管理不同MasterData domain间的复杂的关系。比如 产品VS供应商，客户VS账户和地理位置。

4.      能定义MasterData间的层次、关系和分组。手工方式或者自动方式(从外部系统获得诸如公司和机构、人员和机构等之间的关系)

5.      有版本管理能力，能明白MasterData 实体的状态是如何随时间变化的，

6.      有编写能力，能定义，管理，定制和扩展不同的类型的MasterData。

7.      能够迅速增加新的MasterData。比如增加多渠道属性(multichannelattribute)，隐私偏好(Privacypreference)，还有存在但是尚未在企业应用中捕获的各种事件。多渠道属性可标记客户与企业最近一次交互的日期和时间，客户可能是通过客服代表，电话 或者Internet与企业接触的。隐私偏好标记客户的个人信息能不能在多个业务线间共享。

8.      支持多种层次结构。比如产品的分类：可以从购买者的角度分，也可以从销售的角度分。

9.      能维护数据的来源，标记出与MDM系统中的Master Data实体相关联的MasterData的存储位置。MDM系统可能不存储所有的与Master Data实体相关的信息，仅包含了一些需要集中维护的属性。

10.  必要的MDM安全和隐私机制。

11.  必要的审计(Audit)功能，帮助管理员了解修改Master Data 的相关信息：“who,” “what,” “how,” and “when”。

数据质量管理

1.      需要有作数据分析和概要 (analysis and profiling)的能力。这有利于了解源系统中MasterData的质量和结构，确认必要的清理和合并规则。数据概要(DataProfiling)能力提供了建立数据质量基线(baseline)的方法，用以评估Master data的质量的改进程度。

 

2.      能基于一致的数据标准化、校验和清理逻辑 改进Master Data的数据质量。这要求定义和实施一致的数据清理和校验规则，为数据域指定标准化逻辑，比如姓名和地址。

 

3.      数据调谐(Datareconciliation)：能自动调谐MasterData实体，比如：客户和产品。 要组合deterministic和probabilistic的匹配功能，定义在合并多个Master Data记录时的存留规则(survivorship rule)。

 

4.      数据治理能力：在发生数据冲突时，管理MasterData间的调谐，实施更新关键MasterData的数据质量策略。

 

5.      能测量数据的失效程度(staleness)，定期更新和重新评估Master Data的数据质量。

 

Master Data协调(Harmonization)

此功能支持：1.业务系统与MDM系统的集成；2. 通过数据和系统集成技术在企业范围内分发MasterData。

 

1.      集成功能加强共享、合并和分析MasterData的能力。例如，通过使用同步和异步技术，比如：消息、WebService、ETL和FTP等等，MDM系统内功能从业务系统处接收到Master Data的更新。

 

2.      MDM系统能支持EAI(EnterpriseApplication Integration), ETL和EII(EnterpriseInformation Integration)同步信息，包括MDM系统与业务系统之间的信息同步和支持业务流程

 

3.      基于MDM提供的知识，能够从业务系统中移除Master Data的内容。例如MDM系统发现某个客户不再活跃了，并且所有规定的条件均满足移除要求了。

 

4.      必须具备自动或者手工的错误处理功能，应对企业内MasterData同步发生故障。例如，当某业务线系统不能成功收到和处理最近的MasterData更新的时候，必须采取一些行动，无论是手工的或者是自动的。

 

5.      MDM方案能支持高吞吐量的事务环境，实现实时处理和高可用性。

 

分析能力

1.      分析能力：需要发现各种蕴含的关系，包括明显的和不明显的，从而支持业务决策。比如谁属于同一户(Household)，了解消费模式，交叉销售(cross-sell)和上拽销售(up-sell) 机会。

 

2.      有能力从各分支机构处获得最新的MasterData，改进全局的业务决策。

 

3.      能够提供分布于多个数据源的某个MasterData 实体的结构和非结构化信息。

 

4.      协同能力：管理流程的状态的能力，这个流程的一系列任务由人或者系统驱动。

 

5.      能配置事件管理服务：定义事件发生和产生提醒的各种条件。

 

CRM和MDM的关系

MDM是机构的一项重要的信息管理能力。MDM方案的目的是创建单一的存储（也许是虚拟的），存放高质量的MasterData，提供给各种应用系统一个同步的，一致的机构数据视图。

对于CRM(Customer Relationship Management)，我们采用AdrianPayne在

HANDBOOK OF CRM: Achieving Excellence inCustomer Management (Elsevier Butterworth Heinemann,2005) 的中的定义：

“CRM是一个战略性的方法，通过发展与关键客户和客户群的恰当关系来获得更好的股东价值（公司价值）。CRM把IT和关系营销结合起来，与客户建立长期的，有利可图的关系。CRM提供了利用数据和信息了解客户并和他们一起共建价值的机会。CRM要求跨职能集成流程，人员和运营 和 营销能力，这需要通过信息、技术和它们的应用来实现。”

 

从上述定义，我们知道CRM需要跨职能集成流程，人员和运营 和 营销能力。因此MDM是一项强化CRM能力的必要的信息管理能力。没有对客户数据的一致的视图，CRM的价值将大打折扣，甚至对企业有负面影响。

 

为了帮助大家理解为什么MDM对CRM如此重要，我从http://hubdesignsmagazine.com/2010/06/10/mdm-crm-erp/处摘取了一些颇为有趣的但是实在的观点：

 

“如果CRM和ERP能更好的管理MasterData,或许我们就不需要MDM了。”

 

“设计这些应用系统的年代是不考虑面向全局信息需求的。”

 

“很不幸，大部分CRM和ERP的运营假设是：整个企业的运营都要让它管理”

 

“这导致了数据孤岛(datasilo)，造成了企业信息分析和管理的很多问题。”

 

“这就是为什么MDMhub存在原因。它提供了为客户、产品和其他MasterData提供了一个中立的、负责创建、读取、更新和管理的地方 ”

 

“现今的CRM和ERP逐渐在和MDMHub结合。即使在今天，CRM和ERP产品的设计并不能有效管理MasterData。它们没有内置的数据质量和治理的流程，确保提供一个精确、完整、及时和一致的MasterData视图。”

EAI(Enterprise Application Integration) 和 MDM的关系

通过几代技术创建了自动化孤岛后，用户和管理人员便产生了要把它们桥接在一起的需求。 效果上他们想把这些应用联合为一个单一的企业级应用。EAI让现存封闭的系统共享流程和数据，从而解决这个需求。引用GartnerGroup的定义：EAI是：在联接的应用系统或者数据源之间无约束共享数据和业务流程。

 

EAI 假设应用系统自己能很好管理MasterData的数据质量。EAI只解决应用系统间的同步问题。很不幸，在一个分布式环境下，如何管理MasterData的数据质量一直存在着，甚至已经成了噩梦。

 

MDM从业务操作层面解决这个数据质量问题。它结合了类似数据仓库/数据分析等技术。 为了呈现一致的MasterData 视图，MDM系统必须有存储和管理Master Data的能力，共享给其他应用系统使用。MDM与这些应用系统的有效沟通需要EAI的帮助。

 

因此，MDM和EAI的关系是互补的。

 

References and Resources

Lobshin09

David Loshin, Master Data Management, The MK/OMG Press Series, Morgan Kaufmann, 2009

Dreibelbis+08

Allen Dreibelbis, Eberhard Hechler, Ivan Milman, Martin Oberhofer, Paul van Run, Dan Wolfson, Enterprise Master Data Management: An SOA Approach to Managing Core Information, IBM Press, First edition (June 15, 2008).

ORACLE11

Master Data Management, An Oracle White Paper, September 2011

http://www.oracle.com/us/products/applications/master-data-management/018876.pdf

 

Linthicum99

David S. Linthicum, Enterprise Application Integration, Addison Wesley,1999