主数据(MD Master Data)

主数据(MD Master Data)

目录 1 什么是主数据 2 主数据的因素 3 主数据管理 4 主数据管理问题存在的根源 5 主数据管理的成熟度 6 主数据管理方案的构建

 

什么是主数据

　　主数据是指在整个企业范围内各个系统(操做/事务型应用系统以及分析型系统)间要共享的数据， 好比，能够是与客户(customers), 供应商(suppliers), 账户(accounts)以及组织单位(organizational units)相关的数据。

　　主数据一般须要在整个企业范围内保持一致性(consistent)、完整性(complete)、可控性(controlled)，为了达成这一目标，就须要进行主数据管理(Master Data Management ，MDM)。须要注意的是，主数据不是企业内全部的业务数据，只是有必要在各个系统间共享的数据才是主数据，好比大部分的交易数据、账单数据等都不是主数据，而像描述核心业务实体的数据，而像客户、供应商、账户、组织单位、员工、合做伙伴、位置信息等都是主数据。主数据是企业内可以跨业务重复使用的高价值的数据。这些主数据在进行主数据管理以前常常存在于多个异构或同构的系统中。

主数据的因素

• 企业绩效管理报告(如利润或收入计划随产品、客户、帐户等产生的变化)要求综合多个系统的主数据。

• 听从报告(如辛巴赛尔协定关于运营风险的报告)要求一致性主数据。

• 同步交易系统处理特定客户(如提供具体报价)或供应商(如指定采购的首选供应商)。

主数据管理

　　主数据管理(Master Data Management ，MDM)是指一组约束和方法用来保证一个企业内主题域和系统内相关数据和跨主题域和系统的相关数据的实时性、含义和质量。这是从深层次来讲来讲明主动主数据管理(MDM)的深度和复杂性，简单的说，主数据管理(MDM)保证你的系统协调和重用通用、正确的业务数据(主数据)。一般，咱们会把主数据管理做为应用流程的补充，经过从各个操做/事务型应用以及分析型应用中分离出主要的信息，使其成为一个集中的、独立于企业中各类其余应用核心资源，从而使得企业的核心信息得以重用并确保各个操做/事务型应用以及分析型应用间的核心数据的一致性。经过主数据管理，改变企业数据利用的现状，从而更好地为企业信息集成作好铺垫。

　　主数据管理(MDM)能够帮助咱们建立并维护整个企业内主数据的单一视图(Single View)，保证单一视图的准确性、一致性以及完整性，从而提供数据质量，统一商业实体的定义，简化改进商业流程并提供业务的响应速度。从变化的频率来看，主数据和平常交易数据不同，变化相对缓慢，另外，主数据因为跨各个系统，因此对数据的一致性、实时性以及版本控制要求很高。

　　主数据管理其实在很早以前就一直存在，只不过如今随着业务发展以及监管的须要，对主数据的实时性、准确性、一致性有了更高的要求，才被业界普遍接受，各个厂商相应的推出了一系列的主数据管理集成与基础套件以及特定领域的解决方案。近年来最明显的变化是，客户在之前的时候常常问的问题是：“主数据管理是什么?”，而如今客户常常问的问题演变成了：“咱们的业务的确存在一些问题，主数据管理正好能够解决这个问题，咱们怎么开始?”。与之前相比，客户对主数据管理(MDM)的认识有了巨大的进步，并开始尝试用主数据管理(MDM)解决他们在整个企业范围内进行跨业务、跨主题域时赶上的各类挑战和问题：好比税务行业，税务局在按纳税人在一些分析统计时，就发现关于纳税人的基本信息分布在核心征收管理系统、发票管理系统、我的所得税系统、增值税管理系统等多达几十个系统中，使得统计分析变得困难起来，在好比在医疗设备公司，因为没有按照供应商进行产品层次的分类，各个产品的描述也很不同，使得产品目录的维护十分困难。随着业务的发展，对各行各业来讲，生成并维护一个统一的主数据系统变的十分迫切和必要，特别是对一些跨国公司，如何在不一样的地区(各个国家和地区)的业务系统之间维护关于客户、产品目录、供应商等信息的单一视图更是重要。

　　须要注意的是，主数据(Master Data)和元数据(Meta Data)是两个彻底不一样的概念。元数据是指表示数据的相关信息，好比数据定义等，而主数据是指实例数据，好比产品目录信息等。好比，某省地税开发了一套征收管理软件，以市为单位部署了17套，每套征收管理软件中的元数据都是同样的，可是主数据仍是须要进行管理的。主数据管理和传统数据仓库解决方案不是一个概念，数据仓库会将各个业务系统的数据集中在一块儿在进行业务的分析，而主数据管理系统不会把全部数据都管理起来，只是把须要在各个系统间共享的主数据进行采集和发布。相对于传统数据仓库解决方案的单向集成，主数据管理正注重将主数据的变化同步发布到各个关联的业务系统中(主数据管理数据是双向的)。

主数据管理问题存在的根源

　　对于大多数的企业都存在主数据管理的问题，我的觉得这是因为业务发展的渐进性以及IT技术发展的渐进性形成的，正是因为这种渐进性，各大企业的业务系统从经历了从无到有，从简单到复杂，从而造成了一个又一个的业务竖井。从根本上来讲，不可能只使用一个业务系统就能覆盖企业的全部业务，即使对一些国际大型的公司提供的套件来讲也是一个不可能完成的任务(即使对套件来讲，常常也存在一个跨国企业在不一样的国家或地区部署多个实例的现象，也就是没有集中部署该套件，而是在不少地方分散部署了该套件)。对企业来讲，业务系统的构建更可能是以项目为中心，从下而上的构建系统，而不是至上而下的构建系统，必然缺少整个企业范围内的统一规划，从而使得一些须要在各个业务中共享的数据(主数据)被分散到了各个业务系统进行分别管理。分散管理的主数据因为没有不具有一致性、准确性、完整性，使得各个企业广泛存在着产品管理不力、供应商管理不力、订单管理不力等现象。解决这一问题的根本方法就是引入主数据管理(MDM)，主数据不光指须要共享的数据，更包含须要共享的业务规则和策略。

 

主数据管理的成熟度

根据主数据管理实施的复杂程度，参照Jill Dyche, Evan Levy的观点大致能够把主数据管理能够分为五个层次，从低到高反映了主数据管理(MDM)的不一样成熟度。下面咱们简单介绍一下这五个层次：

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

　　在Level 0的状况下，意味着企业的各个应用之间没有任何的数据共享，整个企业没有数据定义元素存在。好比，一个公司销售不少产品，对这些产品的生产和销售由多个独立的系统来处理，各个系统独立处理产品数据并拥有本身独立的产品列表，各个系统之间不共享产品数据。在Level 0, 每一个独立的应用负责管理和维护本身的关键数据(好比产品列表、客户信息等)，各个系统间不共享这些信息，这些数据是不连通的。

　　Level 1 ：提供列表

　　无论公司大仍是小，列表管理是咱们经常使用的一种方式。在公司内部，会经过手工的方式维护一个逻辑或物理的列表。当各个异构的系统和用户须要某些数据的时候，就能够索取该列表了。对于这个列表的维护，包括数据添加、删除、更新以及冲突处理，都是由各个部门的工做人员经过一系列的讨论和会议进行处理的。业务规则(Business Rules)是用来反映价值的一致性，当业务规则发生改变或者出现相似的状况时，这样高度手工管理的流程容易发生错误。因为列表管理是经过手工管理的，其列表维护的质量取决于谁参加了变动管理流程，一旦某人缺席，将会影响列表的维护。

　　MDM Level 1比MDM Level 0的不一样就是，各个部门虽然仍是独立维护各自的关键数据，但会经过列表管理维护一个松散的主数据列表，可以向其余各个部门提供其须要的数据。在MDM Level 1中，数据变动决定以及数据变动操做都是由人来决定的，所以，只有人完成数据变动决定后才会变动数据。在实际状况中，虽然数据变动流程有严格的规定，可是因为缺少集中的、基于规则的数据管理，当数据量比较大时，数据维护的成本会变的很高，效率也会很低。当主数据，好比客户信息、产品目录信息等数量比较少时，列表管理的方式是可行的，可是当产品目录或客户列表出现爆炸式增加之后，列表管理的变动流程将变得困难起来。MDM Level 1 依赖于人的协做。若是产品经理须要更新事后的产品价格列表，那须要联系ERP系统全部者，让其发送邮件给她。在企业范围内实现客户或产品列表就如同维护不一样部门之间人们的关系同样。若是客户或产品存在层次或分组，列表将很难提供，而且一般在Level 1由于过于复杂难以被管理。

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

　　MDM Level 2与MDM Level 1相比，引入了对主数据的(自动)管理。经过创建数据标准，定义对存储在中央知识库(Central Repository)中详细数据的访问和共享，为各个系统间共享使用数据提供了严密的支持。中央知识库(Central Repository)一般会被称为“主数据主机(Master Data Host)”。这个知识库能够是一个数据库或者一个应用系统，经过在线的方式支持数据的访问和共享。

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

　　好比，一个数据库或一个打包应用(好比一个销售自动化系统)对外部应用提供数据访问功能。当一个外部应用(好比呼叫中心应用)须要增长一个客户，这个外部应用将提交一个事务，请求数据全部者增长一个客户条目。主数据主机(Master Data Host)将增长数据并告知外部应用。CRUD处理方式比纸上办公有了很大提升，其是基于会话的数据管理。在MDM Level 1，数据变动是基于手工的方式。在MDM Level 2， 数据变动是自动完成的—经过由具体技术实现的标准流程，容许多应用系统修改数据。MDM Level 2能够支持不一样的应用使用和变动单1、共享的数据知识库。MDM Level 2 须要每一个同等应用理解基本的业务规则以便访问主列表、与主列表进行交互。所以，每一个同等应用必须正确恰当地建立、增长、更新和删除数据。受权应用有责任坚持数据管理原则和约束。

　　Level 3 ：集中总线处理

　　与MDM Level 2相比，MDM Level 3打破了各个独立应用的组织边界，使用各个系统都能接受的数据标准统一创建和维护主数据(MDM Level 2的主数据主机上存储的数据仍是按照各个系统分开存储的，没有真正的整合在一块儿)。

　　集中处理意味着为MDM构建了一个通用的、基于目标构建的平台。大多数公司发现MDM正在挑战他们现有的IT架构：他们拥有太多的独立平台处理主数据。MDM Level 3 集中数据访问、控制跨不一样应用和系统使用数据。这极大的下降了应用数据访问的复杂性，大大简化了面向数据规则的管理，使MDM比一个分散环境具备更多的功能和特色。企业主数据面临一致性的挑战。数据在不一样的地方存在，数据所表明的含义也是不一样的，数据的规则各个系统之间也是不同的。集中MDM处理-经过一个公共的平台做为一个总线(HUB)-说明一个共识，从多个系统整合主题域数据，意味着使用集中、标准化的方法转换异构操做数据，无论其在源系统中是什么样子，都会被整合起来。在MDM Level 3，公司对主题域内容采用集中管理方式。这意味着应用系统，做为消费者或使用主数据，拥有一个共识就是数据是主题数据内容的映像，打破了各个独立应用的组织边界。MDM Level 3支持分布主参考数据的存在。

　　MDM的核心之一就是保证全部系统都能接受 数据表示的惟一公认方法。这有点相似于语言翻译，经过其余语言的翻译，英语已经称为一个全球性的语言。在MDM Level 3， 一个公司可让任意两个系统共享数据和说对方的语言。MDM Level 3还下降了等同访问的复杂性。"消费"应用再也不须要支持系统定位和操做逻辑。任何与源系统数据相关的分布式细节都会被MDM总线集中处理。在MDM Level 3自动数据标准意味着：创建目标数据值表示和经过必要的步骤提供精确的主数据值捕获。在全部的分类中从MDM Level 3开始第一次支持一致性的企业数据视图。数据质量规则在这里进行数据清洗和错误纠正。

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

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

　　举例来讲，在一个HMO内，须要多个应用来支持一个病人的护理。一个单一的访问(visit)可能包括入院、房间和床位分配、监控设备、化验、身体检查以及其余程序等。一旦一个病人准备离开医院，出院流程须要确保和这个病人相关的全部活动、资源都被结清。MDM技术在召集多个应用系统一块儿保证病人辨识方面是十分有效的，处理是正确的。虽然病人辨识很重要，业务规则整合一样重要。临床系统依靠一系列的业务流程和数据规则来辨别全部显着的病人详细资料。这包括返回全部基于房间的资源(监护设备、床位等)以获得有用的详细目录，当病人要出院时分解其全部的费用。MDM保证当John Smith出院时，正确的房间和设备放入到该John Smith的详细目录中，而不是其余的John Smith(正在另外一个楼层作身体治疗)。

　　MDM系统必须不只支持基于规则的整合，还要可以整合外部的工做流。这些规则可能包括经过总线与临床系统交互或等待另外一个系统或者人(有权限作出改变的人)审批。经过一个MDM总线，规则定义能够不只局限在逻辑上，还能够依赖于其余系统的输入。固然，协调和审计数据意味着能够回退其余系统(或业务流程)来保证数据变化通过严格的审批，这样错误能够被发现而且事务在须要的时候能够被回滚。MDM Level 4提出对规则和策略扩展性的支持。 经过总线以一个灵活可持续的方式支持任何面向业务的规则集合这很重要。

　　好比，若是一个商店经理更新一个产品的价格，总线系统须要可以和一个可信系统(好比，商品管理系统)进行协商以便使规则生效。详细规则将支持另外一个系统中存在产品价格的变动—总线须要可以理解可以处理和批准变动的权限系统或方法。这些规则可能涉及到复杂性或隐私限制，禁止它们直接在总线上存在。在 MDM Level 4， 一个企业能够支持一套步骤或任务，在一个特殊的建立、读取、更新和删除任务被容许以前这些步骤或任务必须遵照。工做流自动化常常用来支持发生在总线上的事件或活动的受权。可是变动管理远远不只仅是工做流：它能够包括基于逻辑的流程和基于人的决策。变动管理的存在能够支持动态业务，容许变动。举例说明，在 911以前，任何人均可以在美国国内的航空公司运载货物。没有规定之外的其余某种形式的鉴定和付款方式。911以后，美国联邦航空协会(FAA)指导创建了一个更加全面的规定，指示一我的是否被容许运载货物。在这个特殊的例子中，要求各个系统都部署FAA对托运人的要求是不现实的。部署一个规则管理系统 ，为全部的系统(包括MDM总线)集中托运人批准规则，更加容易实现(也更现实)。集中数据定义和标准化在MDM Level 2就已经引入，与MDM Level 4的集中规则管理相比，相对简单。业务流程越复杂、业务流程越多，对总线的需求就越多，以便对针对共同数据的跨职能、异构规则进行更好的支持。重要的是 MDM Level 4支持集中规则管理，可是规则自己和相关的处理是能够分开的。换句话说，MDM总线须要保证规则是集中应用的，即使这个规则是在总线外居住的。

　　Level 5 ：企业数据集中

　　在MDM Level 5 ， 总线和相关的主数据被集成到独立的应用中。主数据和应用数据之间没有明显的分隔。他们是一体的。当主数据记录详细资料被修改后，全部应用的相关数据元素都将被更新。这意味着全部的消费应用和源系统访问的是相同的数据实例。这本质上是一个闭环的MDM：全部的应用系统经过统一管理的主数据集成在一块儿。在这个级别，全部在系统看起来都是事实的同一个版本。操做应用系统和MDM内容是同步的，因此当变动发生时，操做应用系统都将更新。在那些熟悉的MDM架构风格中，持久总线架构，当一个总线更新全部的操做应用系统将体现这种变动，造成改变的直接操做视图。在注册环境中，当数据数据更新时，总线将经过Web服务链接相关系统应用事务更新。所以，MDM Level 5提供一个集成的，同步的架构，当一个有权限的系统更新一个数据值时，公司内全部的系统将反映这个变动。系统更新完数据值后不要单选其余系统中相应值的更新：MDM将使这种更新变的透明。

　　从MDM Level 4到MDM Level 5意味着MDM功能性不是在一个应用内被特殊设计或编码的。这还意味着主数据传播和供应不须要源系统专门的开发或支持。全部的应用清楚的知道他们并不拥有或控制主数据。他们仅仅使用数据来支持他们本身的功能和流程。因为MDM总线和支持的IT基础架构，全部的应用能够访问主参考数据。一个公司在完成MDM Level 5后将使他们全部的应用连在一块儿—既包括操做的也包括分析的—全部访问主数据是透明的。举例说明，当一个客户更新她的状态—不要管注册该变动的系统—数据变动将被广播到全部的应用平台(所以一致起来)。MDM Level 5是把数据概念做为一种service来实现。MDM Level 5保证了一个一致的主数据主题域企业映像。定义“客户”和其余应用接受客户主数据业务规则变化其实是一回事。MDM Level 5移走了主数据的最后一个障碍：统一采用数据定义、受权使用和变动传播。

主数据管理方案的构建

　　在开始构建主数据管理(MDM)解决方案以前，首先须要明确咱们当前的数据管理现状是什么样子的，而咱们的目标是什么，具体能够参照上一小节：主数据管理(MDM)的成熟度。

　　第二步，须要肯定咱们的每一个主数据域的范围(这也是前期需求分析的一部分)。常见的主题域有：

• Party ：能够反映任何合法的实体, 不管是个体仍是组织。

• Product ：既包括物理存在的货物，也能够是任何服务。

• Account ：包括期限和条件，以及相关的各类关系。

• Location ：既能够独立存在，也经常与其余主数据域共存。

　　第三步，进行数据管理系统的设计，在设计时要注意如下几点：

• 数据采集和发布是否实时，最小的响应时间是多少。

• 数据转换规则可否让客户定制，而不是硬编码。

• 若是根据数据质量标准清理主数据域中的主数据。

• 权限控制。

• 主数据的历史版本控制以及变动监控控制(当主数据变化时，要能记录该变化，另外还要对主数据造成层次并记录其不一样的版本值)。

　　第四步，开发部署测试。