主数据管理（MDM）的出现源于企业提高关键数据资产一致性和质量的需要，例如产品数据、资产数据、客户数据、位置数据等。
根据Dataversity最近的一篇文章，分析师预测数字化企业将在2023年通过其企业数据管理和数据治理战略脱颖而出。当今的许多企业，尤其是全球企业拥有数百个独立的应用程序和系统（即ERP、CRM），其中数据跨组织部门或分部的信息很容易变得支离破碎、重复并且最常见的是过时的。发生这种情况时，准确回答有关任何类型的绩效指标或业务KPI的最基本但关键的问题都会变得很痛苦。
获得基本问题的答案，例如“谁是我们最赚钱的客户？”、“哪些产品的利润率最高？”或者在某些情况下，“我们有多少员工”？变得难以回答——或者至少难以准确回答。
基本上，对准确、及时的信息的需求是迫切的，并且随着数据源的增加，一致地管理数据并保持数据定义最新，以便企业的所有部分都使用相同的信息是一个永无休止的挑战。
为了应对这一挑战，企业需要实施主数据管理(MDM)以获得单一事实真相的能力。
大多数软件系统都有由组成系统的多个应用程序共享和使用的数据列表。
例如：典型的ERP系统至少会有客户主数据、项目主数据和帐户主数据列表。该主数据通常是公司的关键资产之一。事实上，一家公司被收购主要是为了访问其客户主数据，这种情况并不罕见。
了解主数据最重要的步骤之一是了解术语。首先，有一些非常容易理解且易于识别的主数据项，例如“客户”和“产品”。说实话，许多人只是通过背诵共同商定的主数据项列表来定义主数据，例如：客户、产品、位置、员工和资产。
但是，如何识别应由MDM系统管理的数据元素要复杂得多，并且违背了此类基本定义。这在什么是主数据以及如何限定主数据方面造成了很多混乱。
为了更全面地回答“什么是主数据？”这个问题，我们可以看看公司中常见的6种数据类型：
1.非结构化数据：在电子邮件、白皮书、杂志文章、公司内部网门户、产品规格、营销材料和PDF文件中找到的数据。
2.交易数据：关于具有历史意义或其他系统分析所需的业务事件的数据（通常与系统交易相关，例如销售、交付、发票、故障单、索赔和其他货币和非货币交互）。交易数据是使用主数据实体的单位级交易。与主数据不同，交易本质上是暂时的和瞬时的。
3.元数据：有关其他数据的数据。它可能驻留在正式的存储库中或以各种其他形式存在，例如XML文档、报告定义、数据库中的列描述、日志文件、连接和配置文件。
4.层次数据：存储其他数据之间关系的数据。它可以作为会计系统的一部分存储，也可以作为现实世界关系的描述单独存储，例如公司组织结构或产品线。分层数据有时被认为是一个超级MDM域，因为它对于理解和有时发现主数据之间的关系至关重要。
5.参考数据：一种特殊类型的主数据，用于对其他数据进行分类或用于将数据与企业边界之外的信息相关联。参考数据可以在主数据或交易数据对象（例如国家、货币、时区、付款条件等）之间共享
6.主数据：企业内的核心数据，描述业务开展所围绕的对象。它通常很少更改，并且可以包含运营业务所需的参考数据。主数据本质上不是事务性的，但它确实描述了事务。主数据涵盖的业务关键名词通常分为四个领域，这些领域内的进一步分类称为主题领域、子领域或实体类型。
四个通用主数据域是：
在人员域中，有客户、员工和销售员子域。
在物料域内，有物资、产品、零件、服务和资产子域。
位置
在位置域内，有办公位置和地理分区子域。
在另一个域中，有诸如合同、保修和许可子域之类的东西。
其中一些子域可能会进一步划分。例如，可以根据激励和历史对客户进行进一步细分，因为您的公司可能有普通客户以及高级客户和执行客户。同时，产品可能会按部门和行业进一步细分。这种粒度级别很有帮助，因为消费品(CPG)行业的产品的要求、生命周期和CRUD周期可能与服装行业的产品非常不同。域的粒度基本上由域内实体属性之间的差异大小决定。
虽然识别主数据实体非常简单，但并非所有符合主数据定义的数据都必须这样管理。一般来说，从数据量的角度来看，主数据通常只占所有数据的一小部分，但它是一些最复杂的数据，也是维护和管理起来最有价值的数据。
我们建议使用以下标准，在决定是否应将给定实体视为主数据时，应同时考虑所有这些标准。
主数据可以通过它与其他数据交互的方式来描述。
例如：
在交易系统中，主数据几乎总是与交易数据相关。客户购买产品，供应商销售零件，合作伙伴将一箱材料运送到某个地点。员工在层级上与他们的经理相关，经理通过经理（另一名员工）向上报告。产品可能是描述其在仓库中的位置的多个层次结构的一部分。
主数据和交易数据之间的这种关系可以从根本上被视为名词/动词关系。交易数据捕获动词，例如销售、交付、购买、电子邮件和撤销，而主数据捕获名词。这是相同的关系数据仓库事实和维度共享。
主数据可以通过创建、读取、更新、删除和搜索的方式来描述。此生命周期称为CRUD周期，对于不同的主数据元素类型和公司来说是不同的。
例如：
如何创建客户很大程度上取决于公司的业务规则、行业细分和数据系统。一家公司可能有多种客户创造途径，例如通过互联网、直接通过客户代表或通过直销店。另一家公司可能只允许通过电话直接联系其呼叫中心来创建客户。此外，创建客户元素的方式当然不同于创建供应商元素的方式。
下表说明了四个常见主数据主题区域的不同CRUD周期。
顾客 | 产品 | 资产 | 员工 | |
创建 | 客户访问（例如公司网站或设施）会触发帐户创建 | 在SCM的参与下购买或制造产品 | 经过必要的审批流程后，通过开立采购订单来获取单位 | 人力资源部雇用一名新员工，然后他必须填写大量表格、参加入职培训、选择福利、确定资产分配并遵守办公室分配 |
读取 | 基于观众凭据的情境化视图 | 定期库存目录 | 定期报告目的、计算折旧、验证 | 办公室使用、审查、保险索赔、移民 |
更新 | 地址、折扣、电话号码、偏好、信用账户 | 包装变化、原材料变化 | 转让、维护、事故报告 | 移民身份、婚姻状况、级别提升、加薪、调职 |
删除 | 死亡、破产、清算、拒收通知 | 取消、替换、不再可用 | 过时、出售、毁坏、被盗、报废 | 终止、死亡 |
搜索 | CRM系统、呼叫中心系统、联系人管理系统 | ERP系统、订单处理系统 | 总账跟踪、资产数据库管理 | HRLOB系统 |
随着基数（集合中元素的数量）的减少，元素被视为主数据元素的可能性——即使是普遍接受的主题领域，如客户——也会减少。
例如：
如果一家公司只有三个客户，那么该组织很可能不会考虑这些客户的主数据——至少在使用MDM解决方案支持他们的情况下不会考虑，这仅仅是因为使用主数据基础架构管理这些客户没有任何好处.相比之下，一家拥有数千名客户的公司会认为客户是一个重要的主题领域，因为管理如此庞大的实体集会带来随之而来的问题和好处。
这些公司的客户价值是相同的，因为它们都依赖客户开展业务。但是，一个不需要客户主数据解决方案，而另一个则需要。基数不会改变给定实体类型的分类；然而，随着实体类型基数的增加，拥有管理实体类型的解决方案的重要性也随之增加。
主数据的波动性往往低于交易数据。随着它变得更加不稳定，它通常被认为更具交易性。
例如：
有些人可能认为“合同”是一个主数据元素。其他人可能会将其视为交易。根据合同的生命周期，它可以采用任何一种方式。
推广职业运动员的机构可能会考虑他们的合同主数据。在这种情况下，每个都彼此不同，并且通常具有超过一年的生命周期。简单地拥有一个名为“运动员”的主数据项可能很诱人。然而，运动员往往在任何给定时间都有不止一份合同：一份是与他们的团队签订的，另一些是与公司签订的产品代言合同。随着时间的推移，随着每份合同的要素重新谈判或运动员被交易，该机构需要管理所有这些合同。
其他合同（例如，汽车细节设计合同或房屋粉刷合同）更像是一项交易。它们是一次性的、短期的协议，旨在提供付款服务，通常会在数小时内履行和销毁。
简单实体，即使它们是有价值的实体，也很少成为管理挑战，并且很少被视为主数据元素。元素越不复杂，管理该元素变更的可能性就越小。通常，此类资产只需收集和统计即可。
例如：
诺克斯堡可能不会追踪其存储的每根金条的信息，而只会记录金条的数量。每根金条价值高、基数高、寿命长，但复杂程度低。
数据元素对公司越有价值，就越有可能被视为主数据元素。价值和复杂性共同作用。
虽然主数据通常不如交易数据易变，但属性完全不变的实体通常不需要主数据解决方案。
例如：
稀有硬币似乎满足主数据处理的许多标准。稀有硬币收藏家可能会拥有许多稀有硬币，因此基数很高。它们也很有价值且复杂，因为它们有历史和描述（例如正面、反面、图例、铭文、边缘和区域以及设计师姓名缩写、边缘设计、层次和肖像等属性）。
尽管有所有这些条件，但稀有硬币不需要作为主数据项进行管理，因为它们不会随时间变化——或者，至少，它们变化不够大。随着特定硬币的历史被揭示或某些属性必须更正，可能需要添加更多信息，但一般来说，稀有硬币不会通过主数据管理系统进行管理，因为它们的波动性不足以保证它。
主数据管理的主要驱动力之一是重用。
例如：
在一个简单的示例中，CRM系统将管理有关客户的所有信息，并且永远不需要与其他系统共享有关客户的任何信息。然而，在当今复杂的环境中，客户信息需要在多个应用程序之间共享。这就是麻烦开始的地方。
由于多种原因，对主数据的访问并不总是可用，因此人们开始将主数据存储在不同的位置，例如电子表格和应用程序私有存储。仍然有一些原因，例如数据质量下降和衰退，需要管理未在整个企业中重复使用的主数据。但是，如果一个主数据实体在多个系统中重复使用，则肯定应该使用MDM系统对其进行管理。
虽然枚举各种主数据实体类型很简单，但有时决定公司中的哪些数据项应视为主数据更具挑战性。
通常，通常不符合主数据定义的数据可能需要按原样进行管理，而符合定义的数据则可能不需要。
最终，在决定应将哪些实体类型视为主数据时，最好根据业务需求上下文中的行为和属性对它们进行分类，而不是依赖简单的实体类型列表。
由于主数据由多个应用程序使用，一处数据的错误可能会导致使用该数据的所有应用程序出现错误。
例如：
客户主数据中的地址不正确可能意味着订单、账单和营销资料都发送到错误的地址。同样，项目主控上的错误价格可能是一场营销灾难，而客户主控中的账号不正确可能会导致CEO被处以巨额罚款甚至入狱——这对犯错的人来说是一种职业生涯限制。
一个典型的主数据恐怖故事
一位信用卡客户从2847North9thSt.搬到100111thSt.North。客户立即更改了帐单地址，但几个月都没有收到帐单。一天，客户接到信用卡账单部门打来的恐吓电话，询问为什么还没有支付账单。客户确认他们拥有新地址，计费部门确认存档地址为100111thSt.North。客户要求提供账单副本以结账。
两周后没有收到账单，客户回电发现账户已移交给催收机构。这一次，客户发现即使文件中的地址是100111thSt.North，账单地址却被列为10111thSt.North。经过律师的多次电话和信件，账单终于得到解决，信用卡公司永远失去了一位客户。
在这种情况下，数据的主副本是准确的，但另一个副本有缺陷。主数据必须正确且一致。即使主数据没有错误，也很少有组织只有一套主数据。许多公司通过兼并和收购成长，母公司收购的每家公司都有自己的客户主数据、项目主数据等。
如果您可以将新的主数据与当前的主数据结合起来，这还不错，但除非被收购的公司在遥远的国家从事完全不同的业务，否则某些客户和产品很有可能同时出现在两者中主数据集——通常具有不同的格式和不同的数据库密钥。
如果两家公司都使用Dun&BradstreetNumber或SocialSecurityNumber作为客户标识符，发现哪些客户记录属于同一客户是一个简单的问题；但这种情况很少发生。在大多数情况下，客户编号和零件编号由创建主记录的软件分配，因此同一客户或同一产品在两个数据库中具有相同标识符的可能性很小。如果同等零件是从具有不同供应商编号的不同供应商处购买的，则项目主数据可能更难协调。
将主列表合并在一起可能非常困难，因为同一客户在不同的数据库中可能有不同的姓名、客户编号、地址和电话号码。例如，WilliamSmith可能显示为BillSmith,Wm。史密斯和威廉·史密斯。普通的数据库连接和搜索将无法解决这些差异。
需要一个非常复杂的工具来理解昵称、替代拼写和打字错误。该工具可能还必须认识到，如果不同的名称变体都住在同一地址或具有相同的电话号码，则可以解决这些问题。
虽然创建一个干净的主列表可能是一项艰巨的挑战，但拥有一个通用的主列表可以给底线带来许多积极的好处，包括：
单一的合并账单，可节省资金并提高客户满意度
无需担心向多个客户列表中的客户发送相同的营销资料，这会浪费金钱并激怒客户
整个组织内客户的统一视图，这样用户在将客户帐户转交给催收机构之前就知道该客户是否欠组织其他部门的钱，或者更重要的是，该客户是否是另一个部门的最大来源业务的
商品的综合视图，以消除金钱和货架空间的浪费，以及因使用不同零件编号库存相同商品而造成的人为短缺的风险
最后，SOA、SaaS和中台的发展使MDM成为一个关键问题。
例如：
如果您创建通过明确定义的XML消息进行通信的单一客户服务，您可能会认为已经定义了客户的单一视图。但是，如果同一个客户存储在具有三个不同地址和四个不同电话号码的五个数据库中，那么您的客户服务将返回什么？
同样，如果决定订阅通过SaaS提供的CRM服务，服务提供商将需要为其数据库提供客户列表。您将发送哪个列表？
由于所有这些原因，为组织维护一组高质量、一致的主数据正迅速成为一种必要。维护此数据所需的系统和流程称为主数据管理。
主数据管理(MDM)是确保主数据在整个企业内协调的技术、工具和流程。MDM提供了一个统一的主数据服务，可以在整个企业和业务合作伙伴之间提供准确、一致和完整的主数据。
在这个定义中有几点值得注意：
MDM不仅仅是一个技术问题。在许多情况下，需要对业务流程进行根本性更改以维护干净的主数据，而一些最困难的MDM问题更多的是政治而非技术问题。
MDM包括创建和维护主数据。投入大量时间、金钱和精力来创建一组干净、一致的主数据是一种浪费，除非解决方案包含能够在主数据随着时间的推移更新和扩展时保持主数据干净和一致的工具和流程。
根据所使用的技术，MDM可能涵盖单个域（客户、产品、位置或其他）或多个域。多域MDM的优势包括一致的数据管理体验、最小化的技术足迹、跨域共享参考数据的能力、更低的总拥有成本和更高的投资回报。
鉴于MDM不仅仅是一个技术问题，这意味着您不能只安装一项技术并解决所有问题，那么强大的MDM程序需要什么？
在开始使用主数据管理计划之前，您的MDM策略应围绕以下6个方面构建：
治理：管理组织机构、政策、原则和质量的指令，以促进对准确且经过认证的主数据的访问。从本质上讲，这是跨职能团队定义MDM程序各个方面的过程。
衡量：根据既定的目标，表现如何？衡量应该着眼于数据质量和持续改进。
组织：在整个MDM计划中安排合适的人员，包括主数据所有者、数据管理员和参与治理的人员。
政策：MDM计划应遵守的要求、政策和标准。
流程：跨数据生命周期的定义流程，用于管理主数据。
技术：主数据中心和任何支持技术。
一旦获得MDM计划的支持，就可以开始了。虽然MDM在应用于组织中的所有主数据时最为有效，但在许多情况下，企业范围内的工作的风险和费用很难证明是合理的。
专业提示：通常更容易从一些关键的主数据来源开始，并在证明成功并吸取教训后扩大努力。
如果你确实从小处开始，你应该对你最终可能想要包含在你的程序中的所有主数据进行分析，这样你就不会做出设计决策或工具选择，而这些决策或工具选择将迫使你在尝试合并一个项目时重新开始。新的数据源。例如，如果您的初始客户主实施仅包括您的直接销售人员处理的10,000个客户，您不希望做出会妨碍以后添加10,000,000个Web客户的设计决策。
您的MDM项目计划将受到需求、优先级、资源可用性、时间范围和问题规模的影响。大多数MDM项目至少包括以下阶段：
（1）确定主数据的来源
这一步通常是一个非常有启发性的练习。一些公司发现他们有数十个数据库，其中包含IT部门不知道存在的客户数据。
（2）识别主数据的生产者和消费者
此步骤涉及查明哪些应用程序生成在第一步中识别的主数据，并且通常更难以确定哪些应用程序使用主数据。根据您用于维护主数据的方法，此步骤可能不是必需的。例如，如果在数据库级别检测和处理所有更改，则更改来自何处可能无关紧要。
（3）收集和分析主数据的元数据
对于第一步中确定的所有来源，数据的实体和属性是什么？它们意味着什么？这应该包括：
属性名称
数据类型
允许值
约束条件
默认值
依赖关系
谁拥有数据的定义和维护
“所有者”是最重要的，通常也是最难确定的。如果您的存储库加载了所有元数据，则此步骤很简单。如果您必须从数据库表和源代码开始，这可能需要付出很大的努力。
（4）任命数据管理员
这些人应该是了解当前源数据并有能力确定如何将源数据转换为主数据格式的人员。一般来说，管理员应该由每个主数据源的所有者、负责MDM系统的架构师和来自主数据的业务用户的代表任命。
（5）实施数据治理计划和数据治理委员会
该小组必须拥有知识和权力来决定如何维护主数据、它包含什么、保留多长时间以及如何授权和审计更改。在主数据项目的过程中必须做出数百个决策，如果没有明确定义的决策机构和流程，项目可能会失败，因为政治阻碍了有效的决策。
（6）开发主数据模型
确定主记录的外观，包括包含哪些属性、它们的大小和数据类型、允许的值等等。此步骤还应包括主数据模型和当前数据源之间的映射。这通常是该过程中最重要也是最困难的步骤。如果您试图通过在主实体中包含所有源属性来让每个人都满意，您通常会得到过于复杂和繁琐而无用的主数据。
例如：
如果您无法决定重量应该以磅还是公斤为单位，一种方法是包括两者（WeightLb和WeightKg）。虽然这可能会让人们高兴，但您正在为可以以微秒为单位计算的数字浪费数兆字节的存储空间，并冒着创建不一致数据的风险（WeightLb=5和WeightKg=5）。虽然这是一个非常简单的示例，但更大的问题是维护同一零件的多个零件号。
正如在任何委员会的努力中一样，会有导致次优决策的争吵和交易。重要的是要提前制定决策流程、优先事项和最终决策者，以确保事情顺利进行。
（7）选择一个工具集
您将需要购买或构建工具，通过清理、转换和合并源数据来创建主列表。您还需要一个基础设施来使用和维护主列表。本文稍后将详细介绍这些功能。您可以使用来自单一供应商的单一工具集来实现所有这些功能，或者您可能希望采用同类最佳的方法。一般来说，不同类型的数据清理和合并数据的技术是不同的，所以没有很多工具可以涵盖整个主数据范围。工具的两个主要类别是用于创建客户主数据的客户数据集成(CDI)工具和用于创建产品主数据的产品信息管理(PIM)工具。有些工具可以同时完成这两项工作，但通常工具更擅长其中一项。该工具集还应该支持查找和修复数据质量问题以及维护版本和层次结构。版本控制是一项关键功能，因为了解主数据记录的历史对于长期保持其质量和准确性至关重要。
例如：
如果合并工具合并了波士顿JohnSmith的两条记录，并且您确定波士顿确实有两个不同的JohnSmith，则您需要知道记录在合并之前的样子，以便“取消合并”它们。
从全局来看，需要关注的功能包括数据建模、集成、数据匹配、数据质量、数据管理、层次结构管理、工作流和数据治理。从非功能角度来看，您还应该考虑可扩展性、可用性和性能。
（8）设计基础设施
一旦您拥有干净、一致的主数据，您将需要将其公开给您的应用程序并提供管理和维护它的流程。实施此基础架构后，您将拥有许多依赖于其可用性的应用程序，因此可靠性和可扩展性是设计中需要考虑的重要因素。在大多数情况下，您必须自己实现基础设施的重要部分，因为它将被设计为适合您当前的基础设施、平台和应用程序。
（9）生成和测试主数据
在此步骤中，您可以使用已开发或购买的工具将源数据合并到主数据列表中。这通常是一个迭代过程，需要修改规则和设置以获得正确的匹配。此过程还需要进行大量人工检查，以确保结果正确并满足为项目制定的要求。
没有任何工具能够在100%的时间内正确完成匹配，因此您必须权衡错误匹配与错过匹配的后果，以确定如何配置匹配工具。如果账单不准确或逮捕了错误的人，错误匹配可能会导致客户不满。错过太多匹配会导致主数据的用处降低，因为您无法获得在MDM中投入的收益。
（10）修改生产和消费系统
根据MDM实施的设计方式，您可能必须更改生成、维护或使用主数据的系统才能使用新的主数据源。如果主数据用于与源系统分离的系统（例如数据仓库），则源系统可能不需要更改。
但是，如果源系统要使用主数据，则可能需要进行更改。源系统必须访问新的主数据，或者主数据必须与源系统同步，以便源系统拥有清理后的主数据的副本可供使用。如果无法更改一个或多个源系统，则该源系统可能无法使用主数据，或者主数据必须通过外部进程（例如触发器和SQL）与源系统的数据库集成命令。
在创建新记录或更新现有主记录之前，应更改生成新记录的源系统以查找现有主记录集。这确保了上游生成的数据质量良好，以便MDM可以更有效地运行，并且应用程序本身可以管理数据质量。MDM不仅应用作记录系统，还应用作促进企业中所有应用程序更清洁、更高效地处理数据的应用程序。
作为MDM策略的一部分，您需要研究数据管理的所有三个支柱：
数据来源
数据管理
数据消耗
如果忽略其中任何一个方面，就不可能拥有稳健的企业级MDM策略。
（11）实施维护流程
如前所述，任何MDM实施都必须结合工具、流程和人员来维护数据质量。所有数据都必须有一个数据管理员，负责确保主数据的质量。
数据管理员通常是了解数据的业务人员，可以识别不正确的数据，并拥有纠正问题的知识和权限。MDM基础架构应包括帮助数据管理员识别问题和简化更正的工具。一个好的数据管理工具应该指出所进行的有问题的匹配，例如居住在同一地址的具有不同姓名和客户编号的客户。
管理员可能还想查看由于匹配标准接近但低于阈值而作为新添加的项目。对于数据管理员来说，查看MDM系统对数据所做的更改历史记录非常重要，以便隔离错误源并撤消不正确的更改。维护还包括将更改和添加内容拉入MDM系统以及将清理后的数据分发到所需位置的过程。
正如您所看到的，MDM是一个可能持续很长时间的复杂过程。与软件中的大多数事情一样，成功的关键是逐步实施MDM，以便业务实现一系列短期收益，而完整的项目是一个长期的过程。
此外，没有业务用户的支持和参与，任何MDM项目都不可能成功。IT专业人员不具备创建和维护高质量主数据的领域知识。任何不包括对创建、维护和验证主数据的流程进行更改的MDM项目都可能会失败。
本文的其余部分将详细介绍创建和维护主数据的技术和流程。
无论您购买MDM工具还是决定构建自己的MDM工具，创建主数据都有两个基本步骤：
清理和标准化数据
匹配来自所有来源的数据以合并重复项。
在开始清理和规范化数据之前，您必须了解主数据的数据模型。作为建模过程的一部分，您应该定义每个属性的内容并定义从每个源系统到主数据模型的映射。现在，您可以使用此信息来定义清理源数据所需的转换。
清理数据并将其转换为主数据模型与用于填充数据仓库的提取、转换和加载(ETL)过程非常相似。如果您已经定义了ETL工具和转换，那么根据主数据的需要修改这些工具可能比学习新工具更容易。以下是一些典型的数据清理功能：
标准化数据格式：使所有电话号码看起来都一样，将地址等转换为通用格式。
替换缺失值：插入默认值，从地址查找邮政编码，查找Dun&BradstreetNumber。
标准化值：将所有测量值转换为公制，将价格转换为通用货币，将零件号更改为行业标准。
映射属性：从联系人姓名字段中解析名字和姓氏，将Part#和partno移至PartNumber字段。
大多数工具会尽可能地清理数据，并将其余数据放入错误表中以供手动处理。根据匹配工具的工作方式，清理后的数据将放入主表或一系列暂存表中。在清理每个源时，您应该检查输出以确保清理过程正常工作。
匹配主数据记录以消除重复项是创建主数据中最难也是最重要的步骤。错误的匹配实际上可能会丢失数据（例如，两个AcmeCorporations变成一个）并且丢失的匹配会降低维护公共列表的价值。
因此，MDM工具的匹配精度是最重要的购买标准之一。
有些比赛做起来非常简单。如果您有所有客户的社会安全号码，或者如果您的所有产品都使用通用编号方案，则数据库JOIN将找到大部分匹配项。然而，这在现实世界中几乎不会发生，因此匹配算法通常非常复杂和精密。客户可以根据姓名、婚前姓名、昵称、地址、电话号码、信用卡号码等进行匹配，而产品则可以根据名称、描述、部件号、规格和价格进行匹配。
专业提示：属性匹配越多且匹配越接近，MDM系统对匹配的置信度越高。
为每个匹配计算此置信因子，如果它超过阈值，则记录匹配。阈值通常根据错误匹配的后果进行调整。
例如：
您可以指定如果置信度超过95%，记录将自动合并，如果置信度介于80%和95%之间，数据管理员应该在合并之前批准匹配。
大多数合并工具将一组输入合并到主列表中，因此最好的过程是从您最有信心的数据开始列表，然后一次将其他来源合并为一个。如果您有大量数据并且存在很多问题，则此过程可能需要很长时间。
专业提示：您可能希望从合并后希望从中获得最大收益的数据开始，然后使用该数据运行试点项目以确保您的流程正常运行并确保您看到预期的业务收益。
从那里，您可以在时间和资源允许的情况下开始添加其他来源。这种方法意味着您的项目将花费更长的时间，并且可能成本更高，但风险较低。这种方法还可以让您从几个组织开始，并在项目展示成功时添加更多组织，而不是试图从一开始就让每个人都参与进来。
将源数据合并到主列表时要考虑的另一个因素是隐私。当客户成为客户主数据的一部分时，他们的信息可能对任何有权访问客户主数据的应用程序可见。如果客户数据是根据限制其使用到特定应用程序的隐私策略获取的，则您可能无法将其合并到客户主数据中。
由于涉及隐私问题，您可能需要在MDM规划团队中添加一名法律顾问。
此时，如果您的目标是生成主数据列表，那么您就完成了。将其打印出来或刻录到外部硬盘上然后继续。如果您希望主数据在数据添加和更改时保持最新状态，则必须开发基础架构和流程来管理主数据。
（二）如何维护主列表
有许多不同的工具和技术用于管理和使用主数据。我们将在这里介绍三种更常见的场景：
1.单副本：在这种方法中，主数据只有一个主副本。所有添加和更改均直接对主数据进行。所有使用主数据的应用程序都将被重写，以使用新数据而不是当前数据。这种方法保证了主数据的一致性，但在大多数情况下并不实用。这是因为修改所有应用程序以使用具有不同架构和不同数据的新数据源至少非常昂贵。如果您的某些应用程序是购买的，甚至可能是不可能的。
2.多个副本，单一维护：在这种方法中，主数据在数据的单个主副本中添加或更改，但更改会发送到本地存储副本的源系统。每个应用程序可以更新不属于主数据的部分数据，但不能更改或添加主数据。
例如：
库存系统可能能够更改零件的数量和位置，但无法添加新零件，并且无法更改产品主数据中包含的属性。这减少了所需的应用程序更改数量，但应用程序至少必须禁用添加或更新主数据的功能。用户将不得不学习新的应用程序来添加或修改主数据，而他们通常做的一些事情将不再起作用。
3.连续合并：在这种方法中，应用程序可以更改其主数据的副本。对源数据所做的更改将发送到主数据，并在其中合并到主数据列表中。然后，对主系统的更改将发送到源系统并应用到本地副本。这种方法几乎不需要对源系统进行任何更改。如有必要，可以在数据库中处理更改传播，因此不会更改应用程序代码。从表面上看，这似乎是理想的解决方案，因为应用程序更改已最小化并且不需要重新培训。每个人都继续做他们正在做的事情，但数据质量更高、更完整。但是，这种方法确实存在几个问题：
更新冲突是可能的并且难以调和：如果两个源系统将客户的地址更改为不同的值会发生什么？MDM系统无法决定保留哪一个，因此需要数据管理员进行干预。同时，客户有两个不同的地址。这必须通过创建数据治理规则和标准操作程序来解决，以确保减少或消除更新冲突。
添加必须重新合并：添加客户时，另一个系统可能已经添加了该客户。为了应对这种情况，所有的数据添加都必须重新经过匹配过程，以防止master中出现新的重复项。
保持一致的值更加困难：如果产品的重量从磅转换为千克，然后再转换回磅，四舍五入可能会改变原始重量。这可能会让输入一个值然后在几秒钟后看到它发生变化的用户感到不安。
一般来说，所有这些事情都可以规划和处理，使用户的生活变得更轻松，但代价是维护更复杂的基础设施以及数据管理员的更多工作。这可能是一种可以接受的取舍，但应该有意识地做出取舍。
无论您如何管理主数据，了解数据如何达到当前状态都很重要。
例如：
如果客户记录是从两个不同的合并记录合并而成的，您可能需要知道原始记录是什么样子，以防数据管理员确定这些记录是错误合并的，并且实际上应该是两个不同的客户。版本管理应包括一个简单的界面，用于显示版本并将全部或部分更改恢复到先前版本。
源控制系统使用的版本的正常分支和更改分组对于维护不同的派生更改并将更改组恢复到先前的分支也非常有用。数据管理和合规性要求通常包括确定每个更改的执行者和时间的方法。
为了支持这些要求，MDM系统应包含用于审核主数据更改的功能。除了保留审核日志之外，MDM系统还应该包括一种简单的方法来查找您正在查找的特定更改。MDM系统每天可以审核数千个更改，因此审核日志的搜索和报告功能非常重要。
除了主数据本身，MDM系统还必须维护数据层次结构——例如，产品的物料清单、销售区域结构、客户的组织结构等。MDM系统捕获这些层次结构很重要，但对于MDM系统而言，能够独立于底层系统修改层次结构也很有用。
例如：
当员工调动到不同的成本中心时，可能会对差旅和费用系统、工资单、时间报告、报告结构和绩效管理产生影响。如果MDM系统管理层次结构，则在单个位置对层次结构进行更改可以将更改同步到所有底层系统。
也可能有理由在MDM系统中维护源系统中不存在的层次结构。
例如：
收入和支出可能需要汇总到任何单一源系统中都不存在的区域或组织结构中。规划和预测可能还需要临时层次结构来计算提议的组织变更的“假设”数字。在许多情况下，还需要历史层次结构将财务信息汇总到过去存在的结构中，但不存在于当前的结构中。
由于这些原因，强大、灵活的层次结构管理功能是MDM系统的重要组成部分。
现在您了解了是什么和为什么，让我们来谈谈有几种不同的方式来考虑让谁参与MDM项目。首先，让我们从高层次看一下三个核心角色：
数据治理：推动定义、要求和解决方案的个人。这些用户帮助管理员知道要创建什么，数据管理员知道要管理什么以及如何管理。数据治理用户向数据管理员指示应如何管理数据，包括这样做的过程，然后让数据管理员对遵循这些要求负责。数据治理用户还向管理员指示在MDM解决方案的实施过程中要创建什么，尤其是从数据匹配和质量的角度来看。数据治理用户还需要维护来自MDM系统的反馈循环，以确保一切都按预期工作。该反馈涵盖了MDM计划的衡量角度，可能包括以下信息：
加入新客户需要多长时间？
这个过程变得更快还是更慢？
与SLA相比，该公司的表现如何？
如果有任何区域在下滑，为什么会发生这种情况？
数据匹配的效果如何？
从数据质量的角度来看，有多少业务规则失败了？
管理员：负责设置和配置解决方案的IT人员。
数据管理员：负责直接在解决方案中修复、清理和管理数据的实地人员。理想情况下，数据管理员来自整个企业的部门，例如财务和营销部门。通常，数据管理员在MDM程序中执行的活动由数据治理用户定义。
其他MDM角色可以包括并因组织/项目类型而异：
角色 | 技能/职责 | 参与程度 |
项目经理 | 拥有数据管理策略和平台。 | 全职 |
专案经理 | 制定和管理项目计划，确保及时交付高质量的成果并报告项目进度。负责风险和问题的管理和升级。 | 全职 |
系统管理员和DBA | 系统管理员：系统管理员倾向于管理域、存储、虚拟化、组策略、DNS、某些网络等事物。基本上，他们往往更加通用。DBA：DBA结合了系统管理的一些技能、开发领域的一些技能以及所使用的数据库平台的专业知识。 | 偶尔的支持 |
开发商 | 开发人员实施自定义SDK和/或工作流解决方案以扩展MDM平台。这可能包括基于Web服务的集成、定制用户界面或利用API或MDM数据的自定义应用程序或流程。 | 偶尔的支持 |
ETL开发人员 | 从源系统（ETL集成）批量加载数据由这些团队成员执行，Profisee提供有关如何在范围内执行实施的培训和指导。 | 偶尔的支持 |
业务分析师/中小企业 | 熟悉与MDM解决方案相关的数据和业务流程的资源。提供对应用程序功能和要求的深入了解，并参与研讨会、审查和测试活动的规划和执行。 | 偶尔的支持 |
数据架构师/数据建模师 | 监督符合组织标准和惯例的企业概念、逻辑和物理数据模型；提供企业数据战略的领导和指导，尤其是与MDM相关的战略；协助制定组织治理实践和标准，并充当业务和IT之间的联络人以阐明数据要求。 | 偶尔的支持 |
最终用户/数据管理员 | 与主数据和/或业务流程交互的个人。这些是MDM系统的业务用户，充当数据的管理员/维护者。 | 直至全日制 |
治理委员会 | 主数据治理委员会(MDGC)是数据相关事务的决策制定机构。MDGC监督数据标准和质量保证的实施，以确保MDM团队和数据管理员正在开发、维护和提供可接受的系统数据以供其他人使用。 | 兼职（例会） |
除了执行和管理MDM策略的角色之外，MDM项目成功的关键之一是关键利益相关者的积极承诺。典型MDM参与的利益相关者包括那些同时代表业务和IT的利益相关者。积极的利益相关者通常包括但不限于以下类型的角色：
业务或IT主管发起人
IT项目负责人
来自受影响业务线的主题专家
数据管理员
IT交付团队
由于MDM利益相关者是在整个组织中定义的，因此确保他们的参与并致力于他们组织的MDM之旅至关重要。根据经验，我们确定了几个“健康”指标，以帮助确定MDM利益相关者的影响：
健康迹象
高管激励与项目结果挂钩
变革管理和培训投资
全职主题专家
合适的赞助商得到适当的参与和资助
指导委员会定期召开会议，决策和行动及时有效
所有适当的利益相关者群体均得到有效代表和参与
不健康的迹象
没有可见的执行发起人
对新思想的抵制
没有可用的“专家”
建议MDM利益相关者的管理层代表组成一个指导委员会，以促进跨职能决策。以下是有效的指导委员会的一些特征：
规模适当——大到足以代表优先利益相关者，但又小到足以快速分析关键信息并做出决策。
专注于快速决策
成为消除组织障碍的工具，而不仅仅是听取项目团队成员报告的例会
不能替代实际赞助
一旦确定了利益相关者，MDM项目章程应包括组建指导委员会。基于运行数百个MDM项目，我们建议以下角色参与指导委员会。请注意，每个角色可能有多个团队成员，或者某些角色或公司的组织结构可能不适用。
角色 | 描述 |
执行发起人 | MDMInitiative的主要预算所有者。该角色通常来自预计将从MDM解决方案中受益的业务线。 |
数据治理主管 | MDM是更大的数据治理策略的组成部分。如果组织拥有数据治理团队，那么它应该是MDM指导委员会的积极参与者。 |
数据管理员 | 负责日常数据管理的团队，包括决定如何在运营或分析系统中呈现数据，通常是指导委员会的一部分。 |
赞助者 | MDM赞助有时驻留在IT组织内部，因为MDM可以被视为IT驱动的工作。组织通常还拥有正式或非正式的业务和IT合作伙伴关系，而IT发起人支持业务主导的计划。无论哪种情况，IT发起人都在MDM项目的成功中发挥着关键作用，并且应该是指导委员会的一部分。 |
组织标准机构 | 如果组织拥有跨职能团队推动整个企业采用通用标准，则该角色可能是MDM指导委员会的最佳候选人。此类标准的示例可能包括IT架构、IT集成、元数据管理等。 |
数据域所有者 | 当公司围绕其业务周期的关键组成部分（例如客户、产品或供应商）进行组织时，可能会有数据域所有者参与指导委员会的决策制定。 |
MDM负责人 | 在某些情况下，MDM负责人负责监督MDM实施的所有业务和IT方面。在这种情况下，该角色是MDM指导委员会的一部分。 |
MDM合作伙伴 | 为了从MDM投资中获得最佳价值，我们鼓励公司将其MDM实施和/或软件合作伙伴纳入指导委员会。MDM合作伙伴提供最佳实践见解以支持指导委员会的决策制定。 |
虽然很容易将主数据管理视为技术问题，但如果不对业务流程和控制进行相应更改，纯技术解决方案可能无法产生令人满意的结果。
联系客服
