主数据管理MDM的成熟度.docx
《主数据管理MDM的成熟度.docx》由会员分享，可在线阅读，更多相关《主数据管理MDM的成熟度.docx（7页珍藏版）》请在冰豆网上搜索。
主数据管理MDM的成熟度
主数据管理（MDM）的成熟度
MDM全写MasterDataManagement，翻译为主数据管理或元数据管理。
什么是MDM
企业主数据是用来描述企业核心业务实体的数据，比如客户、合作伙伴、员工、产品、物料单、账户等；它是具有高业务价值的、可以在企业内跨越各个业务部门被重复使用的数据，并且存在于多个异构的应用系统中。
主数据和主数据管理的概念
企业主数据可以包括很多方面，除了常见的客户主数据之外，不同行业的客户还可能拥有其他各种类型的主数据，例如：
对于电信行业客户而言，电信运营商提供的各种服务可以形成其产品主数据；对于航空业客户而言，航线、航班是其企业主数据的一种。
对于某一个企业的不同业务部门，其主数据也不同，例如市场销售部门关心客户信息，产品研发部门关心产品编号、产品分类等产品信息，人事部门关心员工机构，部门层次关系等信息。
数据管理的范畴和主数据管理的概念
如图所示，企业数据管理的内容及范畴通常包括交易数据、主数据以及元数据。
● 交易数据：
用于纪录业务事件，如客户的订单，投诉记录，客服申请等，它往往用于描述在某一个时间点上业务系统发生的行为。
● 主数据：
主数据则定义企业核心业务对象，如客户、产品、地址等，与交易流水信息不同，主数据一旦被记录到数据库中，需要经常对其进行维护，从而确保其时效性和准确性；主数据还包括关系数据，用以描述主数据之间的关系，如客户与产品的关系、产品与地域的关系、客户与客户的关系、产品与产品的关系等。
● 元数据：
即关于数据的数据，用以描述数据类型、数据定义、约束、数据关系、数据所处的系统等信息。
主数据管理是指一整套的用于生成和维护企业主数据的规范、技术和方案，以保证主数据的完整性、一致性和准确性（“Thesetofdisciplines,technologies,andsolutionsusedtocreateandmaintainconsistent,complete,contextualandaccuratebusinessdataforallstakeholders（users,applications,datawarehouses,processes,companies,tradingpartners,customers,etc.）acrossandbeyondtheenterprise”）。
主数据管理的典型应用有CustomerDataIntegration—客户数据管理和ProductInformationIntegraiton—产品数据管理。
图2.主数据管理的信息流
一般来说，主数据管理系统从IT建设的角度而言都会是一个相对复杂的系统，它往往会和企业数据仓库/决策支持系统以及企业内的各个业务系统发生关系，技术实现上也会涉及到ETL、EAI、EII等多个方面，如图2所示，一个典型的主数据管理的信息流为：
1. 某个业务系统触发对企业主数据的改动；
2. 主数据管理系统将整合之后完整、准确的主数据分发给所有有关的应用系统；
3. 主数据管理系统为决策支持和数据仓库系统提供准确的数据源。
因此对于主数据管理系统的建设，要从建设初期就考虑整体的平台框架和技术实现。
MDM的意义
如图3所示：
集成、共享、数据质量、数据治理是主数据管理的四大要素，主数据管理要做的就是从企业的多个业务系统中整合最核心的、最需要共享的数据（主数据），集中进行数据的清洗和丰富，并且以服务的方式把统一的、完整的、准确的、具有权威性的主数据分发给全企业范围内需要使用这些数据的操作型应用和分析型应用，包括各个业务系统、业务流程和决策支持系统等。
主数据管理使得企业能够集中化管理数据，在分散的系统间保证主数据的一致性，改进数据合规性、快速部署新应用、充分了解客户、加速推出新产品的速度。
从IT建设的角度，主数据管理可以增强IT结构的灵活性，构建覆盖整个企业范围内的数据管理基础和相应规范，并且更灵活地适应企业业务需求的变化。
以客户主数据为例，客户主数据是目前企业级客户普遍面临的一个问题，在大多数企业中，客户信息通常分散于CRM等各个业务系统中，而每个业务系统中都只有客户信息的片断，即不完整的客户信息，但却缺乏企业级的完整、统一的单一客户视图，结果导致企业不能完全了解客户，无法协调统一的市场行为，导致客户满意度下降，市场份额减少。
因此，建立客户主数据系统的目的在于：
● 整合并存储所有业务系统和渠道的客户及潜在客户的信息：
一方面从相关系统中抽取客户信息，并完成客户信息的清洗和整合工作，建立企业级的客户统一视图；另一方面，客户主数据管理系统将形成的统一客户信息以广播的形式同步到其他各个系统，从而确保客户信息的一致；
● 为相关的应用系统提供联机交易支持，提供客户信息的唯一访问入口点，为所有应用系统提供及时和全面的客户信息；服务于OCRM系统，充分利用数据的价值，在所有客户接触点上提供更多具有附加价值的服务；
● 实现SOA的体系结构：
建立客户主数据系统之前，数据被锁定在每一个应用系统和流程中，建立主数据管理系统之后，数据从应用系统中被释放出来，并且被处理成为一组可重用的服务，被各个应用系统调用。
MDM的模式
元数据管理涉及到各个层次的元数据，管理的内容包括元数据的获取、元数据的更新、使用和面向应用项目的元数据使用处理等多个方面。
元数据的管理涉及数据库、数据处理软件、数据使用系统、面向应用的数据分析等各个环节。
下面给出了一种普通意义的以元数据信息系统为基础的元数据管理模式：
通常意义上的元数据管理是指元数据通过各种途径形成后，对其内容的添加、删除、更新等涉及内容改变的操作和元数据内容检索、查询、放置、组织等常规性元数据操作，从这种意义上元数据的管理可以通过两种方式实现，即系统管理模式和用户管理模式。
系统管理模式是面向数据库的，由数据库管理系统专业人员完成，数据用户只有使用权，没有元数据的操作权，数据应用项目中新生成的数据集的元数据也有应用系统传递给数据库管理员，然后由数据库管理员统一管理。
这种方式中，数据在处理过程中形成的动态元数据很难及时记录下来。
另一种管理方式是用户管理模式，它是面向应用项目的，即允许某些数据用户在数据应用元数据的变动信息直接反馈给元数据库，这样则能保证元数据的动态更新和新生成数据集元数据的及时捕获及写入元数据文件。
但这种模式中数据用户的权限要适当的控制，以避免数据库的破坏。
通常对元数据的管理是采用两者结合的模式。
主数据（MDMasterData）指系统间共享数据（例如，客户、供应商、账户和组织部门相关数据）。
与记录业务活动，波动较大的交易数据相比，主数据（也称基准数据）变化缓慢。
在正规的关系数据模型中，交易记录（例如，订单行项）可通过关键字（例如，订单头或发票编号和产品代码）调出主数据。
主数据必须存在并加以正确维护，才能保证交易系统的参照完整性。
从报告或维度建模角度看，主数据指基于其组织或配置指标的维度或层次，而不是实际情况或其自身测量结果。
例如，收入、成本和利润是实际情况，而时间、地点、客户和供应商是维度。
应根据以下因素或更多因素综合考虑主数据：
企业绩效管理报告（如利润或收入计划随产品、客户、账户等产生的变化）要求综合多个系统的主数据。
遵从报告要求一致性主数据。
同步交易系统处理特定客户（如提供具体报价）或供应商（如指定采购的首选供应商）。
主数据管理（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移走了主数据的最后一个障碍：
统一采用数据定义、授权使用和变更传播
升级会员 