主数据管理

主数据管理（Master Data Management，MDM）是对多个业务系统重复描述的关键实体进行识别、协调、治理和共享的能力。常见主数据对象包括客户、供应商、产品、员工、地点和组织；它们不同于每天产生的订单、支付、浏览事件等交易数据，也不同于用于分类的参考数据代码表。某家公司在CRM里可能是“青岚科技”，在开票系统里是“青岚科技有限公司”，在供应商门户里又有不同编号。MDM要识别这些记录如何代表同一实体，哪些属性来源可信，以及经核验后的主记录如何供其他系统使用。范围应围绕业务对象、属性和使用流程明确定义，不能把所有数据库集中到一个平台就称为主数据治理。

参考数据是用于解释、分类或限制值的集合，例如国家代码、币种、商品类别、状态枚举；主数据则描述业务中实际存在的对象，如某个客户实体、供应商或商品型号。参考数据可被主数据字段引用，主数据也可被交易数据引用。若把“已批准”“待审核”当客户对象属性，它属于主数据字段；“待审核”状态的代码及定义则属于参考数据。两者治理周期、负责人和唯一性约束往往不同。主数据通常要处理来源对齐、重复实体、属性权威性和关系网络；参考数据常需维护代码定义、有效期、层级和跨分类映射。分清二者有助于避免状态代码被误当真实客户、也避免每个交易系统自行创造含义不同的分类值。

源记录是某个系统对实体的一种描述，主数据实体则是经规则判断后关联的一个或多个记录所构成的业务视图。实体解析可以使用稳定标识、名称、地址、电话或其他字段，先标准化再计算匹配可能性。名称相同不必然是同一组织，同一企业更名、搬迁或分支机构也可能拥有不同身份。自动匹配适用于证据较强的场景，边界记录应进入人工复核，并保存匹配理由和信心信息。匹配阈值太宽会把不同客户误合并，太严则会留下重复记录；参数需按实体类型和错误代价验证，不能照搬个人客户的算法到商品、供应商或机构数据。

“黄金记录”常指经协调后供下游引用的可信主视图，并不意味着每个字段都来自同一系统，也不表示这条记录永远正确。对不同属性可设来源优先级、完整性要求、最近验证时间、人工批准状态或业务规则。例如注册地址以企业登记核验记录为主，显示名称可采用经品牌确认的名称，客服电话则优先使用最近由客户验证的数据。字段发生冲突时，系统按生存规则选择、合并或提交数据管家复核。规则要说明何时适用、依据是什么、如何回退，以及当两个可信来源冲突时怎么办。保留来源记录和选值理由，能让主视图被纠正时追溯和重新计算。

MDM可采用不同控制模式。集中式/汇总式方案把来源记录复制进主数据平台，在其中清理和发布统一记录；注册式方案主要维护身份链接、引用和索引，让权威属性仍保存在源系统；共存式方案允许主数据平台与部分源系统共同维护不同字段。现实架构常为组合，选择受更新延迟、系统改造成本、业务实时性、审计和数据所有权限制。若中央系统变成唯一写入入口，须确保源系统能够接收更改、权限同步及故障回退；若采用注册模式，下游仍需处理跨源查询和版本一致性。无需为“单一事实来源”这一口号强行迁移全部字段，应逐域设计明确的主责与传播方式。

主数据模型定义对象类型、属性、标识、关系和约束。产品可以有系列、型号、变体、包装层级和替换件；企业客户可以关联母公司、分支、经销商、付款主体和交付地点；个人可以在不同关系场景担任联系人、采购人或服务对象。模型应区分独立实体与实体的角色关系，写明生效时间和来源。父子关系变化、并购、拆分、地址迁移都可能影响实体结构，不能只改名称字段了事。稳定内部标识帮助系统跟随身份变化，外部编号则需记录发行组织和有效期。模型版本变更时需评估接口映射、历史记录和分析口径。

主数据管理不是技术部门单独完成的去重项目。业务数据所有者决定定义和策略，数据管家处理日常例外，源系统负责人保障输入与接口，架构人员管理标识和集成，实际用户反馈匹配错误及缺失关系。角色可按数据域分配，不同字段可拥有不同责任人。新增实体、合并、拆分、关键字段更改和撤销都应有清楚的批准与审计路径。对于自动流程，建议设置疑似重复队列、可解释理由、人工裁决结果以及撤销或拆分机制。谁可以改记录、谁能改匹配规则、谁能发布下游主视图，权限不应混为一谈。目标是让责任与修改能力相称，而不是增加无目的审批。

主数据的质量问题可能来自重复、属性缺失、过期、来源不一致或关联错误。通过精确匹配（例如同一受信外部标识）和模糊匹配（名称相似、地址接近）分层，可对自动合并风险进行控制。一个评分不是事实证明；来源地址相同也可能是共享办公地点，品牌名相似也可能属于不同法人。应将“确定匹配”“疑似匹配”“确认不同”分别表示，支持人工查看证据并记录决定。合并后如果发现误判，拆分流程要恢复来源记录、重建下游身份关联并告知订阅系统；没有解合并方案的自动合并对客户、结算和隐私处理可能造成连锁影响。

主数据平台通常从CRM、ERP、供应链、客服或目录系统接收数据，按规则标准化和匹配，再通过API、事件、文件或数据产品将标识、属性及变更传播给消费者。接口需约定主键、字段含义、消息顺序、幂等、删除语义、冲突处置和数据时效。单纯导出“最新主视图”可能使下游丢失字段来源与有效期限；只发布差异消息则要求消费者正确处理断点恢复和版本号。数据目录可登记主数据集的位置、负责人、更新频率和接口，但它描述资产而非运行时替代主数据服务。系统设计须考虑延迟、重试、重复事件、下游缓存和回滚，保证消费者知道主记录处于哪个版本。

客户和员工主数据可能包含个人信息，应遵照组织的数据分类、最少访问和留存要求。建立统一身份视图并不意味着所有下游用户都应看到全部属性；可通过用途授权、字段级权限、脱敏和访问审计控制使用。跨境数据流还需明确哪些记录可在哪些地区处理、下游复制范围、缓存期限和责任方。主数据的统一标识可提高关联能力，也可能提升识别敏感个人的可能性，因此安全设计要与实体解析同时规划。数据质量高并不自动代表采集、共享或跨境处理合法；具体依据和处理规则应由组织相关责任岗位结合适用制度评估。

可从客户、产品或供应商中选一个痛点明确的数据域开始。先确认关键对象、业务词汇、源系统、标识现状、常见重复类型和下游消费者，再设定匹配、字段生存、例外处理和通知策略。试点应覆盖正常记录与边缘冲突样本，验证自动决策及误匹配修复。可观察重复率、匹配精确率抽查、未决队列龄期、关键字段来源覆盖、源系统同步时间、误合并导致的工单和跨系统关联成功率。指标应按域和错误影响分层，避免仅以合并数量衡量成功。MDM的长期效果来自更清晰的身份关系、稳定的数据责任和可逆的变更流程，而非一次性压缩记录数。

内部主标识应保持稳定，不宜直接由易变名称、地区或部门编码拼接而成。客户可能更名、合并、换地址，供应商可能更换外部注册号；系统需要保留原有引用及身份变更历史。外部标识应连同标识类型、发行机构、有效期和验证状态保存，不能把不同机构发出的相同字符串视作相同身份。对跨境实体，登记名称、商业名称、分支机构与集团母公司可能分别对应不同实体层级。数据模型应说明关联方式及证据，而非将全部别名堆进单一名称字段。多个系统的旧编号可通过交叉引用表映射到统一标识，使交易、客服和分析能够在不丢失源系统历史的前提下指向同一主视图。

主数据域可从一个高频对象逐步扩展到相邻对象，并在扩展时保留已有标识与映射。客户域稳定后，团队可能再管理联系地址、法人实体、渠道伙伴或产品目录；扩展并不意味着把客户联系人与公司合并成同一种实体。记录类型、身份规则和生命周期各有差异，需沿用共同的审计与权限原则，同时为新对象单独验证匹配条件。跨域关系可帮助识别客户采购了哪些产品、由哪些地点履约，却应避免把关系推断成未经确认的所有权或资格事实。先在有限范围验证、再增加数据域，有助于让治理角色和消费者跟上变化。

Microsoft Learn《Microsoft Purview 中的主数据管理》描述与合作MDM方案的元数据协作流程；IBM《主数据记录匹配算法》说明标准化、分桶、比较和实体匹配步骤；IBM《生存规则的决策标准》讨论来源可信度、标准和数据时效等选择因素。来源：https://learn.microsoft.com/en-us/purview/data-governance-master-data-management ；https://www.ibm.com/docs/en/ws-and-kc?topic=data-matching-algorithms-in-match-360 ；https://www.ibm.com/docs/en/imdm/12.0.0?topic=data-deciding-criteria-survivorship。 IBM《InfoSphere MDM 技术》区分虚拟、物理与混合MDM能力，并说明注册式、集中式和共存式实现风格。来源：https://www.ibm.com/docs/en/imdm/14.0.0?topic=overview-infosphere-mdm-technologies。

84 container