主数据管理详解MDM.docx
- 文档编号:12749868
- 上传时间:2023-06-07
- 格式:DOCX
- 页数:14
- 大小:208.42KB
主数据管理详解MDM.docx
《主数据管理详解MDM.docx》由会员分享,可在线阅读,更多相关《主数据管理详解MDM.docx(14页珍藏版)》请在冰点文库上搜索。
主数据管理详解MDM
主数据管理详解
主数据是指在整个企业范围内各个系统(操作/事务型应用系统以及分析型系统)间要共享的
数据,比如,可以是与客户(customers),供应商(suppliers),帐户(accounts)以及组织单位(or
(consistent)、
ganizationalunits)相关的数据。
主数据通常需要在整个企业范围内保持一致性完整性(complete)、可控性(controlled),为了达成这一目标,就需要进行主数据管理(Master
DataManagement,MDM)。
什么是主数据管理(MasterDataManagement,MDM)
主数据是指在整个企业范围内各个系统(操作/事务型应用系统以及分析型系统)间要共
享的数据,比如,可以是与客户(customers),供应商(suppliers),帐户(accounts)以及组织单
(consiste
位(organizationalunits)相关的数据。
主数据通常需要在整个企业范围内保持一致性
nt)、完整性(complete)、可控性(controlled),为了达成这一目标,就需要进行主数据管理(M
asterDataManagement,MDM)。
需要注意的是,主数据不是企业内所有的业务数据,只
主数据,而像描述核心业务实体的数据,而像客户、供应商、帐户、组织单位、员工、合作
主数据在进行主数据管理之前经常存在于多个异构或同构的系统中。
主数据管理(MasterDataManagement,MDM)是指一组约束和方法用来保证一个企业
层次来说来说明主动主数据管理(MDM)的深度和复杂性,简单的说,主数据管理(MDM)保证
你的系统协调和重用通用、正确的业务数据(主数据)。
通常,我们会把主数据管理作为应用
流程的补充,通过从各个操作/事务型应用以及分析型应用中分离出主要的信息,使其成为
一个集中的、独立于企业中各种其他应用核心资源,从而使得企业的核心信息得以重用并确
保各个操作/事务型应用以及分析型应用间的核心数据的一致性。
通过主数据管理,改变企
业数据利用的现状,从而更好地为企业信息集成做好铺垫。
实时性以及版本控制
改进商业流程并提供业务的响应速度。
从变化的频率来看,主数据和日常交易数据不一样,变化相对缓慢,另外,主数据由于跨各个系统,所以对数据的一致性、要求很高。
主数据管理其实在很早之前就一直存在,只不过现在随着业务发展以及监管的需要,对主数据的实时性、准确性、一致性有了更高的要求,才被业界广泛接受,各个厂商相应的推出了一系列的主数据管理集成与基础套件以及特定领域的解决方案。
近年来最明显的变化
是,客户在以前的时候经常问的问题是:
主数据管理是什么”,而现在客户经常问的问题演
变成了:
“我们的业务的确存在一些问题,主数据管理正好可以解决这个问题,我们怎么开
始”。
与以前相比,客户对主数据管理(MDM)的认识有了巨大的进步,并开始尝试用主数据
管理(MDM)解决他们在整个企业范围内进行跨业务、跨主题域时遇上的各种挑战和问题:
比
如税务行业,税务局在按纳税人在一些分析统计时,就发现关于纳税人的基本信息分布在核
心征收管理系统、发票管理系统、个人所得税系统、增值税管理系统等多达几十个系统中,
使得统计分析变得困难起来,在比如在医疗设备公司,由于没有按照供应商进行产品层次的
分类,各个产品的描述也很不一样,使得产品目录的维护十分困难。
随着业务的发展,
对各
行各业来说,生成并维护一个统一的主数据系统变的十分迫切和必要,
特别是对一些跨国公
司,如何在不同的地区(各个国家和地区)的业务系统之间维护关于客户、产品目录、供应商
等信息的单一视图更是重要。
需要注意的是,主数据(MasterData)和元数据(MetaData)是两个完全不同的概念。
元数据
是指表示数据的相关信息,比如数据定义等,而主数据是指实例数据,比如产品目录信息等。
比如,某省地税开发了一套征收管理软件,以市为单位部署了
17套,每套征收管理软件中
的元数据都是一样的,但是主数据还是需要进行管理的。
主数据管理和传统数据仓库解决方
案不是一个概念,数据仓库会将各个业务系统的数据集中在一起在进行业务的分析,
而主数
据管理系统不会把所有数据都管理起来,只是把需要在各个系统间共享的主数据进行采集和
发布。
相对于传统数据仓库解决方案的单向集成,主数据管理正注重将主数据的变化同步发
布到各个关联的业务系统中(主数据管理数据是双向的)。
主数据管理问题存在的根源
对于大多数的企业都存在主数据管理的问题,个人以为这是由于业务发展的渐进性以及
IT技术发展的渐进性造成的,正是由于这种渐进性,各大企业的业务系统从经历了从无到有,
从简单到复杂,从而形成了一个又一个的业务竖井。
从根本上来说,不可能只使用一个业务
系统就能覆盖企业的所有业务,即便对一些国际大型的公司提供的套件来说也是一个不可能
完成的任务(即便对套件来说,经常也存在一个跨国企业在不同的国家或地区部署多个实例
的现象,也就是没有集中部署该套件,而是在很多地方分散部署了该套件
)。
对企业来说,
业务系统的构建更多是以项目为中心,从下而上的构建系统,而不是至上而下的构建系统,
必然缺乏整个企业范围内的统一规划,从而使得一些需要在各个业务中共享的数据
(主数据)
被分散到了各个业务系统进行分别管理。
分散管理的主数据由于没有不具备一致性、准确性、
完整性,使得各个企业普遍存在着产品管理不力、供应商管理不力、订单管理不力等现象。
解决这一问题的根本方法就是引入主数据管理(MDM),主数据不光指需要共享的数据,更包
含需要共享的业务规则和策略。
主数据管理(MDM)的成熟度
根据主数据管理实施的复杂程度,参照JillDyche,EvanLevy的观点大体可以把主数据
管理可以分为五个层次,从低到高反映了主数据管理(MDM)的不同成熟度。
下面我们简单介
绍一下这五个层次:
Level0:
没有实施任何主数据管理(MDM)
在Level0的情况下,意味着企业的各个应用之间没有任何的数据共享,整个企业没有
数据定义元素存在。
比如,一个公司销售很多产品,对这些产品的生产和销售由多个独立的
系统来处理,各个系统独立处理产品数据并拥有自己独立的产品列表,
各个系统之间不共享
产品数据。
在Level0,每个独立的应用负责管理和维护自己的关键数据
(比如产品列表、客
户信息等),各个系统间不共享这些信息,这些数据是不连通的。
Level1:
提供列表
不管公司大还是小,列表管理是我们常用的一种方式。
在公司内部,会通过手工的方式
维护一个逻辑或物理的列表。
当各个异构的系统和用户需要某些数据的时候,
就可以索取该
列表了。
对于这个列表的维护,包括数据添加、删除、更新以及冲突处理,都是由各个部门
的一致性,当业务规则发生改变或者出现类似的情况时,这样高度手工管理的流程容易发生错误。
由于列表管理是通过手工管理的,其列表维护的质量取决于谁参加了变更管理流程,一旦某人缺席,将会影响列表的维护。
MDMLevel1比MDMLevel0的不同就是,各个部门虽然还是独立维护各自的关键数据,但会通过列表管理维护一个松散的主数据列表,能够向其他各个部门提供其需要的数据。
在MDMLevel1中,数据变更决定以及数据变更操作都是由人来决定的,因此,只有人完成数据变更决定后才会变更数据。
在实际情况中,虽然数据变更流程有严格的规定,但是由于缺乏集中的、基于规则的数据管理,当数据量比较大时,数据维护的成本会变的很高,效
列表管理的变更流程将变得困难
率也会很低。
当主数据,比如客户信息、产品目录信息等数量比较少时,列表管理的方式是可行的,但是当产品目录或客户列表出现爆炸式增长以后,起来。
MDMLevel1依赖于人的协作。
如果产品经理需要更新过后的产品价格列表,那需要联系ERP系统所有者,让其发送邮件给她。
在企业范围内实现客户或产品列表就如同维护不同部门之间人们的关系一样。
如果客户或产品存在层次或分组,列表将很难提供,并且通常在Level1因为过于复杂难以被管理。
Level2:
同等访问(通过接口的方式,各个系统与主数据主机之间直接互联
MDMLevel2与MDMLevel1相比,引入了对主数据的(自动)管理。
通过建立数据标
准,定义对存储在中央知识库(CentralRepository)中详细数据的访问和共享,为各个系统间
共享使用数据提供了严密的支持。
中央知识库(CentralRepository)通常会被称为主数据主机
(MasterDataHost)。
”这个知识库可以是一个数据库或者一个应用系统,通过在线的方式支持数据的访问和共享。
创建、读取、更新和删除(CRUD)是处理基本功能的典型编程术语。
即便在MDM中,C
MDM。
RUD处理也是基本功能。
你的数据库如果仅仅支持CRUD处理并不意味着你实现了
MDMLevel2引入了同等访问”(peebasedaccess),也就是说一个应用可以调用另一个应
等”应用格式化请求(和数据),以便和MDM知识库保持一致。
MDM知识库提供集中的数据存储和供应(provisioning)。
在这个阶段,规则管理、数据质量和变更管理必须在企业范围内作为附加功能定制构建。
比如,一个数据库或一个打包应用(比如一个销售自动化系统)对外部应用提供数据访问
功能。
当一个外部应用(比如呼叫中心应用)需要增加一个客户,这个外部应用将提交一个事
务,请求数据所有者增加一个客户条目。
主数据主机(MasterDataHost)将增加数据并告知
MDM
外部应用。
CRUD处理方式比纸上办公有了很大提高,其是基于会话的数据管理。
在
Level1,数据变更是基于手工的方式。
在MDMLevel2,数据变更是自动完成的—通过由
使用和变更单一、共享的数据知识库。
MDMLevel2需要每个同等应用理解基本的业务规则以便访问主列表、与主列表进行交互。
因此,每个同等应用必须正确恰当地创建、增加、更新和删除数据。
授权应用有责任坚持数据管理原则和约束。
Level3:
集中总线处理
与MDMLevel2相比,MDMLevel3打破了各个独立应用的组织边界,使用各个系统
都能接受的数据标准统一建立和维护主数据(MDMLevel2的主数据主机上存储的数据还是
集中处理意味着为MDM构建了一个通用的、基于目标构建的平台。
大多数公司发现
中数据访问、控制跨不同应用和系统使用数据。
这极大的降低了应用数据访问的复杂性,
一个共识,从多个系统整合主题域数据,意味着使用集中、标准化的方法转换异构操作数据,
用集中管理方式。
这意味着应用系统,作为消费者或使用主数据,拥有一个共识就是数据是
主题数据内容的映像,打破了各个独立应用的组织边界。
MDMLevel3支持分布主参考数
据的存在。
MDM的核心之一就是保证所有系统都能接受数据表示的唯一公认方法。
这有点类似
于语言翻译,通过其他语言的翻译,英语已经称为一个全球性的语言。
在
MDMLevel3,
一个公司可以让任意两个系统共享数据和说对方的语言。
MDMLevel3还降低了等同访问
的复杂性。
"消费"应用不再需要支持系统定位和操作逻辑。
任何与源系统数据相关的分布式
细节都会被MDM总线集中处理。
在MDMLevel3自动数据标准意味着:
建立目标数据值
表示和通过必要的步骤提供精确的主数据值捕获。
在所有的分类中从
MDMLevel3开始第
一次支持一致性的企业数据视图。
数据质量规则在这里进行数据清洗和错误纠正。
Level4:
业务规则和政策支持
一旦数据从多个数据源整合在一起,主题域视图超越单独的应用并表现为一个企业视
图,你将获得事实的单一版本。
当事实的单一版本已经能够提供出来时,来自业务主管和执
行人员的必然反应经常是:
“证明它”。
MDMLevel4可以保证主数据反映一个公司业务规
则和流程,并证实其正确性。
MDMLevel4通过引入主数据来支持规则,并对MDM总线
以及其它外部系统进行完整性检查。
由于多数公司相对比较复杂,影响业务数据访问和操作
的规则以及策略(rulesandpolicies)相对也比较复杂。
假定任何一个单一系统可以包含并管
理与主参考数据相关的各种类型的规则是不切实际的。
因此,如果一个MDM总线真正打算
提供企业范围内数据的精确性,工作流和流程整合的支持是必不可少的。
举例来说,在一个HMO内,需要多个应用来支持一个病人的护理。
一个单一的访问
(vi
sit)可能包括入院、房间和床位分配、监控设备、化验、身体检查以及其他程序等。
一旦一
个病人准备离开医院,出院流程需要确保和这个病人相关的所有活动、资源都被结清。
MD
M技术在召集多个应用系统一起保证病人辨识方面是十分有效的,处理是正确的。
虽然病
人辨识很重要,业务规则整合同样重要。
临床系统依靠一系列的业务流程和数据规则来辨别
所有显着的病人详细资料。
这包括返回所有基于房间的资源
(监护设备、床位等)以得到有用
的详细目录,当病人要出院时分解其所有的费用。
MDM保证当JohnSmith出院时,正确的
房间和设备放入到该JohnSmith的详细目录中,而不是其他的JohnSmith(正在另一个楼层
做身体治疗)。
MDM系统必须不仅支持基于规则的整合,还要能够整合外部的工作流。
这些规则可能
个MDM总线,规则定义可以不仅局限在逻辑上,还可以依赖于其他系统的输入。
当然,协
调和审计数据意味着可以回退其他系统(或业务流程)来保证数据变化经过严格的审批,这样
性的支持。
通过总线以一个灵活可持续的方式支持任何面向业务的规则集合这很重要。
商品管理系统)进行协商以便使规则生效。
详细规则将支持另一个系统中存在产品价格的变
或隐私限制,禁止它们直接在总线上存在。
在MDMLevel4,一个企业可以支持一套步骤
或任务,在一个特殊的创建、读取、更新和删除任务被允许之前这些步骤或任务必须遵守。
工作流:
它可以包括基于逻辑的流程和基于人的决策。
变更管理的存在可以支持动态业务,
允许变更。
举例说明,在911之前,任何人都可以在美国国内的航空公司运载货物。
没有规
定以外的其他某种形式的鉴定和付款方式。
911之后,美国联邦航空协会(FAA)指导建立了一
个更加全面的规定,指示一个人是否被允许运载货物。
在这个特殊的例子中,要求各个系统
M总线)集中托运人批准规则,更加容易实现(也更现实)。
集中数据定义和标准化在MDML
evel2就已经引入,与MDMLevel4的集中规则管理相比,相对简单。
业务流程越复杂、
业务流程越多,对总线的需求就越多,以便对针对共同数据的跨职能、异构规则进行更好的
支持。
重要的是MDMLevel4支持集中规则管理,但是规则本身和相关的处理是可以分开
的。
换句话说,MDM总线需要保证规则是集中应用的,即便这个规则是在总线外居住的。
Level5:
企业数据集中
在MDMLevel5,总线和相关的主数据被集成到独立的应用中。
主数据和应用数据之间没有明显的分隔。
他们是一体的。
当主数据记录详细资料被修改后,所有应用的相关数
这本质上
据元素都将被更新。
这意味着所有的消费应用和源系统访问的是相同的数据实例。
是一个闭环的MDM:
所有的应用系统通过统一管理的主数据集成在一起。
在这个级别,所
有在系统看起来都是事实的同一个版本。
操作应用系统和MDM内容是同步的,所以当变更
当数据数据更新时,
5提供一个集成的,
总线更新所有的操作应用系统将体现这种变更,形成改变的直接操作视图。
在注册环境中,
总线将通过Web服务连接相关系统应用事务更新。
因此,MDMLevel
种更新变的透明。
从MDMLevel4到MDMLevel5意味着MDM功能性不是在一个应用内被特殊设计或编码
总线和支持的IT基础架构,所有的应用可以访问主参考数据。
一个公司在完成MDMLevel
5后将使他们所有的应用连在一起—既包括操作的也包括分析的—所有访问主数据是透明
的。
举例说明,当一个客户更新她的状态—不要管注册该变更的系统—数据变更将被广播到
所有的应用平台(因此一致起来)。
MDMLevel5是把数据概念作为一种service来实现。
MD
据业务规则变化实际上是一回事。
MDMLevel5移走了主数据的最后一个障碍:
统一采用
数据定义、授权使用和变更传播。
如何构建一个主数据管理(MDM)的解决方案
在开始构建主数据管理(MDM)解决方案之前,首先需要明确我们当前的数据管理现状是
第二步,需要确定我们的每个主数据域的范围(这也是前期需求分析的一部分)。
常见的
主题域有:
同步的架构,当一个有权限的系统更新一个数据值时,公司内所有的系
Party:
可以反映任何合法的实体,无论是个体还是组织。
Product:
既包括物理存在的货物,也可以是任何服务。
Account:
包括期限和条件,以及相关的各种关系。
Location:
既可以独立存在,也常常与其他主数据域共存。
第三步,进行数据管理系统的设计,在设计时要注意以下几点:
数据采集和发布是否实时,最小的响应时间是多少。
数据转换规则能否让客户定制,而不是硬编码。
如果根据数据质量标准清理主数据域中的主数据。
权限控制。
主数据的历史版本控制以及变更监控控制(当主数据变化时,要能记录该变化,另外还
第四步,开发部署测试。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 数据管理 详解 MDM