主数据管理的成熟度word版本

1、主数据管理(MDM)的成熟度MDM全写Master Data Management,翻译为主数据管理或元数据管理。什么是MDM企业主数据是用来描述企业核心业务实体的数据，比如客户、合作伙伴、员 工、产品、物料单、账户等；它是具有高业务价值的、可以在企业内跨越各个业 务部门被重复使用的数据，并且存在于多个异构的应用系统中。主数据和主数据管理的概念企 业主数据可以包括很多方面，除了常见的客户主数据之外，不同行业的 客户还可能拥有其他各种类型的主数据，例如：对于电信行业客户而言，电信运 营商提供的各种服务可以形成其产品主数据；对于航空业客户而言，航线、航 班是其企业主数据的一种。对于某一个企业的不同

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

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

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

5、也会涉及到ETL、EAI、EII等多个方面，如图2所示，一个典 型的主数据管理的信息流为：某个业务系统触发对企业主数据的改动；主数据管理系统将整合之后完整、准确的主数据分发给所有有关的应用系统；主数据管理系统为决策支持和数据仓库系统提供准确的数据源。因此对于主数据管理系统的建设，要从建设初期就考虑整体的平台框架和技术实 现。MDM的意义如图3所 示：集成、共享、数据质量、数据治理是主数据管理的四大要素，主 数据管理要做的就是从企业的多个业务系统中整合最核心的、最需要共享的数据 （主数据），集中进行数据的清洗和丰富，并且以服务的方式把统一的、完整的、准确的、具有权威性的主数据分发给全企业范围内需

6、要使用这些数据的操作 型应用和分析型应用，包括各个业务系统、业务流程和决策支持系统等。主数据管理使得企业能够集中化管理数据，在分散的系统间保证主数据的一 致性，改进数据合规性、快速部署新应用、充分了解客户、加速推出新产品的速 度。从IT建设的角度，主数据管理可以增强IT结构的灵活性，构建覆盖整个 企业范围内的数据管理基础和相应规范，并且更灵活地适应企业业务需求的变 化。以客户主数据为例，客户主数据是目前企业级客户普遍面临的一个问题，在 大多数企业中，客户信息通常分散于CRM等各个业务系统中，而每个业务系统 中都只有客户信息的片断，即不完整的客户信息，但却缺乏企业级的完整、统一 的单一客户视图，

7、结果导致企业不能完全了解客户，无法协调统一的市场行为， 导致客户满意度下降，市场份额减少。因此，建立客户主数据系统的目的在于：整合并存储所有业务系统和渠道的客户及潜在客户的信息：一方面从相关系统中抽取客户信息，并完成客户信息的清洗和整合工作，建立企业级的客 户统一视图；另一方面，客户主数据管理系统将形成的统一客户信息以广播 的形式同步到其他各个系统，从而确保客户信息的一致；为相关的应用系统提供联机交易支持，提供客户信息的唯一访问入口点，为所有应用系统提供及时和全面的客户信息；服务于OCRM系统，充分利用数据的价值，在所有客户接触点上提供更多具有附加价值的服务；实现SOA的体系结构：建立客户主数

8、据系统之前，数据被锁定在每一个应 用系统和流程中，建立主数据管理系统之后，数据从应用系统中被释放出来， 并且被处理成为一组可重用的服务，被各个应用系统调用。MDM的模式元数据管理涉及到各个层次的元数据，管理的内容包括元数据的获取、元数 据的更新、使用和面向应用项目的元数据使用处理等多个方面。元数据的管理涉及数据库、数据处理软件、数据使用系统、面向应用的数据 分析等各个环节。下面给出了一种普通意义的以元数据信息系统为基础的元数据 管理模式：通常意义上的元数据管理是指元数据通过各种途径形成后，对其内容的添 加、删除、更新等涉及内容改变的操作和元数据内容检索、查询、放置、组织等 常规性元数据操作，从

9、这种意义上元数据的管理可以通过两种方式实现，即系 统管理模式和用户管理模式。系统管理模式是面向数据库的，由数据库管理系统 专业人员完成，数据用户只有使用权，没有元数据的操作权，数据应用项目中 新生成的数据集的元数据也有应用系统传递给数据库管理员，然后由数据库管理 员统一管理。这种方式中，数据在处理过程中形成的动态元数据很难及时记录下来。另一 种管理方式是用户管理模式，它是面向应用项目的，即允许某些数据用户在数据 应用元数据的变动信息直接反馈给元数据库，这样则能保证元数据的动态更新和 新生成数据集元数据的及时捕获及写入元数据文件。但这种模式中数据用户的权限要适当的控制，以避免数据库的破坏。通常对

10、 元数据的管理是采用两者结合的模式。主数据（MD Master Data）指系统间共享数据（例如，客户、供应商、账 户和组织部门相关数据）。与记录业务活动，波动较大的交易数据相比，主数据 （也称基准数据）变化缓慢。在正规的关系数据模型中，交易记录（例如，订 单行项）可通过关键字（例如，订单头或发票编号和产品代码）调出主数据。主 数据必须存在并加以正确维护，才能保证交易系统的参照完整性。从报告或维度建模角度看，主数据指基于其组织或配置指标的维度或层次， 而不是实际情况或其自身测量结果。例如，收入、成本和利润是实际情况，而时 间、地点、客户和供应商是维度。应根据以下因素或更多因素综合考虑主数据：

11、企业绩效管理报告(如利润或收入计划随产品、客户、账户等产生的变化)要求 综合多个系统的主数据。遵从报告要求一致性主数据。同步交易系统处理特定 客户(如提供具体报价)或供应商(如指定采购的首选供应商)。主数据管理(MDM)的成熟度根据主数据管理实施的复杂程度，参照Jill Dyche, Evan Levy的观点大体 可以把主数据管理可以分为五个层次，从低到高反映了主数据管理(MDM)的不同 成熟度。下面我们简单介绍一下这五个层次：Level 0 :没有实施任何主数据管理(MDM)在Level 0的情况下，意味着企业的各个应用之间没有任何的数据共享，整 个企业没有数据定义元素存在。比如，一个公司销

12、售很多产品，对这些产品的生 产和销售由多个独立的系统来处理，各个系统独立处理产品数据并拥有自己独立 的产品列表，各个系统之间不共享产品数据。在Level 0,每个独立的应用负责 管理和维护自己的关键数据(比如产品列表、客户信息等)，各个系统间不共享这 些信息，这些数据是不连通的。Level 1 :提供列表不管公司大还是小，列表管理是我们常用的一种方式。在公司内部，会通 过手工的方式维护一个逻辑或物理的列表。当各个异构的系统和用户需要某些数 据的时 候，就可以索取该列表了。对于这个列表的维护，包括数据添加、删除、 更新以及冲突处理，都是由各个部门的工作人员通过一系列的讨论和会议进行处 理的。业务

13、规则(Business Rules)是用来反映价值的一致性，当业务规则发生 改变或者出现类似的情况时，这样高度手工管理的流程容易发生错误。由于列表 管理是通过手工管理的，其列表维护的质量取决于谁参加了变更管理流程，一旦 某人缺席，将会影响列表的维护。MDM Level 1比MDM Level 0的不同就是，各个部门虽然还是独立维护各自 的关键数据，但会通过列表管理维护一个松散的主数据列表，能够向其他各个部 门提供其需要的数据。在MDM Level 1中，数据变更决定以及数据变更操作都 是由人来决定的，因此，只有人完成数据变更决定后才会变更数据。在实际情况 中，虽然数据变更流程有严格的规定，但是

14、由于缺乏集中的、基于规则的数据管理，当数据量比较大时，数据维护的成本会变的很高，效率也会很低。当主数 据，比如客户信息、产品目录信息等数量比较少时，列表 管理的方式是可行的， 但是当产品目录或客户列表出现爆炸式增长以后，列表管理的变更流程将变得困 难起来。MDM Level 1依赖于人的协作。如果产品经理需要更新过后的产品价格 列表，那需要联系ERP系统所有者，让其发送邮件给她。在企业范围内实现客户 或产品列表就如同维护不同部门之间人们的关系一样。如果客户或产品存在层次 或分组，列表将很难提供，并且通常在Level 1因为过于复杂难以被管理。Level 2 :同等访问(通过接口的方式，各个系统

15、与主数据主机之间直接互 联)MDM Level 2与MDM Level 1相比，引入了对主数据的(自动)管理。通过建 立数据标准，定义对存储在中央知识库(Central Repository)中详细数据的访问 和共享，为各个系统间共享使用数据提供了严密的支持。中央知识库(Central Repository)通常会被称为主数据主机(Master Data Host)”。这个知识库可 以是一个数据库或者一个应用系统，通过在线的方式支持数据的访问和共享。创建、读取、更新和删除(CRUD)是处理基本功能的典型编程术语。即便在 MDM中，CRUD处理也是基本功能。你的数据库如果仅仅支持CRUD处理并不

16、意味 着你实现了 MDM。MDM Level 2引入了 “同等访问”(peer-based access)，也 就是说一个应用可以调用另一个应用来更新或刷新需要的数据。当CRUD处理规 则定义完成后，MDM Level 2需要客户或“同等”应用格式化请求(和数据)，以 便和MDM知识库保持一致MDM知识库提供集中的数据存储和供应 (provisioning) o在这个阶段，规则管理、数据质量和变更管理必须在企业范围 内作为附加功能定制构建。比如，一个数据库或一个打包应用(比如一个销售自动化系统)对外部应用提 供数据访问功能。当一个外部应用(比如呼叫中心应用)需要增加一个客户，这个 外部应用将提

17、交一个事务，请求数据所有者增加一个客户条目。主数据主机 (Master Data Host)将增加数据并告知外部应用。CRUD处理方式比纸上办公有 了很大提高，其是基于会话的数据管理。在MDM Level 1，数据变更是基于手工 的方式。在MDM Level 2,数据变更是自动完成的一通过由具体技术实现的标准 流程，允许多应用系统修改数据。MDM Level 2可以支持不同的应用使用和变更 单一、共享的数据知识库。MDM Level 2需要每个同等应用理解基本的业务规则 以便访问主列表、与主列表进行交互。因此，每个同等应用必须正确恰当地创建、 增加、更新和删除数据。授权应用有责任坚持数据管理原

18、则和约束。Level 3 :集中总线处理与MDM Level 2相比，MDM Level 3打破了各个独立应用的组织边界，使用 各个系统都能接受的数据标准统一建立和维护主数据(MDM Level 2的主数据主 机上存储的数据还是按照各个系统分开存储的，没有真正的整合在一起)。集中处理意味着为MDM构建了一个通用的、基于目标构建的平台。大多数公 司发现MDM正在挑战他们现有的IT架构：他们拥有太多的独立平台处理主数据。 MDM Level 3集中数据访问、控制跨不同应用和系统使用数据。这极大的降低了 应用数据访问的复杂性，大大简化了面向数据规则的管理，使MDM比一个分散环 境具有更多的功能和特点

19、。企业主数据面临一致性的挑战。数据在不同的地方存 在，数据所代表的含义也是不同的，数据的规则各个系统之间也是不一样的。集 中MDM处理-通过一个公共的平台作为一个总线(HUB)-说明一个共识，从多个系 统整合主题域数据，意味着使用集中、标准化的方法转换异构操作数据，不管其 在源系统中是什么样子，都会被整合起来。在MDM Level 3,公司对主题域内容 采用集中管理方式。这意味着应用系统，作为消费者或使用主数据，拥有一个共 识就是数据是主题数据内容的映像，打破了各个独立应用的组织边界OMDM Level 3支持分布主参考数据的存在。MDM的核心之一就是保证所有系统都能接受数据表示的唯一公认方法

20、。这有 点类似于语言翻译，通过其他语言的翻译，英语已经称为一个全球性的语言。在 MDM Level 3, 一个公司可以让任意两个系统共享数据和说对方的语言o MDM Level 3还降低了等同访问的复杂性。消费应用不再需要支持系统定位和操作逻辑。 任何与源系统数据相关的分布式细节都会被MDM总线集中处理。在MDM Level 3 自动数据标准意味着：建立目标数据值表示和通过必要的步骤提供精确的主数据 值捕获。在所有的分类中从MDM Level 3开始第一次支持一致性的企业数据视图。数据质量规则在这里进行数据清洗和错误纠正。Level 4 :业务规则和政策支持一旦数据从多个数据源整合在一起，主题

21、域视图超越单独的应用并表现为一 个企业视图，你将获得事实的单一版本。当事实的单一版本已经能够提供出来时， 来自业务主管和执行人员的必然反应经常是：“证明它”。MDM Level 4可以保 证主数据反映一个公司业务规则和流程，并证实其正确性。MDM Level 4通过引 入主数据来支持规则，并对MDM总线以及其它外部系统进行完整性检查。由于多 数公司相对比较复杂，影响业务数据访问和操作的规则以及策略（rules and policies ）相对也比较复杂。假定任何一个单一系统可以包含并管理与主参考数 据相关的各种类型的规则是不切实际的。因此，如果一个MDM总线真正打算提供 企业范围内数据的精确性

22、，工作流和流程整合的支持是必不可少的。举例来说，在一个HMO内，需要多个应用来支持一个病人的护理。一个单一 的访问（visit）可能包括入院、房间和床位分配、监控设备、化验、身体检查以 及其他程序等。一旦一个病人准备离开医院，出院流程需要确保和这个病人相关 的所有活动、资源都被结清。MDM技术在召集多个应用系统一起保证病人辨识方 面是十分有效的，处理是正确的。虽然病人辨识很重要，业务规则整合同样重要。 临床系统依靠一系列的业务流程和数据规则来辨别所有显著的病人详细资料。这 包括返回所有基于房间的资源（监护设备、床位等）以得到有用的详细目录，当病 人要出院时分解其所有的费用。MDM保证当John

23、 Smith出院时，正确的房间和 设备放入到该John Smith的详细目录中，而不是其他的John Smith（正在另一 个楼层做身体治疗）。MDM系统必须不仅支持基于规则的整合，还要能够整合外部的工作流。这些 规则可能包括通过总线与临床系统交互或等待另一个系统或者人（有权限做出改 变的人）审批。通过一个MDM总线，规则定义可以不仅局限在逻辑上，还可以依 赖于其他系统的输入。当然，协调和审计数据意味着可以回退其他系统（或业务 流程）来保证数据变化经过严格的审批，这样错误可以被发现并且事务在需要的 时候可以被回滚。MDM Level 4提出对规则和策略扩展性的支持。通过总线以 一个灵活可持续的

24、方式支持任何面向业务的规则集合这很重要。比如，如果一个商店经理更新一个产品的价格，总线系统需要能够和一个可 信系统（比如，商品管理系统）进行协商以便使规则生效。详细规则将支持另一个 系统中存在产品价格的变更一总线需要能够理解能够处理和批准变更的权限系 统或方法。这些规则可能涉及到复杂性或隐私限制，禁止它们直接在总线上存在。 在MDM Level 4， 一个企业可以支持一套步骤或任务，在一个特殊的创建、读 取、更新和删除任务被允许之前这些步骤或任务必须遵守。工作流自动化经常用 来支持发生在总线上的事件或活动的授权。但是变更管理远远不仅仅是工作流: 它可以包括基于逻辑的流程和基于人的决策。变更管理

25、的存在可以支持动态业 务，允许变更。举例说明，在911之前，任何人都可以在美国国内的航空公司 运载货物。没有规定以外的其他某种形式的鉴定和付款方式。911之后，美国联 邦航空协会（FAA）指导建立了一个更加全面的规定，指示一个人是否被允许运载 货物。在这个特殊的例子中，要求各个系统都部署FAA对托运人的要求是不现实 的。部署一个规则管理系统，为所有的系统（包括MDM总线）集中托运人批准规则， 更加容易实现（也更现实）。集中数据定义和标准化在MDM Level 2就已经引入， 与MDM Level 4的集中规则管理相比，相对简单。业务流程越复杂、业务流程越 多，对总线的需求就越多，以便对针对共同数据的跨职能、异构规则进行更好的 支持。重要的是MDM Level 4支持集中规则管理，但是规则本身和相关的处理 是可以分开的。换句话说，MDM总线需要保证规则是集中应用的，即便这个规则 是在总线外居住的。Level 5 :企业