集团企业的主数据管理Word下载.docx

集团企业的主数据管理Word下载.docx

《集团企业的主数据管理Word下载.docx》由会员分享，可在线阅读，更多相关《集团企业的主数据管理Word下载.docx（7页珍藏版）》请在冰豆网上搜索。

“我们的业务的确存在一些问题，主数据管理正好可以解决这个问题，我们怎么开始?

”。

与以前相比，客户对主数据管理（MDM）的认识有了巨大的进步，并开始尝试用主数据管理（MDM）解决他们在整个企业范围内进行跨业务、跨主题域时遇上的各种挑战和问题：

比如税务行业，税务局在按纳税人在一些分析统计时，就发现关于纳税人的基本信息分布在核心征收管理系统、发票管理系统、个人所得税系统、增值税管理系统等多达几十个系统中，使得统计分析变得困难起来，在比如在医疗设备公司，由于没有按照供应商进行产品层次的分类，各个产品的描述也很不一样，使得产品目录的维护十分困难。

随着业务的发展，对各行各业来说，生成并维护一个统一的主数据系统变的十分迫切和必要，特别是对一些跨国公司，如何在不同的地区（各个国家和地区）的业务系统之间维护关于客户、产品目录、供应商等信息的单一视图更是重要。

　　需要注意的是，主数据（MasterData）和元数据（MetaData）是两个完全不同的概念。

元数据是指表示数据的相关信息，比如数据定义等，而主数据是指实例数据，比如产品目录信息等。

比如，某省地税开发了一套征收管理软件，以市为单位部署了17套，每套征收管理软件中的元数据都是一样的，但是主数据还是需要进行管理的。

主数据管理和传统数据仓库解决方案不是一个概念，数据仓库会将各个业务系统的数据集中在一起在进行业务的分析，而主数据管理系统不会把所有数据都管理起来，只是把需要在各个系统间共享的主数据进行采集和发布。

相对于传统数据仓库解决方案的单向集成，主数据管理正注重将主数据的变化同步发布到各个关联的业务系统中（主数据管理数据是双向的）。

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

　　对于大多数的企业都存在主数据管理的问题，个人以为这是由于业务发展的渐进性以及IT技术发展的渐进性造成的，正是由于这种渐进性，各大企业的业务系统从经历了从无到有，从简单到复杂，从而形成了一个又一个的业务竖井。

从根本上来说，不可能只使用一个业务系统就能覆盖企业的所有业务，即便对一些国际大型的公司提供的套件来说也是一个不可能完成的任务（即便对套件来说，经常也存在一个跨国企业在不同的国家或地区部署多个实例的现象，也就是没有集中部署该套件，而是在很多地方分散部署了该套件）。

对企业来说，业务系统的构建更多是以项目为中心，从下而上的构建系统，而不是至上而下的构建系统，必然缺乏整个企业范围内的统一规划，从而使得一些需要在各个业务中共享的数据（主数据）被分散到了各个业务系统进行分别管理。

分散管理的主数据由于没有不具备一致性、准确性、完整性，使得各个企业普遍存在着产品管理不力、供应商管理不力、订单管理不力等现象。

解决这一问题的根本方法就是引入主数据管理（MDM），主数据不光指需要共享的数据，更包含需要共享的业务规则和策略。

主数据管理（MDM）的成熟度

　　根据主数据管理实施的复杂程度，参照JillDyche,EvanLevy的观点大体可以把主数据管理可以分为五个层次，从低到高反映了主数据管理（MDM）的不同成熟度。

下面我们简单介绍一下这五个层次：

　　Level0：

没有实施任何主数据管理（MDM）

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

比如，一个公司销售很多产品，对这些产品的生产和销售由多个独立的系统来处理，各个系统独立处理产品数据并拥有自己独立的产品列表，各个系统之间不共享产品数据。

在Level0,每个独立的应用负责管理和维护自己的关键数据（比如产品列表、客户信息等），各个系统间不共享这些信息，这些数据是不连通的。

　　Level1：

提供列表

　　不管公司大还是小，列表管理是我们常用的一种方式。

在公司内部，会通过手工的方式维护一个逻辑或物理的列表。

当各个异构的系统和用户需要某些数据的时候，就可以索取该列表了。

对于这个列表的维护，包括数据添加、删除、更新以及冲突处理，都是由各个部门的工作人员通过一系列的讨论和会议进行处理的。

业务规则（BusinessRules）是用来反映价值的一致性，当业务规则发生改变或者出现类似的情况时，这样高度手工管理的流程容易发生错误。

由于列表管理是通过手工管理的，其列表维护的质量取决于谁参加了变更管理流程，一旦某人缺席，将会影响列表的维护。

　　MDMLevel1比MDMLevel0的不同就是，各个部门虽然还是独立维护各自的关键数据，但会通过列表管理维护一个松散的主数据列表，能够向其他各个部门提供其需要的数据。

在MDMLevel1中，数据变更决定以及数据变更操作都是由人来决定的，因此，只有人完成数据变更决定后才会变更数据。

在实际情况中，虽然数据变更流程有严格的规定，但是由于缺乏集中的、基于规则的数据管理，当数据量比较大时，数据维护的成本会变的很高，效率也会很低。

当主数据，比如客户信息、产品目录信息等数量比较少时，列表管理的方式是可行的，但是当产品目录或客户列表出现爆炸式增长以后，列表管理的变更流程将变得困难起来。

MDMLevel1依赖于人的协作。

如果产品经理需要更新过后的产品价格列表，那需要联系ERP系统所有者，让其发送邮件给她。

在企业范围内实现客户或产品列表就如同维护不同部门之间人们的关系一样。

如果客户或产品存在层次或分组，列表将很难提供，并且通常在Level1因为过于复杂难以被管理。

　　Level2：

同等访问（通过接口的方式，各个系统与主数据主机之间直接互联）

　　MDMLevel2与MDMLevel1相比，引入了对主数据的（自动）管理。

通过建立数据标准，定义对存储在中央知识库（CentralRepository）中详细数据的访问和共享，为各个系统间共享使用数据提供了严密的支持。

中央知识库（CentralRepository）通常会被称为“主数据主机（MasterDataHost）”。

这个知识库可以是一个数据库或者一个应用系统，通过在线的方式支持数据的访问和共享。

　　创建、读取、更新和删除（CRUD）是处理基本功能的典型编程术语。

即便在MDM中，CRUD处理也是基本功能。

你的数据库如果仅仅支持CRUD处理并不意味着你实现了MDM。

MDMLevel2引入了“同等访问”（peer-basedaccess），也就是说一个应用可以调用另一个应用来更新或刷新需要的数据。

当CRUD处理规则定义完成后，MDMLevel2需要客户或“同等”应用格式化请求（和数据），以便和MDM知识库保持一致。

MDM知识库提供集中的数据存储和供应（provisioning）。

在这个阶段，规则管理、数据质量和变更管理必须在企业范围内作为附加功能定制构建。

　　比如，一个数据库或一个打包应用（比如一个销售自动化系统）对外部应用提供数据访问功能。

当一个外部应用（比如呼叫中心应用）需要增加一个客户，这个外部应用将提交一个事务，请求数据所有者增加一个客户条目。

主数据主机（MasterDataHost）将增加数据并告知外部应用。

CRUD处理方式比纸上办公有了很大提高，其是基于会话的数据管理。

在MDMLevel1，数据变更是基于手工的方式。

在MDMLevel2，数据变更是自动完成的—通过由具体技术实现的标准流程，允许多应用系统修改数据。

MDMLevel2可以支持不同的应用使用和变更单一、共享的数据知识库。

MDMLevel2需要每个同等应用理解基本的业务规则以便访问主列表、与主列表进行交互。

因此，每个同等应用必须正确恰当地创建、增加、更新和删除数据。

授权应用有责任坚持数据管理原则和约束。

　　Level3：

集中总线处理

　　与MDMLevel2相比，MDMLevel3打破了各个独立应用的组织边界，使用各个系统都能接受的数据标准统一建立和维护主数据（MDMLevel2的主数据主机上存储的数据还是按照各个系统分开存储的，没有真正的整合在一起）。

　　集中处理意味着为MDM构建了一个通用的、基于目标构建的平台。

大多数公司发现MDM正在挑战他们现有的IT架构：

他们拥有太多的独立平台处理主数据。

MDMLevel3集中数据访问、控制跨不同应用和系统使用数据。

这极大的降低了应用数据访问的复杂性，大大简化了面向数据规则的管理，使MDM比一个分散环境具有更多的功能和特点。

企业主数据面临一致性的挑战。

数据在不同的地方存在，数据所代表的含义也是不同的，数据的规则各个系统之间也是不一样的。

集中MDM处理-通过一个公共的平台作为一个总线（HUB）-说明一个共识，从多个系统整合主题域数据，意味着使用集中、标准化的方法转换异构操作数据，不管其在源系统中是什么样子，都会被整合起来。

在MDMLevel3，公司对主题域内容采用集中管理方式。

这意味着应用系统，作为消费者或使用主数据，拥有一个共识就是数据是主题数据内容的映像，打破了各个独立应用的组织边界。

MDMLevel3支持分布主参考数据的存在。

　　MDM的核心之一就是保证所有系统都能接受数据表示的唯一公认方法。

这有点类似于语言翻译，通过其他语言的翻译，英语已经称为一个全球性的语言。

在MDMLevel3，一个公司可以让任意两个系统共享数据和说对方的语言。

MDMLevel3还降低了等同访问的复杂性。

"

消费"

应用不再需要支持系统定位和操作逻辑。

任何与源系统数据相关的分布式细节都会被MDM总线集中处理。

在MDMLevel3自动数据标准意味着：

建立目标数据值表示和通过必要的步骤提供精确的主数据值捕获。

在所有的分类中从MDMLevel3开始第一次支持一致性的企业数据视图。

数据质量规则在这里进行数据清洗和错误纠正。

　　Level4：

业务规则和政策支持

　　一旦数据从多个数据源整合在一起，主题域视图超越单独的应用并表现为一个企业视图，你将获得事实的单一版本。

当事实的单一版本已经能够提供出来时，来自业务主管和执行人员的必然反应经常是：

“证明它”。

MDMLevel4可以保证主数据反映一个公司业务规则和流程，并证实其正确性。

MDMLevel4通过引入主数据来支持规则，并对MDM总线以及其它外部系统进行完整性检查。

由于多数公司相对比较复杂，影响业务数据访问和操作的规则以及策略（rulesandpolicies）相对也比较复杂。

假定任何一个单一系统可以包含并管理与主参考数据相关的各种类型的规则是不切实际的。

因此，如果一个MDM总线真正打算提供企业范围内数据的精确性，工作流和流程整合的支持是必不可少的。

　　举例来说，在一个HMO内，需要多个应用来支持一个病人的护理。

一个单一的访问（visit）可能包括入院、房间和床位分配、监控设备、化验、身体检查以及其他程序等。

一旦一个病人准备离开医院，出院流程需要确保和这个病人相关的所有活动、资源都被结清。

MDM技术在召集多个应用系统一起保证病人辨识方面是十分有效的，处理是正确的。

虽然病人辨识很重要，业务规则整合同样重要。

临床系统依靠一系列的业务流程和数据规则来辨别所有显著的病人详细资料。

这包括返回所有基于房间的资源（监护设备、床位等）以得到有用的详细目录，当病人要出院时分解其所有的费用。

MDM保证当JohnSmith出院时，正确的房间和设备放入到该JohnSmith的详细目录中，而不是其他的JohnSmith（正在另一个楼层做身体治疗）。

　　MDM系统必须不仅支持基于规则的整合，还要能够整合外部的工作流。

这些规则可能包括通过总线与临床系统交互或等待另一个系统或者人（有权限做出改变的人）审批。

通过一个MDM总线，规则定义可以不仅局限在逻辑上，还可以依赖于其他系统的输入。

当然，协调和审计数据意味着可以回退其他系统（或业务流程）来保证数据变化经过严格的审批，这样错误可以被发现并且事务在需要的时候可以被回滚。

MDMLevel4提出对规则和策略扩展性的支持。

通过总线以一个灵活可持续的方式支持任何面向业务的规则集合这很重要。

　　比如，如果一个商店经理更新一个产品的价格，总线系统需要能够和一个可信系统（比如，商品管理系统）进行协商以便使规则生效。

详细规则将支持另一个系统中存在产品价格的变更—总线需要能够理解能够处理和批准变更的权限系统或方法。

这些规则可能涉及到复杂性或隐私限制，禁止它们直接在总线上存在。

在MDMLevel4，一个企业可以支持一套步骤或任务，在一个特殊的创建、读取、更新和删除任务被允许之前这些步骤或任务必须遵守。

工作流自动化经常用来支持发生在总线上的事件或活动的授权。

但是变更管理远远不仅仅是工作流：

它可以包括基于逻辑的流程和基于人的决策。

变更管理的存在可以支持动态业务，允许变更。

举例说明，在911之前，任何人都可以在美国国内的航空公司运载货物。

没有规定以外的其他某种形式的鉴定和付款方式。

911之后，美国联邦航空协会（FAA）指导建立了一个更加全面的规定，指示一个人是否被允许运载货物。

在这个特殊的例子中，要求各个系统都部署FAA对托运人的要求是不现实的。

部署一个规则管理系统，为所有的系统（包括MDM总线）集中托运人批准规则，更加容易实现（也更现实）。

集中数据定义和标准化在MDMLevel2就已经引入，与MDMLevel4的集中规则管理相比，相对简单。

业务流程越复杂、业务流程越多，对总线的需求就越多，以便对针对共同数据的跨职能、异构规则进行更好的支持。

重要的是MDMLevel4支持集中规则管理，但是规则本身和相关的处理是可以分开的。

换句话说，MDM总线需要保证规则是集中应用的，即便这个规则是在总线外居住的。

　　Level5：

企业数据集中

　　在MDMLevel5，总线和相关的主数据被集成到独立的应用中。

主数据和应用数据之间没有明显的分隔。

他们是一体的。

当主数据记录详细资料被修改后，所有应用的相关数据元素都将被更新。

这意味着所有的消费应用和源系统访问的是相同的数据实例。

这本质上是一个闭环的MDM：

所有的应用系统通过统一管理的主数据集成在一起。

在这个级别，所有在系统看起来都是事实的同一个版本。

操作应用系统和MDM内容是同步的，所以当变更发生时，操作应用系统都将更新。

在那些熟悉的MDM架构风格中，持久总线架构，当一个总线更新所有的操作应用系统将体现这种变更，形成改变的直接操作视图。

在注册环境中，当数据数据更新时，总线将通过Web服务连接相关系统应用事务更新。

因此，MDMLevel5提供一个集成的，同步的架构，当一个有权限的系统更新一个数据值时，公司内所有的系统将反映这个变更。

系统更新完数据值后不要单选其他系统中相应值的更新：

MDM将使这种更新变的透明。

　　从MDMLevel4到MDMLevel5意味着MDM功能性不是在一个应用内被特殊设计或编码的。

这还意味着主数据传播和供应不需要源系统专门的开发或支持。

所有的应用清楚的知道他们并不拥有或控制主数据。

他们仅仅使用数据来支持他们自己的功能和流程。

由于MDM总线和支持的IT基础架构，所有的应用可以访问主参考数据。

一个公司在完成MDMLevel5后将使他们所有的应用连在一起—既包括操作的也包括分析的—所有访问主数据是透明的。

举例说明，当一个客户更新她的状态—不要管注册该变更的系统—数据变更将被广播到所有的应用平台（因此一致起来）。

MDMLevel5是把数据概念作为一种service来实现。

MDMLevel5保证了一个一致的主数据主题域企业映像。

定义“客户”和其他应用接受客户主数据业务规则变化实际上是一回事。

MDMLevel5移走了主数据的最后一个障碍：

统一采用数据定义、授权使用和变更传播。

如何构建一个主数据管理（MDM）的解决方案

　　在开始构建主数据管理（MDM）解决方案之前，首先需要明确我们当前的数据管理现状是什么样子的，而我们的目标是什么，具体可以参照上一小节：

主数据管理（MDM）的成熟度。

　　第二步，需要确定我们的每个主数据域的范围（这也是前期需求分析的一部分）。

常见的主题域有：

　　Party：

可以反映任何合法的实体,无论是个体还是组织。

　　Product：

既包括物理存在的货物，也可以是任何服务。

　　Account：

包括期限和条件，以及相关的各种关系。

　　Location：

既可以独立存在，也常常与其他主数据域共存。

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

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

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

　　如果根据数据质量标准清理主数据域中的主数据。

　　权限控制。

　　主数据的历史版本控制以及变更监控控制（当主数据变化时，要能记录该变化，另外还要对主数据形成层次并记录其不同的版本值）。

　　第四步，开发部署测试。