1. 为什么需要主数据管理
1.1. MDM 的定义
"The whole is more than the sum of the parts." --Aristotle
整体比部分相加之和的内容要多。――亚里斯多德
这句亚里斯多德的哲学名言，很适合来描述主数据管理（MDM ，master data management）。MDM 主要关注于研究、分类和访问企业内的重要数据。也就是说，MDM 帮助你理解企业内的每一份数据，包括客户、产品、场所和其他的主要的主题域等内容。在这篇研究文章中，清晰的给出了MDM 的定义，详细说明了建立MDM 将会产生的收益和结果，也说明了建立MDM 需要的各种技术，以及实现MDM 的实践步骤。
为了更深入的解释MDM ，说明它的好处和用法，本篇文章中列举了很多实际的案例。其中每一个案例都是从实际的业务出发，通过对业务和技术问题的分析，总结了一套实现MDM 的方法和技巧。通过这套方法，可以避免实现中的一些缺陷，增加实现的成功率。
为什么需要主数据管理？
主数据管理：定义
我们从定义MDM 是什么开始，关于这个问题有两种观点，分别对应于MDM 这个词组的重音位置的不同。
1．主数据管理－或者称为管理主数据。这包括建立和维护主数据的一些管理性的应用。例如，客户数据整合（CDI ，customer data integration），产品信息管理（PIM ，product information management），以及用来管理类似数据主题的其他应用。
2．主数据管理－或者称为数据管理之后的一系列管理过程。这包括整合企业数据（包括主数据）所需要的基础结构和技术。例如ETL （extraction, transformation, and load）和EII （enterprise information integration）等技术。 从本篇研究文章的目的出发，我们采用第一种观点，即认为MDM 的功能是管理各种类型的主数据。当然，第二种观点中涉及的基础结构和技术对支持MDM 处理过程和应用也都是必要的。
我们对MDM 的官方定义为：
A set of disciplines, applications, and technologies for harmonizing and managing the system of record and system of entry for the data and metadata associated with the key business entities of an organization.
主数据管理是一系列的规则、应用和技术，目的是为了协调和管理与企业的核心业务实体相关的系统记录和系统登录中的数据和元数据。
在这篇文章中提及了一些专有名词，这些名词对理解本文很重要。这些名词的定义在文章末尾的附录A 中。在继续阅读这篇文章前，请先熟悉这些名词。
1.2. MDM 的内容
MDM 的内容
简单的说，主数据是企业内关于核心业务实体的参照数据。这些业务实体包括：
1．人员－例如，客户，雇员（人力资本），供应商，合伙人等。
2．事物－包括产品，财务（分类帐），资产等。
3．场所－企业感兴趣的位置和地点。
4．其他关键实体－企业感兴趣的其他数据。每个企业都会有自己特有的关键实体。
图1：主数据包括很多业务实体，如客户主数据、产品主数据、财务主数据及其他主数据等。 图略。
MDM 应用包括一系列的处理过程，这些处理过程包括整合、存储、维护企业内业务实体的特定实例，如将企业内地理位置数据、产品数据和客户数据等做标准化处理。完整的维护后，主数据就成为了这些实体的系统记录（SOR ，
system of record），也就是说，对于每一个实体，MDM 中提供的数据就是该数据的完美的最终版本。这些数据也是企业内参照数据的最终版本。
讨论一下哪些数据不包括在我们对MDM 的定义内，也同样是非常重要的事情。MDM 应用不会保存那些和业务实体相关的特定业务处理数据（BTx ，business transaction），例如与客户实体相关的帐户余额信息、取款信息。这些业务处理系统产生的数据会被整合到操作数据存储（ODS ，operational data store）中。而BTx 的历史数据会保存在商业智能（BI ，business intelligence）部件中，如数据仓库和数据集市。
没有一个强制的规则，认为所有的主数据必须保存在MDM 系统中。有些主数据的维护必须保留在业务处理应用（BTx ）中，或者保留在外购应用，如前端的CRM 中。这使企业的IT 环境变得复杂，也给主数据的质量和准确性带来了挑战。这个主题我们会在本文的后面章节进行详细的讨论。
1.3. MDM 的业务目的
通过对没有MDM 的IT 环境进行分析，我们可以很容易的理解MDM 的业务目的。分析结果可以总结为下面的四个主要问题：
1．数据冗余
没有MDM 功能，企业内的每一个系统、应用、甚至业务部门都会收集自己版本的核心业务实体数据。最好的例子就是对客户数据的收集。客户的关键属性如客户名称和地址信息在企业内各个角落都被重复的记录着。非常遗憾的是，在这个收集客户信息的过程中，很少会产生相同或者一致的结果。这导致了一个很严重的问题（除了存储成本之外），数据冗余导致数据质量过差。
根据The Data Warehousing Institute的一份报告（Data Quality and the Bottom Line, by Wayne Eckerson）显示，由于数据质量过差，企业每年的总共损失超过$600 billion，而且其中的大部分成本是因为冗余、低质量的主数据引起的。这也引起了下面提到的第二个主要问题。
2．数据不一致
由于企业内主数据的不一致，导致企业大量的资源浪费，包括时间、金钱和人力资源等的浪费。判断企业内一个客户的真正地址或姓名是到底什么并不能增加企业的收入。而且非常不幸的是，因为没有一个存储机制用来保存比对过的客户数据，这种对客户数据进行一致处理的过程需要重复出现。
3．业务低效
凌乱的主数据会导致各种业务低效的情况发生，如低生产力，低效的供应链管理，不一致的客户待遇，客户不满意，浪费市场部门的努力等。一个客户服务代表需要综合几个操作型系统去判断一个客户的真正状态，这不仅是低效的，而且有可能会由于信息的不全使客户产生不满意而逐渐失去这个客户。企业内的各种工作都显示出，凌乱的主数据管理严重降低了企业的效率。
4．业务变化
企业内经常发生各种变化，如引入新的产品和服务，公司合并与吞并，新技术出现并成熟。这些企业内的各种变化都会导致企业主数据的变化，如果没有一套机制来管理这些变化，企业在数据冗余、数据不一致和业务低效等方面的问题就会不断加剧。
1.4. MDM 的案例
没有MDM ，企业缺乏关于他们客户、产品及其他核心业务实体的完整的视图，而这个完整的视图可以提供给企业预测和控制未来的能力。下面提供的四个关于MDM 的案例中，每一个都有非常权威的业务目的。所有的这些都为了解决两个主要目标：增强企业的生产力和增强企业的收益率。
Honeywell
Honeywell 公司部署了一个关于客户管理的MDM 方案，通过这个MDM 方案，可以为客户提供更好的服务，为企业提供新的机会。在这个方案中，能以各种单位来交互式的访问和分析采购数据及销售数据，这将会提高客户满意度、增加销售收入。这个方案不仅有企业高层的支持，也受到了销售组的强烈支持，他们认为通过使用这个系统可以更好的管理客户关系，可以得到更好的收益。
Mentor Graphics
为了提高生产力，Mentor Graphics建立了一个集中的MDM 系统，这个系统整合并管理了销售、产品和组织的主数据，并按固定的时间间隔将其发布到业务处理系统和商务智能系统之中。业务用户可以通过这个系统控制主数据的变化，并将变化发布到企业内所有的系统，这也使他们对业务处理更加深了一步。这个系统为计划改编和重组提供了更好的工具和信息，提高了决策支持的能力。通过使用一个单独的系统来验证及核实主数据，数据的质量也得到了提高。
A Nonprofit Member Organization
对于非盈利性组织来说，他们面临的挑战是管理从外部数据源收集的所有数据，他们需要对这些数据进行精加工，确保这些数据的可靠性、一致性、可访问性和及时性。他们通过对业务规则的全面理解，建立了一个存储高质量的会员数据的知识库系统。这个系统帮助他们解决数据不一致的情况，验证了会员的名称和地址，并降低了市场的开销，减小了邮件成本，增强了服务的效率。这个方案免去了很多为了使数据可用而做的手工处理，尽管投资是在一个非盈利性的项目，但是企业的预算减少了。现在，业务人员可以花费更多的时间在分析数据上，而不必在格式化数据及清洗数据上花费时间。
Match Supermarkets
Match Supermarkets 需要以一种通用的格式组织企业内的数据，这样其他系统如操作型应用系统，EDI 系统和数据仓库系统都可以很容易的访问这些数据。他们建立了一个实时的、事件驱动的MDM 整合中心，在这个整合中心中保存了企业主数据的通用格式。这个整合中心将其中的通用格式的主数据发布到企业的每一个地方，增强了他们的操作型接口及EDI 处理的效率。
更详细的说明
下面列出的四个公司对MDM 应用的实现方式提供了更详细的说明，下面也列出了他们MDM 产品的一些情况。 IBM:
1．Master Data Management Solution Overview
2．Honeywell Case Study
Hyperion:
1．Master Data Management Solution Overview
2．MentorGraphics Case Study
DataFlux:
1．Master Data Management Solution Overview
2．Nonprofit Organization Case Study
Sunopsis:
1．Master Data Management Solution overview
2．Supermarch és Match Case Study
1.5. 关于MDM 的误解
由于MDM 是一个相对较新的领域，业内对于MDM 是什么、在企业内应该如何来实现等问题有一些不同的观点。下面列出了我们在研究中遇到的一些关于MDM 的误解：
1．MDM 是一个数据仓库或商业智能项目。
这是不正确的，MDM 既不是BI/DW项目，也不是操作型项目。MDM 是另一类实现方式，它的建立对前面的两种环境都很有利。MDM 可以使用操作型环境作为自己的数据源，但是一旦数据被清洗、整合、加载入MDM 知识库后，这些数据就成为数据仓库、ODS 、数据集市等的数据源或者SOR 。
2．MDM 仅仅为了维护企业内业务处理应用中数据的一致性。
这也是不正确的。当然主数据可以维护这些系统中数据的一致性，但是它的作用不仅仅如此。作为SOR ，主数据知识库可以作为各种系统、应用和环境的标准数据源。
3．MDM 只是另一个数据整合项目。
这是不正确的，MDM 项目除了数据整合之外，还需要业务用户的参与并制定MDM 的原则和政策等内容。MDM 功能是全企业的事情，企业内的每一个应用都会和主数据的设计、配置和使用有关。数据专员和数据管理员都需要进入MDM 项目之中，来解决全企业的主数据统一视图的问题。
4．MDM 整合并管理了所有的企业数据。
这是不正确的。MDM 仅为核心业务实体提供SOR 。其他的事务数据必须被维护到其他地方，如操作型系统、ODS 或者具有混合负载的数据仓库环境中。
2. 二、主数据管理的概念及技术
2.1. 在传统IT 环境中的关于主数据的问题
在今天的大多数企业里，没有一个单一的MDM 环境来管理主数据，主数据被分散在多个业务处理系统（BTx ）中，这些业务系统关于主数据都有自己的业务模型、规则和定义。不同业务系统中的数据、业务模型、规则等经常出现重叠和冲突的情况，这使得在企业内获得一致、准确的操作型主数据变得非常困难。
图2：传统IT 环境中的主数据处理，SOE 和SOR 都在业务处理系统之中，主数据和事务数据保存在ODS 或者数据仓库之中，业务处理系统中的数据通过数据整合服务来提供给ODS 和数据仓库。 图略。
为了在商业智能环境中解决主数据的一致性问题，很多企业整合并维护了主数据的历史记录，并将它们和事务数据一起保存在数据仓库之中。有很多建立数据仓库方法，但是通常来说，对当前的主数据和事务数据进行整合、合并及传播等处理，并将结果保存在存储低延迟数据的ODS 之中，而历史的细节数据和汇总数据则保存在企业的数据仓库或者数据集市之中。
如果因为成本或者安全等原因，不能将操作型事务数据整合入数据仓库之中的话，可以使用数据联邦技术来提供分散在不同的业务处理系统中的事务数据的单一视图。当应用程序通过这个虚拟的数据视图来查询时，数据联邦软件可以在运行时动态的收集和整合操作型事务系统中的数据。数据联邦技术可以解决一部分数据质量和数据一致性的问题，但是它不适合解决较复杂的数据问题。
2.2. 建立一个整合的MDM 环境
有很多不同的方法来整合及管理主数据。在详细讨论这些方法之前，让我们首先确定一下关于MDM 系统的理想的架构是什么样的。就像我们后面将要看到的，这个架构的目标需要通过迭代和逐步进化的应用处理来得到。
在一个企业MDM 系统中，所有的主数据都是通过MDM 应用程序来进行管理的，也是通过这些应用程序发布给业务用户和其他IT 系统。这些应用程序管理主数据及其元数据的变化情况，并维护这些变化的历史记录。举例来说，一个MDM 应用可以管理并跟踪客户帐户数据，如帐户标识、客户名称、客户地址、信用等级等数据。
图3：MDM 系统的数据流，主数据的变化由MDM 应用来维护，MDM 应用将维护好的主数据发布给业务处理系统
和商业智能系统，事务数据直接从业务处理系统进入商务智能系统。 图略。
MDM 系统根据需要将主数据传播给内部及外部的其他IT 系统。它也会提供关于主数据的业务视图，通过这个视图业务用户和应用程序可以直接访问MDM 系统。MDM 应用不会维护其他类型的业务处理数据，如客户帐户的余额及取款数据等。这些数据由业务处理应用来维护。
图4展示了企业MDM 系统中的主要部件。它们包括：
1．MDM 应用，管理和发布主数据及其元数据。
2．主数据存储（MDS ），保存合并后的主数据。
3．主数据的元数据存储（MMS ），保存主数据业务模型、主数据规则和定义。主数据业务模型记录了主数据实体、属性、关系和其他业务含义。
4．一系列的主数据整合（MDI ）服务，用来合并、联邦及传播主数据。
图4略。
业务用户使用定制的或者打包的MDM 应用去访问和维护存储在MDS 中的主数据。这个MDS 中存储了企业范围的主数据的SOR 。关于SOR 的信息，记录在MMS 中。MMS 中的业务规则可以确保主数据与企业实际的业务惯例相一致。
在一个完全一致的MDM 环境中，所有的主数据及其元数据都在MDM 系统中进行管理。当然，也不必将所有的主数据维护操作都从业务处理系统中移植到MDM 系统中。但是需要注意的一点是，即使有些主数据的维护是在MDM 系统之外，也要确保这些主数据的SOR 在MDM 系统之中。为了解释这一点，我们有必要更详细的解释一下主数据的SOR 和SOE 的区别。
2.3. SOR 和SOE
SOR 和SOE
系统记录（SOR ，System of Record）是一个应用系统，它的目的是发布主数据及其相关的元数据，并保证它们的正确性。系统登录（SOE ，System of Entry ）是一个应用系统，它的目的是建立和维护主数据及其相关的元数据。在一个完全一致的MDM 系统中，SOR 和SOE 是同一个系统。如果不是完全一致的MDM 系统，需要由IT 方与用户共同协商，并将协商结果进行记录。
如果SOE 不在MDM 系统中，当外部的SOE 中的主数据及其元数据发生变化时，必须通知MDM 系统，然后，MDM 系统将这部分的变化进行发布，使企业内的其他IT 应用得到变化的信息。
外部SOE 可以通过数据传播方式将主数据的变化发给MDM 系统。也可以使用联邦技术使MDM 系统可以直接读取SOE 中主数据。主数据整合服务为实现这些功能提供了数据传播和数据联邦的技术实现。
图5：SOE 有可能不是MDM 系统的一部分，当SOE 不是MDM 系统的一部分时，有两个方式可以将主数据的变化
传播到MDM 系统，第一种是SOE 通过数据传播技术发布主数据的变化，第二种是建立主数据的联邦视图，MDM 系统自己去读取主数据。图略。
当SOE 和SOR 不是同一个系统时，维护数据质量是一个最大的问题。在理想情况下，SOE 可以使用和MDM 系统相同的主数据的元数据服务及数据质量。当业务处理应用是定制程序或者打包程序时，SOE 很难使用MDM 系统提供的数据及服务。但是很重要的一点是，只要有可能，就应该使MDM 和SOE 使用相同的主数据管理程序和业务模型，这可以最大化主数据的准确性。一个整合资格中心可以扮演这个重要的角色，来管理这些程序、模型和规则。
2.4. MDM 在IT 基础结构中的角色
MDM 系统、应用及服务经常作为已存在的业务处理系统和商业智能系统在战术上的扩展。但是，为了企业的发展，一个从战略层面上考虑的MDM 方案应该被单独的提出来，这个方案应该是全企业范围的，应该有企业的高层支持。这个MDM 系统应该作为主数据的有效资源，给其他IT 系统提供主数据。它不应该只在已有的IT 应用上进行调整，也不应该为了解决一些问题而建立成分散的主数据管理应用。
MDM 不应该是一个自底向上的战术项目，企业必须要有一套战略的MDM 计划。企业应该建立一个全企业范围的主数据管理，真正去解决主数据问题，而不应该为了减小企业主数据问题而在原有系统上修修改改。
2.5. 整合及管理主数据的技术
前面我们回顾了主数据管理的概念，接着我们开始讨论实现主数据管理系统的不同技术。
有三个主要的技术用来整合及管理主数据：主数据标识登记、主数据整合中心及企业主数据管理。有些企业综合使用这些技术来建立混合解决方案。
1．主数据标识登记（Master data identity registry）
主数据标识登记技术通过一个标识管理程序来创建和维护一个关于主数据的知识库，这个知识库中保存各个业务处
理应用中的主数据。这个知识库中保存主数据的全局标识，通过这个标识将不同的业务处理应用中的主数据互相连接在一起。这个全局标识和数据联邦软件结合在一起可以建立一个虚拟的主数据SOR 。
图6 主数据标识登记，主数据标识登记可以建立虚拟的SOR ，ODS 和DW 中需要保存主数据及事务数据。 图略。
2．主数据整合中心（Master data integration hub）
主数据整合中心的实现方式是将主数据的变化传播到不同的业务处理应用中。尽管这个传播处理一般来说是异步方式实现的，数据的交付还是可以得到保证的。有些整合中心提供主数据合并的功能，并将合并后的主数据保存到主数据存储（MDS ）之中。如果企业需要的所有主数据都保存在MDS 中，那么这个地方就可以作为SOR 。如果只有一部分主数据保存在MDS 中，那么可以使用数据联邦技术来建立一个虚拟的SOR ，这个SOR 的数据来自MDS 和业务处理应用。主数据整合中心通常通过一个相关的数据模型来管理流经整合中心的数据的业务含义。
图7 主数据整合中心，主数据整合中心中存储着SOR ，ODS 和DW 中只保存事务数据，不需要保存主数据。 图
略。
3．企业主数据管理（Enterprise master data management）
企业主数据管理可以满足本文前面提到的关于MDM 系统的所有需求。除了一些经过协商的特殊情况，MDM 系统应该同时是主数据的SOE 和SOR 。当SOR 在业务处理应用中时，需要使用数据传播技术将数据从应用复制到MDS 中，这个数据在MDS 中是只读的。数据传播技术也用于将主数据复制到下游的应用中。
图8：企业主数据管理，企业MDM 中保存SOE 和SOR ，ODS 和DW 中只保存事务数据，不需要保存主数据。 图
略。
企业建立MDM 可以逐步进行，从建立主数据标识登记开始，然后发展到主数据整合中心，最终建立一个完整的企业主数据管理的解决方案。这个逐步进化的过程可以使SOE 和SOR 都逐步迁移入MDM 系统之中。
2.6. MDM 对传统IT 环境的影响
MDM 对传统IT 环境的影响
在传统的IT 环境中，主数据是分散到不同的业务处理应用中的。使用数据联邦技术可以创建主数据的一个虚拟视图。当前的主数据可以被合并到ODS 之中，或者合并入数据仓库之中，作为分析的基础。
在传统的IT 环境中增加一个主数据标识登记系统并不会影响主数据在企业内的流转方式。通过主数据的全局标识及数据联邦技术可以使位于不同业务系统中的操作型主数据互相关联。这些主数据的全局标识也可以保存在ODS 之中或者数据仓库之中，这样可以使主数据的访问变得简单一些。
建立一个主数据整合中心可以增强传统处理中的主数据传播能力，主数据整合中心会将变化的主数据在操作型业务处理应用中传播。一个主数据整合中心的建立也会对ODS 的设计产生影响。主数据存储在整合中心中，剩下的事务数据存储在ODS 之中。主数据整合中心和ODS 一起将历史数据传播到数据仓库之中。
企业主数据管理对企业内主数据流动的影响相当的大，因为企业主数据管理将当前的及历史的主数据都维护在主数据存储（MDS ）之中。这就意味着主数据不再需要维护在ODS 或者数据仓库之中。MDS 就可以用来为数据仓库信息处理提供维度数据。MDS 中存储的历史主数据可以为进行当前信息和历史信息比较的BI 应用提供数据。举例来说，MDS 中保存的历史主数据可以支持按照2005年的销售区域划分来对比分析2005年及2006年的销售情况，尽管在2006年已经将销售区域进行了重新划分。在财务报告中，这种分析能力尤其有用。
企业MDM 也可以针对数据仓库中信息提供主数据变化的模型，通过这个模型可以预测主数据变化对业务操作系统的影响。
2.7. 三类主数据技术的比较
图9 在一个较高的级别上比较了三类MDM 技术的一些不同。从表格中我们可以看出，整合中心是在标识登记的基础上扩展了对主数据整合服务的支持，可以用来建立和维护一个集中的主数据存储，并将主数据在不同的应用中进行传播。整合中心中保存的主数据成为SOR 。
企业MDM 在整合中心的基础上又添加了一些功能，如主数据建模和主数据管理。并且SOE 也移入MDM 系统。企业MDM 跟踪了主数据及其元数据的变化情况，可以用来处理相关的多个业务实体，这一点和前面的两种技术不太相同。这个附加的能力给主数据管理增加了大量的功能和业务收益，当然，这也需要更多的资源和开发周期。正因为如此，所以企业MDM 应该是一个战略性的多年的方案。
图9 三类MDM 方法的比较
2.8. 业务领域MDM 和企业MDM 的比较
很多MDM 的目标定位于特定的业务主题，如建立客户的单一视图等。尽管这样的项目比建立企业MDM 开发周期短、成本低，但是这样做有较大的风险，这样容易在企业内建立多个烟囱式的主数据管理。这和商业智能领域中数
据集市和数据仓库的关系比较类似。
在Business Intelligence Network上最近的一篇BLOG 中有如下的描述：
“„我们管理着数百个不同类别的主数据，其中的两个主要的是产品和客户。大企业中都会有相同的问题，不管这些数据是HR 数据、供应链数据、资产数据、还是商标数据。有远见的企业会采取整合的步骤来建立企业MDM ，而不是建立单独的烟囱式的MDM 。”
尽管大多数企业都意识到从长远的角度考虑，建立企业数据仓库是一个较好的方式，但是他们仍然建立独立的数据集市，因为这样的项目开发周期短，成本低，容易部署。当建立了多个数据集市之后，他们意识到他们建立的数据的烟囱，然后他们花大量的成本去合并这些数据集市。主数据管理也面临着相同的状况。解决方案是自顶向下的，但是实施是自底向上的。
长期的目标应该是建立一个合并的主数据业务模型，并建立整合的主数据及其元数据存储。在所有的战术型的主数据管理项目开发时，都应该与长期的MDM 目标保持一致。
为了能平衡主数据管理的短期目标和长期目标，最好的方法是建立一个主数据实践团队，有他们来负责企业内的战略型的主数据管理目标。
3. 三、主数据管理的需求
3.1. MDM 的需求
MDM 的需求
图10 列出了企业MDM 系统的主要功能需求。这些需求可以分为四个部分：应用设计、元数据管理、主数据管理和整合服务。
图10 MDM 需求
在设计的过程中，IT 方和业务用户方都需要一个灵活的建模工具，使用这个工具可以很容易的记录、可视化、定义和修改业务模型（包括实体、属性和关系）和MDM 应用的规则。对于主数据不是很复杂的企业来说，一个水平的或者垂直的行业模板对他们的设计过程可以提供很大的帮助。
主数据的元数据管理功能应该包含在整合的元数据知识库中，这个知识库可以记录和处理与MD M 项目相关的所有信息，包括MDM 业务模型、业务视图、业务规则和政策、与安全相关的业务角色等。主数据管理的需求包括一个公用的主数据存储和一个全局标识管理。
不同供应商的MDM 解决方案间一个最大的区别是，元数据和数据管理工具如何来管理和跟踪主数据、主数据关系、主数据层级结构等内容的变化情况，以及是否可以提供主数据的版本管理以及主数据的世系报告等功能。这些功能对于企业MDM 是非常重要的功能，对企业内数据的一致性非常重要。
第四部分列出了将MDM 应用整合入企业IT 环境中需要的一些服务。这些MDI 服务会在后面进行介绍。
3.2. 主数据整合服务
MDM 商业产品经常会提供私有的整合工具。除非这些整合工具能很容易的与企业现有的整合环境集成在一起，否则都不应该使用它们。私有的工具会产生重复的元数据，使MDM 应用转变为企业MDM 变的很麻烦。关键的需求列示如下：
1．数据质量管理
2．元数据整合及传播
3．同步及异步数据传播并确保数据的交付
4．变化数据捕获及数据转换
5．数据联邦
6．SOA
底层数据整合服务（MDI ）提供的这些功能可以支持MDM 的应用处理。这些服务可以作为企业整合架构中的核心部件。
图11：MDI 服务架构，最低层为整合管理服务，包括数据质量管理、元数据管理和系统管理；之上为整合技术层，以Web Services 和SOA 架构为基础，包括ETL 、EII 、EDR 和EAI ；再之上为整合技巧层，包括数据转换、变化数据捕获、数据联邦、数据合并、数据传播；最上层为MDM 应用。 图略。
3.3. 主数据应用：自己开发、购买还是外包？
到目前为止，很多MDM 应用都是定制开发的。最常见的例子就是在存储低延迟数据的ODS 中建立客户的单一视图。这些定制的MDM 应用可以提供和主数据标识登记或者主数据整合中心相当的功能，但是它们很少能支持全企业的主数据管理。它们主要关注于主数据的整合，而不是主数据管理。
与其他的面对自己开发还是购买的情况类似，对于主数据管理，也需要在开发维护成本与供应商的许可、维护费之间进行平衡。大多数MDM 解决方案供应商都能提供比定制开发更多的功能，尤其是企业MDM 的供应商。他们的解决方案也与业务处理系统整合的很好，尤其是当业务系统和MDM 是同一个供应商时。
MDM 成型的解决方案往往定位与特定的业务主题域（如客户、财务、产品等）或者特定的行业（如零售、银行、电信、医疗等）。对于这些业务主题域和行业，这些方案是很有优势的，它们内置的业务模型和模板可以使MDM 应用的开发快速启动起来。客户MDM 就是一个很好的例子。在其他的领域，如产品，由于比较复杂而且缺乏行业标准，使用预定义的模板和行业模型的优势就不太明显。当企业购买行业解决方案时，要小心不要建立成多个烟囱式的MDM 应用。
主数据对企业来说是至关重要的，最好不要将MDM 处理过程进行外包。如果企业将一些操作型的BTx 应用外包了，会给企业建立内部的MDM 应用带来困难。例如，如果企业的CRM 系统是外包的，当企业开始建立客户MDM 应用并建立SOR 时，就需要从外包的CRM 系统中收集数据。如果要将SOE 从CRM 系统中转移到MDM 系统中，会有很大的麻烦，如果不转移的话，就不能建立企业MDM 。
一些企业在建立他们的MDM 应用时，会使用外部信息提供者（如Acxion 、D&B等）去验证和扩展他们内部的企业主数据。
4. 四、主数据管理面临的挑战及成功的因素
4.1. MDM 面临的挑战
MDM 的目标，和其他的企业范围的应用（如CRM 、BPM 、BI 、数据专员等）一样都面临着各种挑战。这些挑战不仅仅是需要和企业内各个部门及业务应用进行合作。下面列出了在开始第一个MDM 项目前需要考虑的一些问题。
1．责任
目前大多数企业内都没有专门的业务部门来负责主数据。在企业的各个信息系统、处室、部门、甚至个人的数据库中，都散落着企业的主数据。当一个部门在自己的系统中维护了一些主数据之后，他们只对自己的主数据负责，而不管将来如何来处理这些主数据或者其他系统如何来使用这些主数据。这些数据会从一个系统传播到另一个系统，
但是很可能在源系统的数据发生变化、更新、甚至删除时并不通知下游的系统，这样企业内的数据就会出现混乱。除非从企业的角度对主数据进行负责，否则一个MDM 方案不会成功。非常遗憾的是，这在政治上是个很难解决的问题。为了解决这个问题，企业的高级主管必须要参与进来。
2．权利
企业内开始一个MDM 项目，应该在谈论他们的责任时赋予他们足够的权利。这些权利包括定义角色，分派人员等，也包括建立整个企业内的正式的流程等内容。
3．投资
启动一个MDM 方案需要得到企业的支持和许诺，不仅仅包括人员和时间，还需要对软硬件环境的技术需求进行资金支持。在购买MDM 应用时，其中会包括软件和硬件。这个投资在开始时可能比较小，但是随着时间的发展它会越来越多。所以，对于一个成功的MDM 方案，它需要全企业和高层主管的支持。
4．努力
业务处理过程和主数据都在不断的变化，所以MDM 不能仅仅作为清洗参照数据的一个项目。企业必须要理解，MDM 功能事实上是一个持续的过程，这个过程包括多个需要合作并有优先顺序的项目。一个企业可能会有多个MDM 项目同时进行，例如客户MDM 和产品MDM 等同时进行。这些项目之间必须进行合作，如共享相同的技术实现，使用相同的命名规则、格式、定义，并且要有建立企业MDM 的最终目标，向着这个目标努力。
5．投资回报率
最后，对于每一个MDM 项目，都应该计算出该项目的详细的、可度量的投资回报率。有时候，这样的度量很难得到，这些，需要给企业证明有了MDM 环境会有什么样的好处，如果没有的话会有什么样的危害。
前面提到的这些问题在开始时会使人畏缩的。因此，在启动一个MDM 方案时，应该从其中的一小部分开始。在第一个项目中不要期望能解决所有的问题，成功的建立每一个MDM 项目，每次解决一些问题，这样，问题会逐渐的都得到解决。
4.2. MDM 面临的其他问题
除了前面提到的这些问题以外，还有一些需要考虑的其他问题。例如，对于客户主数据来说，安全问题和隐私问题都是相当重要的。如果不事先建立好正确的管理政策和程序，即使主数据是整合好的、有完善文档的、容易访问的，这个MDM 项目对企业来说是好事还是坏事也很难说。
1．MDM 政策
这些政策包括这些至关重要的数据的所有者是谁，谁来维护它们，谁会使用它们，并且这些内容都要用文档记录下来。这些政策还包括如果没按政策执行的会发生什么。例如，应该建立一个政策来决定谁来负责主数据的使用方式和安全问题。一些例外的情况也要记录下来，用来减小例外发生产生的争议和损失。
2．MDM 数据处理流程
和MDM 的政策相似，这些程序包括以什么样的流程来创建这些主数据，这个过程也需要用文档记录下来。例如，当一个客户的定义发生改变时，如添加客户的属性或者删除客户的记录等问题发生时，应该以什么样的流程来进行处理？如果发现安全上出现问题时，应该采用什么的流程来进行处理？同样，对于例外情况的处理也要记录下来。 最后一个要考虑的是关于企业内数据整合中心的问题，或者称为其他的类似名称的数据中心。不管企业内如何来称呼它，这些数据中心的目的都是建立一个整合的、企业范围的、可信任的、可维护的数据环境，并将这些数据发布给企业用户，用来辅助决策。它们的目的是建立一个高质量的、整合的、保存当前数据和历史数据的知识库。这样的数据中心中的数据包括主数据及与其相关的事务数据，也就是说，这样的数据中心和MDM 项目存在着交集。 有两种方案可以用来解决这种可能存在的冲突。第一种方案是将MDM 功能从数据整合中心中分离处理，建立单独的MDM 功能。这种方案中，MDM 建立和控制主数据及其功能，并将这些主数据的相关信息共享给数据整合中心。这种方案的缺点是两个组有可能没有采用同样的技术和企业数据标准，如果这样的话会引起另外的数据整合问题。 另一种方案是将MDM 功能作为整个数据整合中心的一部分，和提供其他数据的功能一样的提供主数据。这种方案可以共享相同的技术、标准、甚至人员，使主数据与其他数据的整合更容易。
实际建设中，可以根据政策和资金的情况来决定采用什么样的方案是最优的。从一个小方案开始建立MDM ，可以先验证你的企业是否需要这种的应用，再对以后进行判断。
4.3. MDM 的文化挑战
从一个MDM 项目开始
当启动一个MDM 项目时，需要面临很多挑战。其中一小部分是文化上的挑战，它将是你面临的最大的挑战。其余的大部分都是技术上问题。在本篇文章中提到的多个供应商都很重视这些问题。
文化挑战
第一个文化上的挑战是需要为MDM 选择一个典型的业务用例。没有主数据管理会带来很多常见的问题，例如，不能在多个业务部门间联合使用数据，信息的质量差，决策周期长，收入机会丢失，利润下降等。未整合的主数据也会导致很多问题，例如，很难鉴别客户，库存管理不正确，供求链管理低效，操作和财务报表不一致，操作错误等。当然，没有高质量的主数据，数据的一致性规则、甚至合并和获取数据都会成为问题。
在这些问题中的任何一个之上都可以建立一个合理的MDM 用例。在建立这个用例时，应该关注于切实的利益，如改进业务操作，改进IT 及业务处理过程、提高收益等。这些都是有形的好处。那些无形的益处也是很有用的，如
客户满意度提高，改进与供应商的关系，提高数据质量等。
第二个文化上的挑战是获得并保持企业高层的支持。在任何一个企业范围的项目中，不同的业务部门都会对业务实体的定义有不同的理解，最终产生争论和数据的不一致。MDM 项目也会面临同样的问题。如果有一个企业高层指导委员会在支持这个MDM 项目，那么当问题出现时就比较容易解决，项目就可以向好的方向进展。
当MDM 开始实施时，企业的高层也可能会投身于业务定义的争论中。克服这些政治上的障碍可能是最困难的事情。从各个业务部门的视角考虑主数据到从全企业的视角考虑主数据，需要全企业都接受MDM 知识库中的数据作为主数据的SOR 。这就意味着企业内的用户都要完全同意MDM 对企业内关键实体的业务定义，至少要接受这些定义。建立一个整合的，有资格的数据中心可以为克服这些障碍起到重要的作用。这样的数据中心也可以对定义和管理MDM 政策及数据处理流程负责。一个全面的管理计划对成功的实施MDM 也是必要的因素。
第三个文化上的障碍是要确保有足够的资金来支持MDM 的实施直到其完成。尽管实施一个全企业范围的MDM 是一件非常有益的事情，但是这样的项目也是非常昂贵的。MDM 的实施过程需要多年的时间，以逐步增加项目的方式最终实现MDM 。在很多情况下，战术项目都需要实现短期的业务目标。但从长期来说，建立一个全企业范围的MDM 系统是必要的。企业应该在战略上制定好建立全企业MDM 的计划，即使他们采用的自低向上的方式来建立MDM 。
4.4. MDM 的技术挑战
很多与MDM 相关的技术问题在前面都讨论过了，下面是主要技术问题的一个总结。
第一个挑战是要建立一个灵活的MDM 业务及数据模型。这个模型是我们走向成功的路线图。我们永远也不能收集全企业内需要的所有的主数据。这个对主数据的需求会随着时间而发生变化，如随着业务的改变、市场方向的变化及企业文化的变化等发生变化。因为，对于主数据模型的设计者来说，必须要建立一个灵活的模型，当一些变化发生时，不能对以后的模型产生较大的影响。有些MDM 供应商可以提供可定制的行业模板及数据模型，这对我们开始MDM 项目很有帮助。
第二个挑战是关于主数据质量的管理问题。数据质量包括标识和定义所有的主数据属性，对这些属性的质量进行评估并更正存在的问题。这是一个非常重要的任务，尤其是对于企业内各个部门之间的数据出现不一致的定义及使用方式时，这时需要对数据进行一致性处理。数据质量处理有两种方案，第一种是在MDM 方案开始实施时，所有的数据源都先进行数据质量清洗；第二种方案是在MDM 方案中一个一个的清洗来自各个数据源的数据。当数据源的数据发生变化时，同样的数据质量清洗操作也需要进行。市场上有很多数据质量和数据概况分析工具可以为我们提供帮助。对于一些特殊类型的主数据实体，也有特殊的工具可以帮助我们进行数据处理，如地址模式匹配，对产品进行语义分析等。
第三个挑战是由于主数据发生变化而引起的。就像主数据模型需要保持灵活性来接受新的主数据属性一样，MDM 应用也必须具有处理复杂变化的能力，这种变化不光包括数据内容的变化，还包括数据的层级结构、数据之间的关联关系以及在数据之间建立新业务规则等内容的变化。变化是不可避免的，因此，当我们选择一个MDM 技术时，要确定当发生变化时，这个技术的处理不应该很复杂。
第四个挑战是如何将SOE 从操作型系统中迁移到MDM 系统中，这需要同时面对文化和技术上的挑战。技术上的挑战是要保证将SOE 从操作型系统迁移到MDM 的过程要顺畅，不要出现各种问题。当越来越多的SOE 迁移到MDM 环境时，相应的操作型系统中的录入功能要禁止掉，否则会出现重复录入的问题。如果一个SOR 不能迁移到MDM 系统中，要保证有一个简单的方式将外部的主数据迁移入MDM 系统中，来保证SOR 是最新的。
MDM 面临的第五个挑战是对标识的管理，尤其是对客户主数据来说。因为客户可能是全球范围的，客户之间有着复杂的关联关系，而且这些关联关系还在不断的变化中。MDM 环境必须能够建立对这些客户建立唯一的标识来适应这种复杂的情况。在很多情况下，这也是文化上的问题。企业必须能够同意建立这些全球内唯一的标识来鉴别不同的客户，这样才能确保MDM 维护主数据的更新和变化的功能。
MDM 面临的最后一个挑战是关于MDM 整个基础结构的挑战。不论MDM 这个概念是新的还是旧的，都需要一套技术体系来支撑它。有很多公司都建立了部分的或者不完善的MDM 解决方案。这些对供应商来说也许是好事。这些供应商一般会关注于MDM 环境中的某个特定技术，对此进行研究和开发，例如进行数据质量管理等。所以，这些供应商一般都是对MDM 的某个一个特定部分可以提供完善的解决方案。而企业必须要保证这些不同供应商提供的技术可以整合成一套完善的MDM 基础机构。而且，由于在MDM 环境中包含了大量的、复杂的、分散的数据环境和系统，这就使得MDM 解决方案能提供通用的主数据整合基础结构变得至关重要。这个MDM 基础结构必须要和企业的数据整合策略及方案保持一致。
有些供应商会提供包含MDM 环境各个部分的完善的解决方案。在很多案例中，这些供应商都合并或者收购了提供专门技术的公司，来组成完整的解决方案。这些完整的解决方案不一定在每一个环节都是最好的，他们的优势在于可以减少由于供应商的不同而产生的数据接口和数据交互。企业需要自己来决定什么样的解决方案是适合自己的。
4.5. MDM 的成功因素
正像前面提到的一样，企业MDM 是一个多年的项目，需要企业高层的支持，需要一个长远的战略计划。企业内会不断新增各种业内的项目，MDM 的成功需要与这些项目进行配合而逐步建立。
有时，MDM 项目会延伸到企业数据整合和数据仓库项目之中，或者成为其中的一部分。每一个做整合工作的项目组都应该认真考虑其工作对企业主数据的影响，也要考虑到企业MDM 解决方案的总目标。
贯穿MDM 的整个开发周期，重点应该放到下面三个方面，建立一个合并的主数据业务和数据模型，数据质量管理，建立一套全面的管理政策和程序。MDM 应用必须和企业整合框架紧密的结合在一起。SOA 架构的使用将成为这个整合框架中关键的一部分。建立一个数据整合管理中心可以有效的支持MDM 应用开发和部署的方方面面。
5. 五、总结
正确的实施，主数据管理可以提供非常大的业务收益，如提高生产力，减小风险，增加收益。很多公司建立MDM 方案时，只部署一个主数据整合（MDI ）应用，目标定位于一个特定的业务问题，如建立一个客户的单一视图，或者管理产品的单一视图或者其他的企业实体。但是需要注意的是，尽管这些MDI 可以提供一个企业内单一的业务视图，它并不能解决大部分企业内存在的主数据问题，它只能掩盖问题。
一个企业MDM 的解决方案中，需要业务用户参与MDM 的处理过程，在MDI 的基础上需要添加管理、跟踪和审计不断变化的主数据及其元数据的功能。企业MDM 是一个单独的IT 部件，它维护着企业内主数据的SOE 和SOR 。它为企业内的业务处理系统和商务智能系统提供主数据。它也可以用来推进数据仓库环境的建立，作为商业智能应用处理的基础。
企业MDM 是一个多年的战略目标，可以从建立主数据登记、主数据整合中心的项目开始进行，最终的目标是建立企业MDM 。
最后，我们引用一个供应商的主管的一段话来作为MDM 的总结，这句话总结了MDM 的现状。“每个人都希望得到一个完善的主数据解决方案，但是从目前市场上的技术及能力来看，达到满意的要求还需要几年的时间。目前企业内讨论的焦点还在应该建立一个MDM 还是建立多个MDM 之上。而在我们评估或者建立正确的MDM 解决方案之前，我们要考虑的还是一些基本的因素，如数据的类型（操作型还是分析型）、数据的延迟时间、聚集的程度、数据的容量、用户视角（业务用户和IT 用户）的不同等。”
5.1. 附录A ：定义
附录A ：定义
Master data: This is reference data about the core business entities of an organization, such as people (customers, employees and suppliers), things (products, finances/ledgers and assets) and places (locations). Many people think of these as major data subject areas (in enterprise data modeling terms) or as dimensions (in multidimensional analytics terms).
主数据（master data）：企业内核心业务实体的参照数据，如人员（客户、雇员和供应商等），事物（产品、财务/分类帐和资产等），场所（位置等）等内容。从企业建模者（3NF 建模者）的术语来说，主数据就是主题域中的主要数据，从维度建模者的术语来说，主数据就是维度数据。
Master data business model: This is a model that documents (in an easy-to-understand format) master data entities, attributes, and relationships and corresponding technical metadata. This model is stored in the master metadata store (MMS).
主数据业务模型（master data business model ）：以一种容易理解的方式记录的关于主数据的实体、属性、关联关系及相应的技术元数据的模型。这个模型存储在主数据的元数据存储中（MMS ，master metadata store）。
Master data identity registry, master data integration hub and enterprise MDM: These are the three main approaches to master data management.
主数据标识登记（master data identity registry ）、主数据整合中心（master data integration hub ）和企业主数据管理（enterprise MDM）：这些是主数据管理的三个主要步骤。
Master data integration (MDI) services: These are the various underlying data services and associated technologies used by MDM applications to integrate master data.
主数据整合服务（master data integration services）：这些是与MDM 应用技术相关联的一些底层服务，用来整合主数据。
Master data management (MDM): A set of disciplines, applications and technologies for harmonizing and managing the system of record and system of entry for the data and metadata associated with the key business entities of an organization. 主数据管理（MDM ，master data management）：主数据管理是一系列的规则、应用和技术，目的是为了协调和管理与企业的核心业务实体相关的系统记录和系统登录中的数据和元数据。
Master metadata store (MMS): A single repository containing metadata and business rules associated with master data. 主数据的元数据存储（MMS ，master metadata store）：一个知识库，保存着与主数据相关的元数据和业务规则。 MDM applications: These employ master data integration (MDI) services to create and maintain master data.
主数据管理应用（MDM applications）：使用主数据整合服务来建立和维护主数据的应用。
System of entry: The application system responsible for creating and maintaining master data and its associated metadata. 系统登录（SOE ，system of entry）：创建和维护主数据及其元数据的应用系统。
System of record: The application system responsible for publishing the master copy of any given piece of master data and its metadata.
系统记录（SOR ，system of record）：负责发布主数据及其元数据的应用系统。
5.2. 附录B ：MDM 调查
附录B ：MDM 调查
作为这个MDM 研究项目的一部分，作者关于MDM 在公司的使用情况做了一个简短的调查，调查的地点是Business Intelligence Network 。在接受调查的60个公司中，有30个准备启动MDM 项目，7个已经实施并有了结果，23个还没有关于MDM 的计划。启动MDM 项目的37个公司中，有26个关注于产品数据，23个关注于客户数据，9个关注于财务数据。很有意思的事情是关注于产品主数据的公司比关注于客户主数据的还要多，这很出乎以外。期望中，客户主数据的整合需求更高一些。
我们报告中的一个焦点是关于主数据整合和主数据管理的区别。很多MDM 项目关注于整合，例如，他们努力去解决主数据现存的不一致问题，而不是去解决产生不一致的根源。管理主数据，从另一个角度讲，不仅要关注于建立一个单一的系统记录（system of record），而且也要关注于系统登录（system of entry），因为主数据的问题产生于系统登录。真正的企业主数据管理也应该处理过去，现在和未来的主数据的层级结构。这样的系统对数据仓库的设计是非常有价值的。
在调查中，我们提供了关于MDM 的两个定义。一个关注于主数据整合和技术，而另一个关注于真正的企业主数据管理和主数据管理规则。19个接受调查的公司选择了前者，倾向于技术定义；而39个选择了后者，倾向于企业MDM 的定义。
1. 为什么需要主数据管理
1.1. MDM 的定义
"The whole is more than the sum of the parts." --Aristotle
整体比部分相加之和的内容要多。――亚里斯多德
这句亚里斯多德的哲学名言，很适合来描述主数据管理（MDM ，master data management）。MDM 主要关注于研究、分类和访问企业内的重要数据。也就是说，MDM 帮助你理解企业内的每一份数据，包括客户、产品、场所和其他的主要的主题域等内容。在这篇研究文章中，清晰的给出了MDM 的定义，详细说明了建立MDM 将会产生的收益和结果，也说明了建立MDM 需要的各种技术，以及实现MDM 的实践步骤。
为了更深入的解释MDM ，说明它的好处和用法，本篇文章中列举了很多实际的案例。其中每一个案例都是从实际的业务出发，通过对业务和技术问题的分析，总结了一套实现MDM 的方法和技巧。通过这套方法，可以避免实现中的一些缺陷，增加实现的成功率。
为什么需要主数据管理？
主数据管理：定义
我们从定义MDM 是什么开始，关于这个问题有两种观点，分别对应于MDM 这个词组的重音位置的不同。
1．主数据管理－或者称为管理主数据。这包括建立和维护主数据的一些管理性的应用。例如，客户数据整合（CDI ，customer data integration），产品信息管理（PIM ，product information management），以及用来管理类似数据主题的其他应用。
2．主数据管理－或者称为数据管理之后的一系列管理过程。这包括整合企业数据（包括主数据）所需要的基础结构和技术。例如ETL （extraction, transformation, and load）和EII （enterprise information integration）等技术。 从本篇研究文章的目的出发，我们采用第一种观点，即认为MDM 的功能是管理各种类型的主数据。当然，第二种观点中涉及的基础结构和技术对支持MDM 处理过程和应用也都是必要的。
我们对MDM 的官方定义为：
A set of disciplines, applications, and technologies for harmonizing and managing the system of record and system of entry for the data and metadata associated with the key business entities of an organization.
主数据管理是一系列的规则、应用和技术，目的是为了协调和管理与企业的核心业务实体相关的系统记录和系统登录中的数据和元数据。
在这篇文章中提及了一些专有名词，这些名词对理解本文很重要。这些名词的定义在文章末尾的附录A 中。在继续阅读这篇文章前，请先熟悉这些名词。
1.2. MDM 的内容
MDM 的内容
简单的说，主数据是企业内关于核心业务实体的参照数据。这些业务实体包括：
1．人员－例如，客户，雇员（人力资本），供应商，合伙人等。
2．事物－包括产品，财务（分类帐），资产等。
3．场所－企业感兴趣的位置和地点。
4．其他关键实体－企业感兴趣的其他数据。每个企业都会有自己特有的关键实体。
图1：主数据包括很多业务实体，如客户主数据、产品主数据、财务主数据及其他主数据等。 图略。
MDM 应用包括一系列的处理过程，这些处理过程包括整合、存储、维护企业内业务实体的特定实例，如将企业内地理位置数据、产品数据和客户数据等做标准化处理。完整的维护后，主数据就成为了这些实体的系统记录（SOR ，
system of record），也就是说，对于每一个实体，MDM 中提供的数据就是该数据的完美的最终版本。这些数据也是企业内参照数据的最终版本。
讨论一下哪些数据不包括在我们对MDM 的定义内，也同样是非常重要的事情。MDM 应用不会保存那些和业务实体相关的特定业务处理数据（BTx ，business transaction），例如与客户实体相关的帐户余额信息、取款信息。这些业务处理系统产生的数据会被整合到操作数据存储（ODS ，operational data store）中。而BTx 的历史数据会保存在商业智能（BI ，business intelligence）部件中，如数据仓库和数据集市。
没有一个强制的规则，认为所有的主数据必须保存在MDM 系统中。有些主数据的维护必须保留在业务处理应用（BTx ）中，或者保留在外购应用，如前端的CRM 中。这使企业的IT 环境变得复杂，也给主数据的质量和准确性带来了挑战。这个主题我们会在本文的后面章节进行详细的讨论。
1.3. MDM 的业务目的
通过对没有MDM 的IT 环境进行分析，我们可以很容易的理解MDM 的业务目的。分析结果可以总结为下面的四个主要问题：
1．数据冗余
没有MDM 功能，企业内的每一个系统、应用、甚至业务部门都会收集自己版本的核心业务实体数据。最好的例子就是对客户数据的收集。客户的关键属性如客户名称和地址信息在企业内各个角落都被重复的记录着。非常遗憾的是，在这个收集客户信息的过程中，很少会产生相同或者一致的结果。这导致了一个很严重的问题（除了存储成本之外），数据冗余导致数据质量过差。
根据The Data Warehousing Institute的一份报告（Data Quality and the Bottom Line, by Wayne Eckerson）显示，由于数据质量过差，企业每年的总共损失超过$600 billion，而且其中的大部分成本是因为冗余、低质量的主数据引起的。这也引起了下面提到的第二个主要问题。
2．数据不一致
由于企业内主数据的不一致，导致企业大量的资源浪费，包括时间、金钱和人力资源等的浪费。判断企业内一个客户的真正地址或姓名是到底什么并不能增加企业的收入。而且非常不幸的是，因为没有一个存储机制用来保存比对过的客户数据，这种对客户数据进行一致处理的过程需要重复出现。
3．业务低效
凌乱的主数据会导致各种业务低效的情况发生，如低生产力，低效的供应链管理，不一致的客户待遇，客户不满意，浪费市场部门的努力等。一个客户服务代表需要综合几个操作型系统去判断一个客户的真正状态，这不仅是低效的，而且有可能会由于信息的不全使客户产生不满意而逐渐失去这个客户。企业内的各种工作都显示出，凌乱的主数据管理严重降低了企业的效率。
4．业务变化
企业内经常发生各种变化，如引入新的产品和服务，公司合并与吞并，新技术出现并成熟。这些企业内的各种变化都会导致企业主数据的变化，如果没有一套机制来管理这些变化，企业在数据冗余、数据不一致和业务低效等方面的问题就会不断加剧。
1.4. MDM 的案例
没有MDM ，企业缺乏关于他们客户、产品及其他核心业务实体的完整的视图，而这个完整的视图可以提供给企业预测和控制未来的能力。下面提供的四个关于MDM 的案例中，每一个都有非常权威的业务目的。所有的这些都为了解决两个主要目标：增强企业的生产力和增强企业的收益率。
Honeywell
Honeywell 公司部署了一个关于客户管理的MDM 方案，通过这个MDM 方案，可以为客户提供更好的服务，为企业提供新的机会。在这个方案中，能以各种单位来交互式的访问和分析采购数据及销售数据，这将会提高客户满意度、增加销售收入。这个方案不仅有企业高层的支持，也受到了销售组的强烈支持，他们认为通过使用这个系统可以更好的管理客户关系，可以得到更好的收益。
Mentor Graphics
为了提高生产力，Mentor Graphics建立了一个集中的MDM 系统，这个系统整合并管理了销售、产品和组织的主数据，并按固定的时间间隔将其发布到业务处理系统和商务智能系统之中。业务用户可以通过这个系统控制主数据的变化，并将变化发布到企业内所有的系统，这也使他们对业务处理更加深了一步。这个系统为计划改编和重组提供了更好的工具和信息，提高了决策支持的能力。通过使用一个单独的系统来验证及核实主数据，数据的质量也得到了提高。
A Nonprofit Member Organization
对于非盈利性组织来说，他们面临的挑战是管理从外部数据源收集的所有数据，他们需要对这些数据进行精加工，确保这些数据的可靠性、一致性、可访问性和及时性。他们通过对业务规则的全面理解，建立了一个存储高质量的会员数据的知识库系统。这个系统帮助他们解决数据不一致的情况，验证了会员的名称和地址，并降低了市场的开销，减小了邮件成本，增强了服务的效率。这个方案免去了很多为了使数据可用而做的手工处理，尽管投资是在一个非盈利性的项目，但是企业的预算减少了。现在，业务人员可以花费更多的时间在分析数据上，而不必在格式化数据及清洗数据上花费时间。
Match Supermarkets
Match Supermarkets 需要以一种通用的格式组织企业内的数据，这样其他系统如操作型应用系统，EDI 系统和数据仓库系统都可以很容易的访问这些数据。他们建立了一个实时的、事件驱动的MDM 整合中心，在这个整合中心中保存了企业主数据的通用格式。这个整合中心将其中的通用格式的主数据发布到企业的每一个地方，增强了他们的操作型接口及EDI 处理的效率。
更详细的说明
下面列出的四个公司对MDM 应用的实现方式提供了更详细的说明，下面也列出了他们MDM 产品的一些情况。 IBM:
1．Master Data Management Solution Overview
2．Honeywell Case Study
Hyperion:
1．Master Data Management Solution Overview
2．MentorGraphics Case Study
DataFlux:
1．Master Data Management Solution Overview
2．Nonprofit Organization Case Study
Sunopsis:
1．Master Data Management Solution overview
2．Supermarch és Match Case Study
1.5. 关于MDM 的误解
由于MDM 是一个相对较新的领域，业内对于MDM 是什么、在企业内应该如何来实现等问题有一些不同的观点。下面列出了我们在研究中遇到的一些关于MDM 的误解：
1．MDM 是一个数据仓库或商业智能项目。
这是不正确的，MDM 既不是BI/DW项目，也不是操作型项目。MDM 是另一类实现方式，它的建立对前面的两种环境都很有利。MDM 可以使用操作型环境作为自己的数据源，但是一旦数据被清洗、整合、加载入MDM 知识库后，这些数据就成为数据仓库、ODS 、数据集市等的数据源或者SOR 。
2．MDM 仅仅为了维护企业内业务处理应用中数据的一致性。
这也是不正确的。当然主数据可以维护这些系统中数据的一致性，但是它的作用不仅仅如此。作为SOR ，主数据知识库可以作为各种系统、应用和环境的标准数据源。
3．MDM 只是另一个数据整合项目。
这是不正确的，MDM 项目除了数据整合之外，还需要业务用户的参与并制定MDM 的原则和政策等内容。MDM 功能是全企业的事情，企业内的每一个应用都会和主数据的设计、配置和使用有关。数据专员和数据管理员都需要进入MDM 项目之中，来解决全企业的主数据统一视图的问题。
4．MDM 整合并管理了所有的企业数据。
这是不正确的。MDM 仅为核心业务实体提供SOR 。其他的事务数据必须被维护到其他地方，如操作型系统、ODS 或者具有混合负载的数据仓库环境中。
2. 二、主数据管理的概念及技术
2.1. 在传统IT 环境中的关于主数据的问题
在今天的大多数企业里，没有一个单一的MDM 环境来管理主数据，主数据被分散在多个业务处理系统（BTx ）中，这些业务系统关于主数据都有自己的业务模型、规则和定义。不同业务系统中的数据、业务模型、规则等经常出现重叠和冲突的情况，这使得在企业内获得一致、准确的操作型主数据变得非常困难。
图2：传统IT 环境中的主数据处理，SOE 和SOR 都在业务处理系统之中，主数据和事务数据保存在ODS 或者数据仓库之中，业务处理系统中的数据通过数据整合服务来提供给ODS 和数据仓库。 图略。
为了在商业智能环境中解决主数据的一致性问题，很多企业整合并维护了主数据的历史记录，并将它们和事务数据一起保存在数据仓库之中。有很多建立数据仓库方法，但是通常来说，对当前的主数据和事务数据进行整合、合并及传播等处理，并将结果保存在存储低延迟数据的ODS 之中，而历史的细节数据和汇总数据则保存在企业的数据仓库或者数据集市之中。
如果因为成本或者安全等原因，不能将操作型事务数据整合入数据仓库之中的话，可以使用数据联邦技术来提供分散在不同的业务处理系统中的事务数据的单一视图。当应用程序通过这个虚拟的数据视图来查询时，数据联邦软件可以在运行时动态的收集和整合操作型事务系统中的数据。数据联邦技术可以解决一部分数据质量和数据一致性的问题，但是它不适合解决较复杂的数据问题。
2.2. 建立一个整合的MDM 环境
有很多不同的方法来整合及管理主数据。在详细讨论这些方法之前，让我们首先确定一下关于MDM 系统的理想的架构是什么样的。就像我们后面将要看到的，这个架构的目标需要通过迭代和逐步进化的应用处理来得到。
在一个企业MDM 系统中，所有的主数据都是通过MDM 应用程序来进行管理的，也是通过这些应用程序发布给业务用户和其他IT 系统。这些应用程序管理主数据及其元数据的变化情况，并维护这些变化的历史记录。举例来说，一个MDM 应用可以管理并跟踪客户帐户数据，如帐户标识、客户名称、客户地址、信用等级等数据。
图3：MDM 系统的数据流，主数据的变化由MDM 应用来维护，MDM 应用将维护好的主数据发布给业务处理系统
和商业智能系统，事务数据直接从业务处理系统进入商务智能系统。 图略。
MDM 系统根据需要将主数据传播给内部及外部的其他IT 系统。它也会提供关于主数据的业务视图，通过这个视图业务用户和应用程序可以直接访问MDM 系统。MDM 应用不会维护其他类型的业务处理数据，如客户帐户的余额及取款数据等。这些数据由业务处理应用来维护。
图4展示了企业MDM 系统中的主要部件。它们包括：
1．MDM 应用，管理和发布主数据及其元数据。
2．主数据存储（MDS ），保存合并后的主数据。
3．主数据的元数据存储（MMS ），保存主数据业务模型、主数据规则和定义。主数据业务模型记录了主数据实体、属性、关系和其他业务含义。
4．一系列的主数据整合（MDI ）服务，用来合并、联邦及传播主数据。
图4略。
业务用户使用定制的或者打包的MDM 应用去访问和维护存储在MDS 中的主数据。这个MDS 中存储了企业范围的主数据的SOR 。关于SOR 的信息，记录在MMS 中。MMS 中的业务规则可以确保主数据与企业实际的业务惯例相一致。
在一个完全一致的MDM 环境中，所有的主数据及其元数据都在MDM 系统中进行管理。当然，也不必将所有的主数据维护操作都从业务处理系统中移植到MDM 系统中。但是需要注意的一点是，即使有些主数据的维护是在MDM 系统之外，也要确保这些主数据的SOR 在MDM 系统之中。为了解释这一点，我们有必要更详细的解释一下主数据的SOR 和SOE 的区别。
2.3. SOR 和SOE
SOR 和SOE
系统记录（SOR ，System of Record）是一个应用系统，它的目的是发布主数据及其相关的元数据，并保证它们的正确性。系统登录（SOE ，System of Entry ）是一个应用系统，它的目的是建立和维护主数据及其相关的元数据。在一个完全一致的MDM 系统中，SOR 和SOE 是同一个系统。如果不是完全一致的MDM 系统，需要由IT 方与用户共同协商，并将协商结果进行记录。
如果SOE 不在MDM 系统中，当外部的SOE 中的主数据及其元数据发生变化时，必须通知MDM 系统，然后，MDM 系统将这部分的变化进行发布，使企业内的其他IT 应用得到变化的信息。
外部SOE 可以通过数据传播方式将主数据的变化发给MDM 系统。也可以使用联邦技术使MDM 系统可以直接读取SOE 中主数据。主数据整合服务为实现这些功能提供了数据传播和数据联邦的技术实现。
图5：SOE 有可能不是MDM 系统的一部分，当SOE 不是MDM 系统的一部分时，有两个方式可以将主数据的变化
传播到MDM 系统，第一种是SOE 通过数据传播技术发布主数据的变化，第二种是建立主数据的联邦视图，MDM 系统自己去读取主数据。图略。
当SOE 和SOR 不是同一个系统时，维护数据质量是一个最大的问题。在理想情况下，SOE 可以使用和MDM 系统相同的主数据的元数据服务及数据质量。当业务处理应用是定制程序或者打包程序时，SOE 很难使用MDM 系统提供的数据及服务。但是很重要的一点是，只要有可能，就应该使MDM 和SOE 使用相同的主数据管理程序和业务模型，这可以最大化主数据的准确性。一个整合资格中心可以扮演这个重要的角色，来管理这些程序、模型和规则。
2.4. MDM 在IT 基础结构中的角色
MDM 系统、应用及服务经常作为已存在的业务处理系统和商业智能系统在战术上的扩展。但是，为了企业的发展，一个从战略层面上考虑的MDM 方案应该被单独的提出来，这个方案应该是全企业范围的，应该有企业的高层支持。这个MDM 系统应该作为主数据的有效资源，给其他IT 系统提供主数据。它不应该只在已有的IT 应用上进行调整，也不应该为了解决一些问题而建立成分散的主数据管理应用。
MDM 不应该是一个自底向上的战术项目，企业必须要有一套战略的MDM 计划。企业应该建立一个全企业范围的主数据管理，真正去解决主数据问题，而不应该为了减小企业主数据问题而在原有系统上修修改改。
2.5. 整合及管理主数据的技术
前面我们回顾了主数据管理的概念，接着我们开始讨论实现主数据管理系统的不同技术。
有三个主要的技术用来整合及管理主数据：主数据标识登记、主数据整合中心及企业主数据管理。有些企业综合使用这些技术来建立混合解决方案。
1．主数据标识登记（Master data identity registry）
主数据标识登记技术通过一个标识管理程序来创建和维护一个关于主数据的知识库，这个知识库中保存各个业务处
理应用中的主数据。这个知识库中保存主数据的全局标识，通过这个标识将不同的业务处理应用中的主数据互相连接在一起。这个全局标识和数据联邦软件结合在一起可以建立一个虚拟的主数据SOR 。
图6 主数据标识登记，主数据标识登记可以建立虚拟的SOR ，ODS 和DW 中需要保存主数据及事务数据。 图略。
2．主数据整合中心（Master data integration hub）
主数据整合中心的实现方式是将主数据的变化传播到不同的业务处理应用中。尽管这个传播处理一般来说是异步方式实现的，数据的交付还是可以得到保证的。有些整合中心提供主数据合并的功能，并将合并后的主数据保存到主数据存储（MDS ）之中。如果企业需要的所有主数据都保存在MDS 中，那么这个地方就可以作为SOR 。如果只有一部分主数据保存在MDS 中，那么可以使用数据联邦技术来建立一个虚拟的SOR ，这个SOR 的数据来自MDS 和业务处理应用。主数据整合中心通常通过一个相关的数据模型来管理流经整合中心的数据的业务含义。
图7 主数据整合中心，主数据整合中心中存储着SOR ，ODS 和DW 中只保存事务数据，不需要保存主数据。 图
略。
3．企业主数据管理（Enterprise master data management）
企业主数据管理可以满足本文前面提到的关于MDM 系统的所有需求。除了一些经过协商的特殊情况，MDM 系统应该同时是主数据的SOE 和SOR 。当SOR 在业务处理应用中时，需要使用数据传播技术将数据从应用复制到MDS 中，这个数据在MDS 中是只读的。数据传播技术也用于将主数据复制到下游的应用中。
图8：企业主数据管理，企业MDM 中保存SOE 和SOR ，ODS 和DW 中只保存事务数据，不需要保存主数据。 图
略。
企业建立MDM 可以逐步进行，从建立主数据标识登记开始，然后发展到主数据整合中心，最终建立一个完整的企业主数据管理的解决方案。这个逐步进化的过程可以使SOE 和SOR 都逐步迁移入MDM 系统之中。
2.6. MDM 对传统IT 环境的影响
MDM 对传统IT 环境的影响
在传统的IT 环境中，主数据是分散到不同的业务处理应用中的。使用数据联邦技术可以创建主数据的一个虚拟视图。当前的主数据可以被合并到ODS 之中，或者合并入数据仓库之中，作为分析的基础。
在传统的IT 环境中增加一个主数据标识登记系统并不会影响主数据在企业内的流转方式。通过主数据的全局标识及数据联邦技术可以使位于不同业务系统中的操作型主数据互相关联。这些主数据的全局标识也可以保存在ODS 之中或者数据仓库之中，这样可以使主数据的访问变得简单一些。
建立一个主数据整合中心可以增强传统处理中的主数据传播能力，主数据整合中心会将变化的主数据在操作型业务处理应用中传播。一个主数据整合中心的建立也会对ODS 的设计产生影响。主数据存储在整合中心中，剩下的事务数据存储在ODS 之中。主数据整合中心和ODS 一起将历史数据传播到数据仓库之中。
企业主数据管理对企业内主数据流动的影响相当的大，因为企业主数据管理将当前的及历史的主数据都维护在主数据存储（MDS ）之中。这就意味着主数据不再需要维护在ODS 或者数据仓库之中。MDS 就可以用来为数据仓库信息处理提供维度数据。MDS 中存储的历史主数据可以为进行当前信息和历史信息比较的BI 应用提供数据。举例来说，MDS 中保存的历史主数据可以支持按照2005年的销售区域划分来对比分析2005年及2006年的销售情况，尽管在2006年已经将销售区域进行了重新划分。在财务报告中，这种分析能力尤其有用。
企业MDM 也可以针对数据仓库中信息提供主数据变化的模型，通过这个模型可以预测主数据变化对业务操作系统的影响。
2.7. 三类主数据技术的比较
图9 在一个较高的级别上比较了三类MDM 技术的一些不同。从表格中我们可以看出，整合中心是在标识登记的基础上扩展了对主数据整合服务的支持，可以用来建立和维护一个集中的主数据存储，并将主数据在不同的应用中进行传播。整合中心中保存的主数据成为SOR 。
企业MDM 在整合中心的基础上又添加了一些功能，如主数据建模和主数据管理。并且SOE 也移入MDM 系统。企业MDM 跟踪了主数据及其元数据的变化情况，可以用来处理相关的多个业务实体，这一点和前面的两种技术不太相同。这个附加的能力给主数据管理增加了大量的功能和业务收益，当然，这也需要更多的资源和开发周期。正因为如此，所以企业MDM 应该是一个战略性的多年的方案。
图9 三类MDM 方法的比较
2.8. 业务领域MDM 和企业MDM 的比较
很多MDM 的目标定位于特定的业务主题，如建立客户的单一视图等。尽管这样的项目比建立企业MDM 开发周期短、成本低，但是这样做有较大的风险，这样容易在企业内建立多个烟囱式的主数据管理。这和商业智能领域中数
据集市和数据仓库的关系比较类似。
在Business Intelligence Network上最近的一篇BLOG 中有如下的描述：
“„我们管理着数百个不同类别的主数据，其中的两个主要的是产品和客户。大企业中都会有相同的问题，不管这些数据是HR 数据、供应链数据、资产数据、还是商标数据。有远见的企业会采取整合的步骤来建立企业MDM ，而不是建立单独的烟囱式的MDM 。”
尽管大多数企业都意识到从长远的角度考虑，建立企业数据仓库是一个较好的方式，但是他们仍然建立独立的数据集市，因为这样的项目开发周期短，成本低，容易部署。当建立了多个数据集市之后，他们意识到他们建立的数据的烟囱，然后他们花大量的成本去合并这些数据集市。主数据管理也面临着相同的状况。解决方案是自顶向下的，但是实施是自底向上的。
长期的目标应该是建立一个合并的主数据业务模型，并建立整合的主数据及其元数据存储。在所有的战术型的主数据管理项目开发时，都应该与长期的MDM 目标保持一致。
为了能平衡主数据管理的短期目标和长期目标，最好的方法是建立一个主数据实践团队，有他们来负责企业内的战略型的主数据管理目标。
3. 三、主数据管理的需求
3.1. MDM 的需求
MDM 的需求
图10 列出了企业MDM 系统的主要功能需求。这些需求可以分为四个部分：应用设计、元数据管理、主数据管理和整合服务。
图10 MDM 需求
在设计的过程中，IT 方和业务用户方都需要一个灵活的建模工具，使用这个工具可以很容易的记录、可视化、定义和修改业务模型（包括实体、属性和关系）和MDM 应用的规则。对于主数据不是很复杂的企业来说，一个水平的或者垂直的行业模板对他们的设计过程可以提供很大的帮助。
主数据的元数据管理功能应该包含在整合的元数据知识库中，这个知识库可以记录和处理与MD M 项目相关的所有信息，包括MDM 业务模型、业务视图、业务规则和政策、与安全相关的业务角色等。主数据管理的需求包括一个公用的主数据存储和一个全局标识管理。
不同供应商的MDM 解决方案间一个最大的区别是，元数据和数据管理工具如何来管理和跟踪主数据、主数据关系、主数据层级结构等内容的变化情况，以及是否可以提供主数据的版本管理以及主数据的世系报告等功能。这些功能对于企业MDM 是非常重要的功能，对企业内数据的一致性非常重要。
第四部分列出了将MDM 应用整合入企业IT 环境中需要的一些服务。这些MDI 服务会在后面进行介绍。
3.2. 主数据整合服务
MDM 商业产品经常会提供私有的整合工具。除非这些整合工具能很容易的与企业现有的整合环境集成在一起，否则都不应该使用它们。私有的工具会产生重复的元数据，使MDM 应用转变为企业MDM 变的很麻烦。关键的需求列示如下：
1．数据质量管理
2．元数据整合及传播
3．同步及异步数据传播并确保数据的交付
4．变化数据捕获及数据转换
5．数据联邦
6．SOA
底层数据整合服务（MDI ）提供的这些功能可以支持MDM 的应用处理。这些服务可以作为企业整合架构中的核心部件。
图11：MDI 服务架构，最低层为整合管理服务，包括数据质量管理、元数据管理和系统管理；之上为整合技术层，以Web Services 和SOA 架构为基础，包括ETL 、EII 、EDR 和EAI ；再之上为整合技巧层，包括数据转换、变化数据捕获、数据联邦、数据合并、数据传播；最上层为MDM 应用。 图略。
3.3. 主数据应用：自己开发、购买还是外包？
到目前为止，很多MDM 应用都是定制开发的。最常见的例子就是在存储低延迟数据的ODS 中建立客户的单一视图。这些定制的MDM 应用可以提供和主数据标识登记或者主数据整合中心相当的功能，但是它们很少能支持全企业的主数据管理。它们主要关注于主数据的整合，而不是主数据管理。
与其他的面对自己开发还是购买的情况类似，对于主数据管理，也需要在开发维护成本与供应商的许可、维护费之间进行平衡。大多数MDM 解决方案供应商都能提供比定制开发更多的功能，尤其是企业MDM 的供应商。他们的解决方案也与业务处理系统整合的很好，尤其是当业务系统和MDM 是同一个供应商时。
MDM 成型的解决方案往往定位与特定的业务主题域（如客户、财务、产品等）或者特定的行业（如零售、银行、电信、医疗等）。对于这些业务主题域和行业，这些方案是很有优势的，它们内置的业务模型和模板可以使MDM 应用的开发快速启动起来。客户MDM 就是一个很好的例子。在其他的领域，如产品，由于比较复杂而且缺乏行业标准，使用预定义的模板和行业模型的优势就不太明显。当企业购买行业解决方案时，要小心不要建立成多个烟囱式的MDM 应用。
主数据对企业来说是至关重要的，最好不要将MDM 处理过程进行外包。如果企业将一些操作型的BTx 应用外包了，会给企业建立内部的MDM 应用带来困难。例如，如果企业的CRM 系统是外包的，当企业开始建立客户MDM 应用并建立SOR 时，就需要从外包的CRM 系统中收集数据。如果要将SOE 从CRM 系统中转移到MDM 系统中，会有很大的麻烦，如果不转移的话，就不能建立企业MDM 。
一些企业在建立他们的MDM 应用时，会使用外部信息提供者（如Acxion 、D&B等）去验证和扩展他们内部的企业主数据。
4. 四、主数据管理面临的挑战及成功的因素
4.1. MDM 面临的挑战
MDM 的目标，和其他的企业范围的应用（如CRM 、BPM 、BI 、数据专员等）一样都面临着各种挑战。这些挑战不仅仅是需要和企业内各个部门及业务应用进行合作。下面列出了在开始第一个MDM 项目前需要考虑的一些问题。
1．责任
目前大多数企业内都没有专门的业务部门来负责主数据。在企业的各个信息系统、处室、部门、甚至个人的数据库中，都散落着企业的主数据。当一个部门在自己的系统中维护了一些主数据之后，他们只对自己的主数据负责，而不管将来如何来处理这些主数据或者其他系统如何来使用这些主数据。这些数据会从一个系统传播到另一个系统，
但是很可能在源系统的数据发生变化、更新、甚至删除时并不通知下游的系统，这样企业内的数据就会出现混乱。除非从企业的角度对主数据进行负责，否则一个MDM 方案不会成功。非常遗憾的是，这在政治上是个很难解决的问题。为了解决这个问题，企业的高级主管必须要参与进来。
2．权利
企业内开始一个MDM 项目，应该在谈论他们的责任时赋予他们足够的权利。这些权利包括定义角色，分派人员等，也包括建立整个企业内的正式的流程等内容。
3．投资
启动一个MDM 方案需要得到企业的支持和许诺，不仅仅包括人员和时间，还需要对软硬件环境的技术需求进行资金支持。在购买MDM 应用时，其中会包括软件和硬件。这个投资在开始时可能比较小，但是随着时间的发展它会越来越多。所以，对于一个成功的MDM 方案，它需要全企业和高层主管的支持。
4．努力
业务处理过程和主数据都在不断的变化，所以MDM 不能仅仅作为清洗参照数据的一个项目。企业必须要理解，MDM 功能事实上是一个持续的过程，这个过程包括多个需要合作并有优先顺序的项目。一个企业可能会有多个MDM 项目同时进行，例如客户MDM 和产品MDM 等同时进行。这些项目之间必须进行合作，如共享相同的技术实现，使用相同的命名规则、格式、定义，并且要有建立企业MDM 的最终目标，向着这个目标努力。
5．投资回报率
最后，对于每一个MDM 项目，都应该计算出该项目的详细的、可度量的投资回报率。有时候，这样的度量很难得到，这些，需要给企业证明有了MDM 环境会有什么样的好处，如果没有的话会有什么样的危害。
前面提到的这些问题在开始时会使人畏缩的。因此，在启动一个MDM 方案时，应该从其中的一小部分开始。在第一个项目中不要期望能解决所有的问题，成功的建立每一个MDM 项目，每次解决一些问题，这样，问题会逐渐的都得到解决。
4.2. MDM 面临的其他问题
除了前面提到的这些问题以外，还有一些需要考虑的其他问题。例如，对于客户主数据来说，安全问题和隐私问题都是相当重要的。如果不事先建立好正确的管理政策和程序，即使主数据是整合好的、有完善文档的、容易访问的，这个MDM 项目对企业来说是好事还是坏事也很难说。
1．MDM 政策
这些政策包括这些至关重要的数据的所有者是谁，谁来维护它们，谁会使用它们，并且这些内容都要用文档记录下来。这些政策还包括如果没按政策执行的会发生什么。例如，应该建立一个政策来决定谁来负责主数据的使用方式和安全问题。一些例外的情况也要记录下来，用来减小例外发生产生的争议和损失。
2．MDM 数据处理流程
和MDM 的政策相似，这些程序包括以什么样的流程来创建这些主数据，这个过程也需要用文档记录下来。例如，当一个客户的定义发生改变时，如添加客户的属性或者删除客户的记录等问题发生时，应该以什么样的流程来进行处理？如果发现安全上出现问题时，应该采用什么的流程来进行处理？同样，对于例外情况的处理也要记录下来。 最后一个要考虑的是关于企业内数据整合中心的问题，或者称为其他的类似名称的数据中心。不管企业内如何来称呼它，这些数据中心的目的都是建立一个整合的、企业范围的、可信任的、可维护的数据环境，并将这些数据发布给企业用户，用来辅助决策。它们的目的是建立一个高质量的、整合的、保存当前数据和历史数据的知识库。这样的数据中心中的数据包括主数据及与其相关的事务数据，也就是说，这样的数据中心和MDM 项目存在着交集。 有两种方案可以用来解决这种可能存在的冲突。第一种方案是将MDM 功能从数据整合中心中分离处理，建立单独的MDM 功能。这种方案中，MDM 建立和控制主数据及其功能，并将这些主数据的相关信息共享给数据整合中心。这种方案的缺点是两个组有可能没有采用同样的技术和企业数据标准，如果这样的话会引起另外的数据整合问题。 另一种方案是将MDM 功能作为整个数据整合中心的一部分，和提供其他数据的功能一样的提供主数据。这种方案可以共享相同的技术、标准、甚至人员，使主数据与其他数据的整合更容易。
实际建设中，可以根据政策和资金的情况来决定采用什么样的方案是最优的。从一个小方案开始建立MDM ，可以先验证你的企业是否需要这种的应用，再对以后进行判断。
4.3. MDM 的文化挑战
从一个MDM 项目开始
当启动一个MDM 项目时，需要面临很多挑战。其中一小部分是文化上的挑战，它将是你面临的最大的挑战。其余的大部分都是技术上问题。在本篇文章中提到的多个供应商都很重视这些问题。
文化挑战
第一个文化上的挑战是需要为MDM 选择一个典型的业务用例。没有主数据管理会带来很多常见的问题，例如，不能在多个业务部门间联合使用数据，信息的质量差，决策周期长，收入机会丢失，利润下降等。未整合的主数据也会导致很多问题，例如，很难鉴别客户，库存管理不正确，供求链管理低效，操作和财务报表不一致，操作错误等。当然，没有高质量的主数据，数据的一致性规则、甚至合并和获取数据都会成为问题。
在这些问题中的任何一个之上都可以建立一个合理的MDM 用例。在建立这个用例时，应该关注于切实的利益，如改进业务操作，改进IT 及业务处理过程、提高收益等。这些都是有形的好处。那些无形的益处也是很有用的，如
客户满意度提高，改进与供应商的关系，提高数据质量等。
第二个文化上的挑战是获得并保持企业高层的支持。在任何一个企业范围的项目中，不同的业务部门都会对业务实体的定义有不同的理解，最终产生争论和数据的不一致。MDM 项目也会面临同样的问题。如果有一个企业高层指导委员会在支持这个MDM 项目，那么当问题出现时就比较容易解决，项目就可以向好的方向进展。
当MDM 开始实施时，企业的高层也可能会投身于业务定义的争论中。克服这些政治上的障碍可能是最困难的事情。从各个业务部门的视角考虑主数据到从全企业的视角考虑主数据，需要全企业都接受MDM 知识库中的数据作为主数据的SOR 。这就意味着企业内的用户都要完全同意MDM 对企业内关键实体的业务定义，至少要接受这些定义。建立一个整合的，有资格的数据中心可以为克服这些障碍起到重要的作用。这样的数据中心也可以对定义和管理MDM 政策及数据处理流程负责。一个全面的管理计划对成功的实施MDM 也是必要的因素。
第三个文化上的障碍是要确保有足够的资金来支持MDM 的实施直到其完成。尽管实施一个全企业范围的MDM 是一件非常有益的事情，但是这样的项目也是非常昂贵的。MDM 的实施过程需要多年的时间，以逐步增加项目的方式最终实现MDM 。在很多情况下，战术项目都需要实现短期的业务目标。但从长期来说，建立一个全企业范围的MDM 系统是必要的。企业应该在战略上制定好建立全企业MDM 的计划，即使他们采用的自低向上的方式来建立MDM 。
4.4. MDM 的技术挑战
很多与MDM 相关的技术问题在前面都讨论过了，下面是主要技术问题的一个总结。
第一个挑战是要建立一个灵活的MDM 业务及数据模型。这个模型是我们走向成功的路线图。我们永远也不能收集全企业内需要的所有的主数据。这个对主数据的需求会随着时间而发生变化，如随着业务的改变、市场方向的变化及企业文化的变化等发生变化。因为，对于主数据模型的设计者来说，必须要建立一个灵活的模型，当一些变化发生时，不能对以后的模型产生较大的影响。有些MDM 供应商可以提供可定制的行业模板及数据模型，这对我们开始MDM 项目很有帮助。
第二个挑战是关于主数据质量的管理问题。数据质量包括标识和定义所有的主数据属性，对这些属性的质量进行评估并更正存在的问题。这是一个非常重要的任务，尤其是对于企业内各个部门之间的数据出现不一致的定义及使用方式时，这时需要对数据进行一致性处理。数据质量处理有两种方案，第一种是在MDM 方案开始实施时，所有的数据源都先进行数据质量清洗；第二种方案是在MDM 方案中一个一个的清洗来自各个数据源的数据。当数据源的数据发生变化时，同样的数据质量清洗操作也需要进行。市场上有很多数据质量和数据概况分析工具可以为我们提供帮助。对于一些特殊类型的主数据实体，也有特殊的工具可以帮助我们进行数据处理，如地址模式匹配，对产品进行语义分析等。
第三个挑战是由于主数据发生变化而引起的。就像主数据模型需要保持灵活性来接受新的主数据属性一样，MDM 应用也必须具有处理复杂变化的能力，这种变化不光包括数据内容的变化，还包括数据的层级结构、数据之间的关联关系以及在数据之间建立新业务规则等内容的变化。变化是不可避免的，因此，当我们选择一个MDM 技术时，要确定当发生变化时，这个技术的处理不应该很复杂。
第四个挑战是如何将SOE 从操作型系统中迁移到MDM 系统中，这需要同时面对文化和技术上的挑战。技术上的挑战是要保证将SOE 从操作型系统迁移到MDM 的过程要顺畅，不要出现各种问题。当越来越多的SOE 迁移到MDM 环境时，相应的操作型系统中的录入功能要禁止掉，否则会出现重复录入的问题。如果一个SOR 不能迁移到MDM 系统中，要保证有一个简单的方式将外部的主数据迁移入MDM 系统中，来保证SOR 是最新的。
MDM 面临的第五个挑战是对标识的管理，尤其是对客户主数据来说。因为客户可能是全球范围的，客户之间有着复杂的关联关系，而且这些关联关系还在不断的变化中。MDM 环境必须能够建立对这些客户建立唯一的标识来适应这种复杂的情况。在很多情况下，这也是文化上的问题。企业必须能够同意建立这些全球内唯一的标识来鉴别不同的客户，这样才能确保MDM 维护主数据的更新和变化的功能。
MDM 面临的最后一个挑战是关于MDM 整个基础结构的挑战。不论MDM 这个概念是新的还是旧的，都需要一套技术体系来支撑它。有很多公司都建立了部分的或者不完善的MDM 解决方案。这些对供应商来说也许是好事。这些供应商一般会关注于MDM 环境中的某个特定技术，对此进行研究和开发，例如进行数据质量管理等。所以，这些供应商一般都是对MDM 的某个一个特定部分可以提供完善的解决方案。而企业必须要保证这些不同供应商提供的技术可以整合成一套完善的MDM 基础机构。而且，由于在MDM 环境中包含了大量的、复杂的、分散的数据环境和系统，这就使得MDM 解决方案能提供通用的主数据整合基础结构变得至关重要。这个MDM 基础结构必须要和企业的数据整合策略及方案保持一致。
有些供应商会提供包含MDM 环境各个部分的完善的解决方案。在很多案例中，这些供应商都合并或者收购了提供专门技术的公司，来组成完整的解决方案。这些完整的解决方案不一定在每一个环节都是最好的，他们的优势在于可以减少由于供应商的不同而产生的数据接口和数据交互。企业需要自己来决定什么样的解决方案是适合自己的。
4.5. MDM 的成功因素
正像前面提到的一样，企业MDM 是一个多年的项目，需要企业高层的支持，需要一个长远的战略计划。企业内会不断新增各种业内的项目，MDM 的成功需要与这些项目进行配合而逐步建立。
有时，MDM 项目会延伸到企业数据整合和数据仓库项目之中，或者成为其中的一部分。每一个做整合工作的项目组都应该认真考虑其工作对企业主数据的影响，也要考虑到企业MDM 解决方案的总目标。
贯穿MDM 的整个开发周期，重点应该放到下面三个方面，建立一个合并的主数据业务和数据模型，数据质量管理，建立一套全面的管理政策和程序。MDM 应用必须和企业整合框架紧密的结合在一起。SOA 架构的使用将成为这个整合框架中关键的一部分。建立一个数据整合管理中心可以有效的支持MDM 应用开发和部署的方方面面。
5. 五、总结
正确的实施，主数据管理可以提供非常大的业务收益，如提高生产力，减小风险，增加收益。很多公司建立MDM 方案时，只部署一个主数据整合（MDI ）应用，目标定位于一个特定的业务问题，如建立一个客户的单一视图，或者管理产品的单一视图或者其他的企业实体。但是需要注意的是，尽管这些MDI 可以提供一个企业内单一的业务视图，它并不能解决大部分企业内存在的主数据问题，它只能掩盖问题。
一个企业MDM 的解决方案中，需要业务用户参与MDM 的处理过程，在MDI 的基础上需要添加管理、跟踪和审计不断变化的主数据及其元数据的功能。企业MDM 是一个单独的IT 部件，它维护着企业内主数据的SOE 和SOR 。它为企业内的业务处理系统和商务智能系统提供主数据。它也可以用来推进数据仓库环境的建立，作为商业智能应用处理的基础。
企业MDM 是一个多年的战略目标，可以从建立主数据登记、主数据整合中心的项目开始进行，最终的目标是建立企业MDM 。
最后，我们引用一个供应商的主管的一段话来作为MDM 的总结，这句话总结了MDM 的现状。“每个人都希望得到一个完善的主数据解决方案，但是从目前市场上的技术及能力来看，达到满意的要求还需要几年的时间。目前企业内讨论的焦点还在应该建立一个MDM 还是建立多个MDM 之上。而在我们评估或者建立正确的MDM 解决方案之前，我们要考虑的还是一些基本的因素，如数据的类型（操作型还是分析型）、数据的延迟时间、聚集的程度、数据的容量、用户视角（业务用户和IT 用户）的不同等。”
5.1. 附录A ：定义
附录A ：定义
Master data: This is reference data about the core business entities of an organization, such as people (customers, employees and suppliers), things (products, finances/ledgers and assets) and places (locations). Many people think of these as major data subject areas (in enterprise data modeling terms) or as dimensions (in multidimensional analytics terms).
主数据（master data）：企业内核心业务实体的参照数据，如人员（客户、雇员和供应商等），事物（产品、财务/分类帐和资产等），场所（位置等）等内容。从企业建模者（3NF 建模者）的术语来说，主数据就是主题域中的主要数据，从维度建模者的术语来说，主数据就是维度数据。
Master data business model: This is a model that documents (in an easy-to-understand format) master data entities, attributes, and relationships and corresponding technical metadata. This model is stored in the master metadata store (MMS).
主数据业务模型（master data business model ）：以一种容易理解的方式记录的关于主数据的实体、属性、关联关系及相应的技术元数据的模型。这个模型存储在主数据的元数据存储中（MMS ，master metadata store）。
Master data identity registry, master data integration hub and enterprise MDM: These are the three main approaches to master data management.
主数据标识登记（master data identity registry ）、主数据整合中心（master data integration hub ）和企业主数据管理（enterprise MDM）：这些是主数据管理的三个主要步骤。
Master data integration (MDI) services: These are the various underlying data services and associated technologies used by MDM applications to integrate master data.
主数据整合服务（master data integration services）：这些是与MDM 应用技术相关联的一些底层服务，用来整合主数据。
Master data management (MDM): A set of disciplines, applications and technologies for harmonizing and managing the system of record and system of entry for the data and metadata associated with the key business entities of an organization. 主数据管理（MDM ，master data management）：主数据管理是一系列的规则、应用和技术，目的是为了协调和管理与企业的核心业务实体相关的系统记录和系统登录中的数据和元数据。
Master metadata store (MMS): A single repository containing metadata and business rules associated with master data. 主数据的元数据存储（MMS ，master metadata store）：一个知识库，保存着与主数据相关的元数据和业务规则。 MDM applications: These employ master data integration (MDI) services to create and maintain master data.
主数据管理应用（MDM applications）：使用主数据整合服务来建立和维护主数据的应用。
System of entry: The application system responsible for creating and maintaining master data and its associated metadata. 系统登录（SOE ，system of entry）：创建和维护主数据及其元数据的应用系统。
System of record: The application system responsible for publishing the master copy of any given piece of master data and its metadata.
系统记录（SOR ，system of record）：负责发布主数据及其元数据的应用系统。
5.2. 附录B ：MDM 调查
附录B ：MDM 调查
作为这个MDM 研究项目的一部分，作者关于MDM 在公司的使用情况做了一个简短的调查，调查的地点是Business Intelligence Network 。在接受调查的60个公司中，有30个准备启动MDM 项目，7个已经实施并有了结果，23个还没有关于MDM 的计划。启动MDM 项目的37个公司中，有26个关注于产品数据，23个关注于客户数据，9个关注于财务数据。很有意思的事情是关注于产品主数据的公司比关注于客户主数据的还要多，这很出乎以外。期望中，客户主数据的整合需求更高一些。
我们报告中的一个焦点是关于主数据整合和主数据管理的区别。很多MDM 项目关注于整合，例如，他们努力去解决主数据现存的不一致问题，而不是去解决产生不一致的根源。管理主数据，从另一个角度讲，不仅要关注于建立一个单一的系统记录（system of record），而且也要关注于系统登录（system of entry），因为主数据的问题产生于系统登录。真正的企业主数据管理也应该处理过去，现在和未来的主数据的层级结构。这样的系统对数据仓库的设计是非常有价值的。
在调查中，我们提供了关于MDM 的两个定义。一个关注于主数据整合和技术，而另一个关注于真正的企业主数据管理和主数据管理规则。19个接受调查的公司选择了前者，倾向于技术定义；而39个选择了后者，倾向于企业MDM 的定义。