主数据管理(MDM)的成熟度

MDM全写Master Data Management，翻译为主数据管理或元数据管理。

什么是MDM？

企业主数据是用来描述企业核心业务实体的数据，比如客户、合作伙伴、员工、产品、物料单、账户等；它是具有高业务价值的、可以在企业内跨越各个业务部门被重复使用的数据，并且存在于多个异构的应用系统中。

主数据和主数据管理的概念

企业主数据可以包括很多方面，除了常见的客户主数据之外，不同行业的客户还可能拥有其他各种类型的主数据，例如：对于电信行业客户而言，电信运营商提供的各种服务可以形成其产品主数据；对于航空业客户而言，航线、航班是其企业主数据的一种。对于某一个企业的不同业务部门，其主数据也不同，例如市场销售部门关 心客户信息，产品研发部门关心产品编号、产品分类等产品信息，人事部门关心员工机构，部门层次关系等信息。

如图所示，企业数据管理的内容及范畴通常包括交易数据、主数据以及元数据。

交易数据
用于记录业务事件，如客户的订单，投诉记录，客服申请等，它往往用于描述在某一个时间点上业务系统发生的行为。

主数据
主数据则定义企业核心业务对象，如客户、产品、地址等，与交易流水信息不同，主数据一旦被记录到数据库中，需要经常对其进行维护，从而确保其时效性和准确性；主数据还包括关系数据，用以描述主数据之间的关系，如客户与产品的关系、产品与地域的关系、客户与客户的关系、产品与产品的关系等。

元数据
即关于数据的数据，用以描述数据类型、数据定义、约束、数据关系、数据所处的系统等信息。

主数据管理是指一整套的用于生成和维护企业主数据的规范、技术和方案，以保证主数据的完整性、一致性和准确性 。主数据管理的典型应用有客户数据管理和产品数据管理。

主数据管理的信息流

一般来说，主数据管理系统从 IT 建设的角度而言都会是一个相对复杂的系统，它往往会和企业数据仓库 / 决策支持系统以及企业内的各个业务系统发生关系，技术实现上也会涉及到 ETL、EAI、EII 等多个方面，如图 2 所示，一个典型的主数据管理的信息流为：

某个业务系统触发对企业主数据的改动；
主数据管理系统将整合之后完整、准确的主数据分发给所有有关的应用系统；
主数据管理系统为决策支持和数据仓库系统提供准确的数据源。
因此对于主数据管理系统的建设，要从建设初期就考虑整体的平台框架和技术实现。

MDM的意义

集成、共享、数据质量、数据治理是主数据管理的四大要素，主数据管理要做的就是从企业的多个业务系统中整合最核心的、最需要共享的数据（主数据），集中进行数据的清洗和丰富，并且以服务的方式把统一的、完整的、准确的、具有权威性的主数据分发给全企业范围内需要使用这些数据的操作型应用和分析型应用，包括各个业务系统、业务流程和决策支持系统等。

主数据管理使得企业能够集中化管理数据，在分散的系统间保证主数据的一致性，改进数据合规性、快速部署新应用、充分了解客户、加速推出新产品的速度。从 IT 建设的角度，主数据管理可以增强 IT 结构的灵活性，构建覆盖整个企业范围内的数据管理基础和相应规范，并且更灵活地适应企业业务需求的变化。

以客户主数据为例，客户主数据是目前企业级客户普遍面临的一个问题，在大多数企业中，客户信息通常分散于 CRM 等各个业务系统中，而每个业务系统中都只有客户信息的片断，即不完整的客户信息，但却缺乏企业级的完整、统一的单一客户视图，结果导致企业不能完全了解客户，无法协调统一的市场行为，导致客户满意度下降，市场份额减少。因此，建立客户主数据系统的目的在于：

整合并存储所有业务系统和渠道的客户及潜在客户的信息：一方面从相关系统中抽取客户信息，并完成客户信息的清洗和整合工作，建立企业级的客户统一视图；另一方面，客户主数据管理系统将形成的统一客户信息以广播的形式同步到其他各个系统，从而确保客户信息的一致。
为相关的应用系统提供联机交易支持，提供客户信息的唯一访问入口点，为所有应用系统提供及时和全面的客户信息；服务于 OCRM 系统，充分利用数据的价值，在所有客户接触点上提供更多具有附加价值的服务。
实现 SOA 的体系结构：建立客户主数据系统之前，数据被锁定在每一个应用系统和流程中，建立主数据管理系统之后，数据从应用系统中被释放出来，并且被处理成为一组可重用的服务，被各个应用系统调用。

主数据管理(MDM)的成熟度

根据主数据管理实施的复杂程度，大体可以把主数据管理可以分为五个层次，从低到高反映了主数据管理(MDM)的不同成熟度。

Level 0 ：没有实施任何主数据管理(MDM)

在Level 0的情况下，意味着企业的各个应用之间没有任何的数据共享，整个企业没有数据定义元素存在。

比如，一个公司销售很多产品，对这些产品的生产和销售由多个独立的系统来处理，各个系统独立处理产品数据并拥有自己独立的产品列表，各个系统之间不共享产品数据。在Level 0, 每个独立的应用负责管理和维护自己的关键数据(比如产品列表、客户信息等)，各个系统间不共享这些信息，这些数据是不连通的。

Level 1 ：提供列表

不管公司大还是小，列表管理是我们常用的一种方式。在公司内部，会通过手工的方式维护一个逻辑或物理的列表。当各个异构的系统和用户需要某些数据的时 候，就可以索取该列表了。对于这个列表的维护，包括数据添加、删除、更新以及冲突处理，都是由各个部门的工作人员通过一系列的讨论和会议进行处理的。

业务规则是用来反映价值的一致性，当业务规则发生改变或者出现类似的情况时，这样高度手工管理的流程容易发生错误。由于列表管理是通过手工管理的，其列表维护的质量取决于谁参加了变更管理流程，一旦某人缺席，将会影响列表的维护。

Level1比Level 0的不同就是，各个部门虽然还是独立维护各自的关键数据，但会通过列表管理维护一个松散的主数据列表，能够向其他各个部门提供其需要的数据。在Level 1中， 数据变更决定以及数据变更操作都是由人来决定的，因此，只有人完成数据变更决定后才会变更数据。

在实际情况中，虽然数据变更流程有严格的规定，但是由于缺乏集中的、基于规则的数据管理，当数据量比较大时，数据维护的成本会变的很高，效率也会很低。当主数据，比如客户信息、产品目录信息等数量比较少时，列表 管理的方式是可行的，但是当产品目录或客户列表出现爆炸式增长以后，列表管理的变更流程将变得困难起来。

Level 1 依赖于人的协作。在企业范围内实现客户或产品列表就如同维护不同部门之间人们的关系一样。如果客户或产品存在层次或分组，列表将很难提供，并且通常在Level 1因为过于复杂难以被管理。

Level 2 ：同等访问(通过接口的方式，各个系统与主数据主机之间直接互联)

Level 2与Level 1相比，引入了对主数据的(自动)管理。通过建立数据标准，定义对存储在中央知识库中详细数据的访问和共享，为各个系统间共享使用数据提供了严密的支持。中央知识库通常会被称为主数据主机。这个知识库可以是一个数据库或者一个应用系统，通过在线的方式支持数据的访问和共享。Level 2引入了“同等访问”，也就是说一个应用可以调用另一个应用来更新或刷新需要的数据。

在这个阶段，规则管理、数据质量和变更管理必须在企业范围内作为附加功能定制构建。在Level 2，数据变更是自动完成的—通过由具体技术实现的标准流程，允许多应用系统修改数据。Level 2可以支持不同的应用使用和变更单一、共享的数据知识库。

Level 2 需要每个同等应用理解基本的业务规则以便访问主列表、与主列表进行交互。因此，每个同等应用必须正确恰当地创建、增加、更新和删除数据。授权应用有责任坚持数据管理原则和约束。

Level 3 ：集中总线处理

与Level 2相比，Level 3打破了各个独立应用的组织边界，使用各个系统都能接受的数据标准统一建立和维护主数据(Level 2的主数据主机上存储的数据还是按照各个系统分开存储的，没有真正的整合在一起)。集中处理意味着为MDM构建了一个通用的、基于目标构建的平台。

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

在Level 3，公司对主题域内容采用集中管理方式。这意味着应用系统，作为消费者或使用主数据，拥有一个共识就是数据是主题数据内容的映像，打破了各个独立应用的组织边界。在Level 3，一个公司可以让任意两个系统共享数据和说对方的语言。Level 3还降低了等同访问的复杂性。"消费"应用不再需要支持系统定位和操作逻辑。

任何与源系统数据相关的分布式细节都会被MDM总线集中处理。在Level 3自动数据标准意味着：建立目标数据值表示和通过必要的步骤提供精确的主数据值捕获。在所有的分类中从Level 3开始第一次支持一致性的企业数据视图。数据质量规则在这里进行数据清洗和错误纠正。

Level 4 ：业务规则和政策支持

一旦数据从多个数据源整合在一起，主题域视图超越单独的应用并表现为一个企业视图，你将获得事实的单一版本。当事实的单一版本已经能够提供出来时，来自业务主管和执行人员的必然反应经常是：“证明它”。Level 4可以保证主数据反映一个公司业务规则和流程，并证实其正确性。

Level 4通过引入主数据来支持规则，并对MDM总线以及其它外部系统进行完整性检查。由于多数公司相对比较复杂，影响业务数据访问和操作的规则以及策略 相对也比较复杂。假定任何一个单一系统可以包含并管理与主参考数据相关的各种类型的规则是不切实际的。因此，如果一个MDM总线真正打算提供企业范围内数据的精确性，工作流和流程整合的支持是必不可少的。

MDM系统必须不仅支持基于规则的整合，还要能够整合外部的工作流。这些规则可能包括通过总线与临床系统交互或等待另一个系统或者人(有权限做出改变的人)审批。通过一个MDM总线，规则定义可以不仅局限在逻辑上，还可以依赖于其他系统的输入。

当然，协调和审计数据意味着可以回退其他系统(或业务流程)来保证数据变化经过严格的审批，这样错误可以被发现并且事务在需要的时候可以被回滚。Level 4提出对规则和策略扩展性的支持。通过总线以一个灵活可持续的方式支持任何面向业务的规则集合这很重要。

比如，如果一个商店经理更新一个产品的价格，总线系统需要能够和一个可信系统(比如，商品管理系统)进行协商以便使规则生效。详细规则将支持另一个系统中存在产品价格的变更—总线需要能够理解能够处理和批准变更的权限系统或方法。这些规则可能涉及到复杂性或隐私限制，禁止它们直接在总线上存在。

在Level 4， 一个企业可以支持一套步骤或任务，在一个特殊的创建、读取、更新和删除任务被允许之前这些步骤或任务必须遵守。工作流自动化经常用来支持发生在总线上的事 件或活动的授权。但是变更管理远远不仅仅是工作流：它可以包括基于逻辑的流程和基于人的决策。变更管理的存在可以支持动态业务，允许变更。

Level 4支持集中规则管理，但是规则本身和相关的处理是可以分开的。换句话说，MDM总线需要保证规则是集中应用的，即便这个规则是在总线外居住的。

Level 5 ：企业数据集中

在Level 5 ，总线和相关的主数据被集成到独立的应用中。主数据和应用数据之间没有明显的分隔。他们是一体的。当主数据记录详细资料被修改后，所有应用的相关数据元素都将被更新。这意味着所有的消费应用和源系统访问的是相同的数据实例。

这本质上是一个闭环的MDM：所有的应用系统通过统一管理的主数据集成在一起。在这个级别，所有在系统看起来都是事实的同一个版本。操作应用系统和MDM内容是同步的，所以当变更发生时，操作应用系统都将更新。在那些熟悉的MDM架构风格中，持久总线架构，当一个总线更新所有的操作应用系统将体现这种变更，形成改变的直接操作视图。在注册环境中，当数据数据更新时，总线将通过Web服务连接相关系统应用事务更新。

因此，Level 5提供一个集成的，同步的架构，当一个有权限的系统更新一个数据值时，公司内所有的系统将反映这个变更。系统更新完数据值后不要单选其他系统中相应值的更新：MDM将使这种更新变得透明。

一个公司在完成MDM Level 5后将使他们所有的应用连在一起—既包括操作的也包括分析的—所有访问主数据是透明的。Level 5是把数据概念作为一种service来实现。Level 5保证了一个一致的主数据主题域企业映像。定义“客户”和其他应用接受客户主数据业务规则变化实际上是一回事。Level 5移走了主数据的最后一个障碍：统一采用数据定义、授权使用和变更传播。