主数据管理详解

什么是主数据管理(Master Data Management ,MDM)

主数据是指在整个企业范围内各个系统( 操作/事务型应用系统以及分析型系统)间要共享的数据,比如,可以是与客户(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),主数据不光指需要共享的数据, 更包含需要共享的业务规则和策略。

主数据管理(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因为过于复杂难以被管理。

时间: 2024-11-05 16:38:23

主数据管理详解的相关文章

php内存管理详解

php的内存管理 php和c最重要的区别就是是否控制内存指针. 内存 在php中, 设置一个字符串变量很简单: <?php $str = 'hello world'; ?>, 字符串可以自由的修改, 拷贝, 移动. 在C中, 则是另外一种方式, 虽然你可以简单的用静态字符串初始化: char *str = "hello world"; 但是这个字符串不能被修改, 因为它存在于代码段. 要创建一个可维护的字符串, 你需要分配一块内存, 并使用一个strdup()这样的函数将内

Linux账户管理详解

当用户登陆Linux系统时,Linux将做如下检查: 1)在/etc/passwd文件里匹配输入的用户名,获取该用户名的UID和GID(其中GID和/etc/group关联) .Home目录和Shell设置 2)在/etc/shadow里核对该用户的密码 /etc/passwd文件结构 这个文件的每一行代表一个账号,如下所示: oracle:x:501:501::/home/oracle:/bin/bash 1. 用户名 2. 密码:早期的密码放在该字段,但如今的密码已单独放在/etc/shad

Linx 卷管理详解--VG LV PV

Linx卷管理详解 VG LV PV 作者:吴伟龙   一. 前言     每个Linux使用者在安装Linux时 都会遇到这样的困境:在为系统分区时,如何精确评估和分配各个硬盘分区的容量,因为系统管理员不但要考虑到当前某个分区需要的容量,还要预见该分区以后可能需要的容量的最大值.因为如果估计不准确,当遇到某个分区不够用时管理员可能甚至要备份整个系统.清除硬盘.重新对硬盘分区,然后恢复数据到新分区.      虽然现在有很多动态调整磁盘的工具可以使用,例如Partation Magic等等,但是

Crashlytics Android 异常报告统计管理(详解)

简介 Crashlytic 成立于2011年,是专门为移动应用开者发提供的保存和分析应用崩溃信息的工具.Crashlytics的使用者包括:支付工具Paypal, 点评应用Yelp, 照片分享应用Path, 团购应用GroupOn等移动应用. 2013年1月,Crashlytics被Twitter收购,成为又一个成功的创业产品.被收购之后,由于没有了创业公司的不稳定因素,我们更有理由使用它来分析应用崩溃信息. 使用Crashlytics的好处有: 1.Crashlytics不会漏掉任何应用崩溃信

DB2表空间管理详解(原创)

create tablespace语法树 >>-CREATE --+-----------------------+---------------------------->            +-LARGE-----------------+               +-REGULAR---------------+               | .-SYSTEM-.            |               '-+--------+--TEMPORARY-'  

linux那点事儿(四)----用户管理详解

用户管理----用户信息与密码的配置文件                                                                                                                   用户管理要学的内容很多,当然了,不会简单的放两个创建用户的命令,这样的文章太多了.我们来看两个用户管理中非常重要的配置文件吧!      我们来看看用户的相关配置文件都存放在什么地方. 用户信息文件:      /etc/pass

asp内置对象 ObjectContext 事务管理 详解_应用技巧

asp内置对象 ObjectContext 详解 您可以使用 ObjectContext 对象提交或放弃一项由 Microsoft Transaction Server (MTS) 管理的事务,它由 ASP 页包含的脚本初始化.  ASP 包含 @TRANSACTION 指令时,该页会在事务中运行,直到事务成功或失败后才会终止.  语法 ObjectContext.method 方法 SetComplete SetComplete 方法声明脚本不了解事务未完成的原因.如果事务中的所有组件都调用 

Yii框架组件和事件行为管理详解_php实例

本文实例讲述了Yii框架组件和事件行为管理.分享给大家供大家参考,具体如下: Yii是一个基于组件.用于开发大型 Web 应用的高性能 PHP 框架.CComponent几乎是所有类的基类,它控制着组件与事件的管理,其方法与属性如下,私有变量$_e数据存放事件(evnet,有些地方叫hook),$_m数组存放行为(behavior). 组件管理 YII是一个纯oop框架,很多类中的成员变量的受保护或者私有的,CComponent中利用php中的魔术方法__get(),__set()来访问和设置属

Android开发教程之电源管理详解_Android

本文实例讲述了Android电源管理.分享给大家供大家参考,具体如下: 一. 相关概念 1. 出于节电的需要,一般应用在用户一段时间无操作的情况下屏幕变暗,然后进入休眠状态 2. 用户只能在"设置->声音和显示"中设置所有应用默认的屏幕亮度和进行待机的时间 3. 电源管理的实现分内核应用两部分,通过下面介绍的接口,我们可以设置应用程序的电源管理,以控制与其休眠相关的状态(是否需要进入休眠,调整cpu频率,键盘灯的开关,屏幕的亮暗等) 二. 设置电源管理常用的几种状态 PARTIA