为什么你的 MDM 项目又烂尾了

见过太多这样的场景：花几百万买了 Informatica MDM 或者 SAP MDG，部署上线三个月，数据质量报告依然一片红。业务部门抱怨"系统里的客户数据还是对不上"，IT 部门委屈"平台都买了还要怎样"。

问题出在哪？MDM 从来不是一个产品交付项目，而是一个数据治理工程。 买平台只是解决了工具层面的问题，但你需要的是一整套从调研、标准制定、清洗执行到持续运营的完整方法论。没有流程，平台就是个空壳。

下面这六步，是我在几个中大型 MDM 项目中反复验证过的落地路径。不保证万能，但至少能让你少踩几个坑。

第一步：数据现状调研

别急着上平台。第一步永远是搞清楚你现在的数据长什么样、在哪里、谁在管。

调研三件套

1. 数据资产盘点 — 遍历所有业务系统，列出涉及主数据的表、字段、记录量
2. 数据流向梳理 — 数据从哪来、到哪去、中间经过了哪些转换
3. 数据 Owner 确认 — 每个数据域的业务负责人是谁，出了问题找谁

常见数据域示例

调研阶段的产出物应该是一份完整的数据现状报告，包含每个域的数据质量评分（完整性、一致性、唯一性、时效性）以及问题清单。这份报告是后续所有步骤的 baseline。

第二步：定义主数据范围和标准

不是所有数据都是主数据。主数据的核心特征是：跨系统共享、变化频率低、业务价值高。

哪些实体该纳入主数据

• 客户（Customer） — 几乎所有业务系统的核心引用
• 产品（Product） — 从研发到销售到售后的全链路依赖
• 供应商（Supplier） — 采购、财务、质量管理的交汇点
• 组织（Organization） — 权限、审批、报表维度的基础
• 员工（Employee） — HR、OA、IT 权限的关联枢纽

编码标准

编码是主数据的身份证，定了就别轻易改。核心原则：

• 唯一性 — 一个实体一个码，绝不允许一物多码
• 可扩展性 — 编码规则要能支撑未来 5-10 年的增长
• 无含义 vs 有含义 — 建议核心编码用无含义流水号（避免业务含义变化导致编码失效），辅助属性用分类码

1
2
3
4

示例编码规则：
客户编码：CUST + 8位流水号 → CUST00001234
产品编码：品类码(2位) + 品牌码(2位) + 流水号(6位) → AB-CD-000123
供应商编码：SUPP + 8位流水号 → SUPP00005678

命名规范

• 客户名称统一使用工商注册全称，别名字段单独存储
• 产品名称遵循"品牌 + 品类 + 规格 + 型号"结构
• 地址字段拆分到省、市、区、街道、门牌号五级，别塞一个字符串

第三步：数据清洗规则和执行

这一步是脏活累活，但没有捷径。

清洗三板斧

1. 去重（Deduplication）

基于匹配规则识别重复记录。匹配策略通常是分层级的：

• 精确匹配：统一社会信用代码 / 身份证号完全一致
• 模糊匹配：名称相似度 > 90%（编辑距离 / Jaro-Winkler）
• 规则匹配：手机号 + 地址组合一致

2. 标准化（Standardization）

3. 补全（Enrichment）

缺失字段通过权威数据源补全。比如用天眼查 API 补全企业工商信息，用国家统计局数据补全行政区划编码。

清洗执行架构

建议用 ETL 管道做批量清洗，配合规则引擎做增量清洗：

1
2
3

源系统 → 数据抽取 → 规则引擎（去重+标准化+补全）→ 清洗结果审核 → 入库
                                    ↓
                              人工审核队列（低置信度记录）

低置信度的匹配结果（比如名称相似度在 80%-90% 之间的）不要自动合并，放进人工审核队列让 Data Steward 确认。

第四步：构建黄金记录（Golden Record）

黄金记录是主数据管理的核心产出——每个实体在各系统中的最佳版本合并成一条权威记录。

合并规则与冲突解决

当多个系统对同一实体有不同数据时，需要 Survivorship 规则来决定谁的数据"活下来"：

合并策略

1
2
3
4
5
6
7
8
9

Trust Score 模型：
黄金记录.字段值 = argmax(各源系统字段值 × 源系统信任权重 × 时效衰减因子)

信任权重示例：
- 工商信息接口：1.0
- ERP：0.9
- CRM：0.8
- 电商平台：0.7
- 手工录入：0.5

黄金记录生成后不是终点。你需要维护一个完整的交叉引用表（Cross Reference），记录黄金记录和各个源系统记录的映射关系，这是后续数据分发的基础。

第五步：分发与同步

主数据管理平台的价值在于让全公司用上同一套干净数据。分发机制的设计直接影响数据一致性的时效。

Push vs Pull

事件驱动架构

推荐的做法是把主数据变更发布为领域事件：

1
2
3
4
5
6
7
8

{
  "eventType": "CUSTOMER_UPDATED",
  "entityId": "CUST00001234",
  "timestamp": "2026-06-18T14:30:00+08:00",
  "changedFields": ["phone", "address"],
  "goldenRecord": { ... },
  "sourceSystem": "CRM"
}

下游系统订阅这些事件，按需消费。关键是要做好幂等处理和顺序保证（同一实体的变更事件必须按序消费）。

批量同步兜底

即使有事件驱动，仍然需要一个每日全量对账机制：比对主数据平台和各源系统的记录数和关键字段，发现漂移及时告警。

第六步：持续治理与质量监控

MDM 上线只是开始。数据质量会随时间退化，没有持续治理就会回到原点。

质量看板

核心指标：

• 完整性 — 必填字段的填充率（目标 > 98%）
• 唯一性 — 疑似重复记录数 / 总记录数（目标 < 0.5%）
• 一致性 — 跨系统字段一致率（目标 > 95%）
• 时效性 — 数据平均更新延迟（目标 < 24h）
• 合规性 — 编码规范符合率（目标 100%）

每周出一份质量报告，每月做一次根因分析。不要只看分数，要看趋势和根因。

Data Steward 机制

每个数据域至少指定一个 Data Steward（数据管家），职责包括：

• 审核新增和变更请求
• 处理人工审核队列中的低置信度匹配
• 制定和更新数据质量规则
• 推动源系统的数据质量改进

Data Steward 不是 IT 岗位，是业务岗位。最好由业务部门的资深人员兼任，IT 提供工具和培训支持。

变更管理

主数据的任何变更都应该走流程：

1

变更申请 → 影响评估 → 审批 → 执行 → 验证 → 通知下游

特别是编码规则和命名规范的变更，影响面巨大，必须经过数据治理委员会审批。

常见踩坑清单

MDM 是一个 Program，不是一个 Project

最后说一句大实话：主数据管理永远不会"做完"。它不像一个 ERP 实施项目，有个明确的上线日期就可以开香槟。MDM 更像是一种组织能力——你的企业能不能持续产出高质量的基础数据。

把 MDM 当 Project 做的公司，通常会在项目验收后的 12 个月内回到起点。把 MDM 当 Program 做的公司，会建立持续的治理机制、专职的团队、不断优化的规则，让数据质量成为业务增长的加速器而不是绊脚石。

六步法不是瀑布式的走一遍就结束。它是一个循环：调研 → 标准 → 清洗 → 合并 → 分发 → 治理 → 再调研。每一轮循环，你的数据质量都会上一个台阶。

关键是：先动起来，从最小可行域开始，快速验证价值，再逐步扩展。 别等到所有条件都具备了才启动——那一天永远不会来。