主数据治理的目标
主数据治理的目标：在多个异构系统集成应用时，基于主数据以尽量低的成本让各系统实现信息对称，进而让多个系统有机协同起来，实现完整的功能和业务。
主数据的首要任务是实现系统的集成，让同一实体（例如：物料、商品、客户、供应商、组织机构、人员、项目等）在集成应用的多个系统之间形成信息对称，即同一个实体在不同的系统中是一致的。具体的，集成在一起的多个系统在交换信息时，对同一个实体的一笔交易，各系统说的应该是同一件事，以最典型和常用的客商主数据为例，在CRM系统中和ERP系统中都要使用客户数据，每个系统都有自己的一套客户数据，那么对于与A公司的一笔业务，就应该让CRM系统中的A公司与ERP系统中的A公司在数据方面是一致的，即对该笔业务，CRM系统中A公司的一个新销售订单传给ERP系统时，ERP系统能够知道这个销售订单就是ERP系统中A公司的一个新订单，两个系统都知道当前业务对应的客户是A，对这笔交易的客户实体达成了一致，信息对称了，支撑同一业务完整流程的两个系统功能才被实现了集成，业务才能运转起来，这是主数据的核心价值，也是主数据概念出现的本质原因，也是主数据治理的目标。
实现不同系统间的信息对称，以往的常规思路就是建立映射关系，然后系统间数据交互时进行翻译，比如CRM系统中A公司的编码是10123，ERP系统中A公司的编码是C000789，那么CRM向ERP传递数据的时候，就要通过映射把A公司从10123翻译为C000789，这样ERP系统收到数据后才能知道使用本系统中编码为C000789的客户数据开始业务处理。建立映射关系和每次翻译在少量系统时已经非常复杂和麻烦，如果集成的系统较多，通过映射和翻译实现信息对称的方式其代价就太大了，而通过主数据治理，并且应用专业的主数据管理系统能够以尽可能低的成本实现信息对称。
下图即为费控系统与ERP系统集成时主数据应用的示例：
综上，主数据管理是为了实现系统集成时数据和业务的互通互联，保障主数据的唯一性、标准性和共享性的，进而保障业务数据的一致性。而部分项目单纯以数据角度开展主数据治理工作往往会遇到很多困难，所以还是需要回归主数据应用的本质，要从应用系统集成切入，结合数据治理的方法，系统和数据两者相辅相成，才能更顺利的做好主数据相关工作。
另外，稍作补充，在国家标准GB/T 36073-2018数据管理能力成熟度评估模型中关于主数据的定义是“组织中需要跨系统、跨部门进行共享的核心业务实体数据”，其中强调主数据是实体数据，那什么是实体数据呢？实体数据通常说的是“物”，而不是“事”，举例来说，物料、商品、客商（客户、供应商、既是客户同时又是供应商）、组织机构等等这些典型的主数据是都是一些实物；而订单、出库单等这些描述的都是一件事，一般情况下都不作为主数据管理。而本文希望着重说明的是，主数据应该遵循实体的本质，例如很常见的供应商更名，无论供应商更名多少次，但始终是同一家企业，相当于实体无变化，那么始终就应该是一条主数据，而不能因为每次更名就新增一条主数据。（相关阅读：关于客商名称变更时两种财务和数据处理方式的探讨，以及：客商主数据为什么不建议采用18位统一社会信用代码做编码？）
主数据治理的原则
主数据治理的原则：尽量做到“一实体一码”，如：一物一码、一客（商）一码、一人一码等。
为实现主数据治理的目标（即以较低成本实现信息对称），基本原则就是一实体一码，即在企业范围内，一个实体在集成应用的所有系统中，只有对应的一条数据，并且拥有唯一的同一个编码，例如上图中“杭州中电科技有限公司”，在主数据、费控、ERP等所有系统中的编码都是“10002604”，那么系统间传递这家供应商的数据时，都使用10002604这个编码即可，直接、简单、高效。
而如果采用映射的方式解决信息对称问题，同一个实体就会拥有多个编码，而建立映射关系一般有两种方法，第一种是采用专用的中间表记录多个系统间的映射关系；第二种是在本系统内编制自己特有的编码，额外再增加一个字段记录相关其他系统的对应编码（也可能是主数据编码），在系统内使用自己的特有编码，当与外部系统交互时再使用额外记录的外部系统编码。无论哪种方式，因为没有做到一实体只有一个编码，就会带来额外的存储、保持对应关系、翻译等一系列成本和风险，复杂和低效。
哪怕第二种情况通过增设字段额外记录的是主数据编码，但实现外部交互时仍然需要翻译等处理，因为有悖于原则的，所以自然就没有完全达到主数据治理的目的和效果。只有一种例外，就是有些系统不能被外部赋码，或者在系统功能上只能使用自己的编码体系，因为有这类“硬伤”，也就只能妥协，而除此之外，都应该坚定的坚持“一实体一码”的原则。
现在还有一种情况，就是对此前没有应用主数据，那么对已经使用多年的一系列应用系统做主数据治理的成本确实非常大，类似于旧城改造，不能推倒重来，必须兼顾以往。因为有的时候采用新的主数据编码确实太复杂了，部分项目就妥协了，利用一些数据工具（例如：数据中台等）在后期，基于映射关系对数据做清洗，通过数据工具再实现信息对称，无论在业务过程中清洗和翻译，还是事后做清洗和翻译用于数据分析（此处需要强调的是，主数据的主要价值不是用于数据的查询和分析，而是本身作为业务实体数据的一部分参与业务处理）等，这些情况都不能算主数据治理。主数据治理是在源头开展的活动，只有在开始时实现标准化和唯一性，才能享受主数据治理后的低成本信息对称，一旦涉及映射和翻译，主数据治理都是没有做到位的，但面对现实，有时也确实很难完全避免映射，那么虽然有时候不得不妥协，但原则是要尽可能遵循的。
主数据治理的边界
主数据治理的边界：治理工作的边界是直到让主数据消费系统能够正常使用主数据为止，而不是局限于主数据管理系统本身的软件功能范围。
主数据的应用，一定是在多系统集成应用场景下，多系统集成就意味着多个团队的协作，就涉及标准的制订与遵循，就带来了接口开发、系统改造、数据清洗等工作量，特别是在部分情况下，工作量或许可左可右，即有些工作主数据管理系统（MDM）可以做，主数据产生的源系统或者主数据的消费系统（使用主数据的应用系统）做也行。但因为主数据标准的控制是由MDM系统掌握的，那么在主数据管理维度上，各系统应该以MDM系统为核心开展集成，即在MDM提供数据标准化和唯一性逻辑控制的基础上，各应用系统应以MDM为准开展工作。
这样就对主数据管理系统的软件功能本身和应用这套系统的主数据管理团队提出了较高的要求，主数据管理团队（厂商）应对应用系统功能和业务有一定程度的理解和掌握，能指导相关系统的团队应用主数据，否则很难与应用系统厂商共同制订主数据标准，很难完成主数据的逻辑控制，很难满足应用系统对主数据的需求。特别是也很难达成对主数据的全面管理，各个应用系统厂商往往是站在本系统和业务的角度上看待主数据，而主数据往往会被多个系统使用，那么主数据管理团队必须理解主数据对应业务实体的属性，必须站在集成在一起的整套系统的角度上审视主数据的产生和消费的多个业务场景和系统功能，才能把握主数据应用（管理、接收、推送等）逻辑的合理性，才能真正对主数据实现管理。
那么由此就对主数据管理团队的工作边界在哪里就提出了问题，或者说，主数据管理团队的工作究竟做到什么程度才行？简而言之，就是直到让主数据消费系统能够正常使用主数据为止，即绝对不是仅仅把主数据成功推送到消费系统就结束，而是要满足消费系统的全面需求才行，例如主数据消费系统获取到的主数据一定是标准化和唯一性的；主数据发生变更后，消费系统可以及时准确的获得最新信息；主数据消费系统的个性化需求可以得到MDM的支持等等。总的来说，主数据管理工作是结果导向的。
最后再补充一下，现代主数据治理的方法论、软件产品、最佳实践都已比较成熟和丰富，MDM的应用似乎不太困难，但因为主数据具有业务属性，而业务本身往往都是很复杂的，而且各种异构系统也是非常复杂的，由此，主数据治理仍然是非常具有挑战的，需要重视，需要专业的软件和团队，并且不能完全依赖于MDM原厂，用户需要形成主数据管理能力，因为主数据治理工作是动态持续的（业务和数据是变化的、应用系统的功能变化、不断集成新的系统等），用户需要有能力运用主数据。
文章来源：猫说信息化微信公众号