主数据管理落地六步法：从数据现状调研到清洗标准全流程拆解
为什么你的 MDM 项目又烂尾了
见过太多这样的场景：花几百万买了 Informatica MDM 或者 SAP MDG，部署上线三个月，数据质量报告依然一片红。业务部门抱怨"系统里的客户数据还是对不上"，IT 部门委屈"平台都买了还要怎样"。
问题出在哪？MDM 从来不是一个产品交付项目，而是一个数据治理工程。 买平台只是解决了工具层面的问题，但你需要的是一整套从调研、标准制定、清洗执行到持续运营的完整方法论。没有流程，平台就是个空壳。
下面这六步，是我在几个中大型 MDM 项目中反复验证过的落地路径。不保证万能，但至少能让你少踩几个坑。
---
第一步：数据现状调研
别急着上平台。第一步永远是搞清楚你现在的数据长什么样、在哪里、谁在管。
调研三件套
1. 数据资产盘点 — 遍历所有业务系统，列出涉及主数据的表、字段、记录量
2. 数据流向梳理 — 数据从哪来、到哪去、中间经过了哪些转换
3. 数据 Owner 确认 — 每个数据域的业务负责人是谁，出了问题找谁
常见数据域示例
| 数据域 | 典型系统 | 关键字段 | 常见 Owner 部门 |
|--------|---------|---------|----------------|
| 客户 | CRM、ERP、电商后台 | 客户编码、名称、统一社会信用代码 | 销售部 / 客户管理部 |
| 产品 | PLM、ERP、WMS | SKU、品名、规格、分类编码 | 产品部 / 供应链 |
| 供应商 | SRM、ERP、采购系统 | 供应商编码、名称、银行账户 | 采购部 |
| 组织架构 | HR 系统、OA | 部门编码、部门名称、上级部门 | 人力资源部 |
| 物料 | ERP、MES | 物料编码、计量单位、BOM 层级 | 生产 / 仓储 |
调研阶段的产出物应该是一份完整的数据现状报告，包含每个域的数据质量评分（完整性、一致性、唯一性、时效性）以及问题清单。这份报告是后续所有步骤的 baseline。
---
第二步：定义主数据范围和标准
不是所有数据都是主数据。主数据的核心特征是：跨系统共享、变化频率低、业务价值高。
哪些实体该纳入主数据
编码标准
编码是主数据的身份证，定了就别轻易改。核心原则：
示例编码规则：
客户编码：CUST + 8位流水号 → CUST00001234
产品编码：品类码(2位) + 品牌码(2位) + 流水号(6位) → AB-CD-000123
供应商编码：SUPP + 8位流水号 → SUPP00005678
命名规范
---
第三步：数据清洗规则和执行
这一步是脏活累活，但没有捷径。
清洗三板斧
1. 去重（Deduplication）
基于匹配规则识别重复记录。匹配策略通常是分层级的：
2. 标准化（Standardization）
| 清洗前 ❌ | 清洗后 ✅ | 规则 |
|-----------|-----------|------|
| 北京市朝阳区建国路88号 | 北京市/朝阳区/建国路/88号 | 地址五级拆分 |
| 阿里巴巴集团 | 阿里巴巴集团控股有限公司 | 工商注册全称映射 |
| 13812345678 / 86-138-1234-5678 | +86-13812345678 | 手机号 E.164 格式 |
| 深圳腾讯 | 深圳市腾讯计算机系统有限公司 | 简称→全称映射表 |
| kg / 公斤 / KG | KG | 计量单位统一 |
3. 补全（Enrichment）
缺失字段通过权威数据源补全。比如用天眼查 API 补全企业工商信息，用国家统计局数据补全行政区划编码。
清洗执行架构
建议用 ETL 管道做批量清洗，配合规则引擎做增量清洗：
源系统 → 数据抽取 → 规则引擎（去重+标准化+补全）→ 清洗结果审核 → 入库
↓
人工审核队列（低置信度记录）
低置信度的匹配结果（比如名称相似度在 80%-90% 之间的）不要自动合并，放进人工审核队列让 Data Steward 确认。
---
第四步：构建黄金记录（Golden Record）
黄金记录是主数据管理的核心产出——每个实体在各系统中的最佳版本合并成一条权威记录。
合并规则与冲突解决
当多个系统对同一实体有不同数据时，需要 Survivorship 规则来决定谁的数据"活下来"：
| 字段 | 优先数据源 | 原因 |
|------|-----------|------|
| 客户名称 | CRM | CRM 由销售维护，更新最及时 |
| 统一社会信用代码 | 工商数据 | 法定权威来源 |
| 联系电话 | CRM（最近更新时间最晚的） | 时效性优先 |
| 信用额度 | ERP 财务模块 | 财务数据以 ERP 为准 |
| 收货地址 | 电商平台（最近订单） | 业务场景决定 |
合并策略
Trust Score 模型：
黄金记录.字段值 = argmax(各源系统字段值 × 源系统信任权重 × 时效衰减因子)
信任权重示例：
- 工商信息接口：1.0
- ERP：0.9
- CRM：0.8
- 电商平台：0.7
- 手工录入：0.5
黄金记录生成后不是终点。你需要维护一个完整的交叉引用表（Cross Reference），记录黄金记录和各个源系统记录的映射关系，这是后续数据分发的基础。
---
第五步：分发与同步
主数据管理平台的价值在于让全公司用上同一套干净数据。分发机制的设计直接影响数据一致性的时效。
Push vs Pull
| 模式 | 适用场景 | 实现方式 | 优缺点 |
|------|---------|---------|--------|
| Push（推送） | 实时性要求高 | 消息队列（Kafka/RabbitMQ）+ 事件驱动 | 实时性好，但下游系统需要改造 |
| Pull（拉取） | 批量场景 | 下游系统定时调用 API 或读取共享表 | 实现简单，但有延迟 |
| 混合 | 大多数企业 | 变更事件 Push + 全量同步 Pull | 兼顾实时和兜底 |
事件驱动架构
推荐的做法是把主数据变更发布为领域事件：
{
"eventType": "CUSTOMER_UPDATED",
"entityId": "CUST00001234",
"timestamp": "2026-06-18T14:30:00+08:00",
"changedFields": ["phone", "address"],
"goldenRecord": { ... },
"sourceSystem": "CRM"
}
下游系统订阅这些事件，按需消费。关键是要做好幂等处理和顺序保证（同一实体的变更事件必须按序消费）。
批量同步兜底
即使有事件驱动，仍然需要一个每日全量对账机制：比对主数据平台和各源系统的记录数和关键字段，发现漂移及时告警。
---
第六步：持续治理与质量监控
MDM 上线只是开始。数据质量会随时间退化，没有持续治理就会回到原点。
质量看板
核心指标：
每周出一份质量报告，每月做一次根因分析。不要只看分数，要看趋势和根因。
Data Steward 机制
每个数据域至少指定一个 Data Steward（数据管家），职责包括：
Data Steward 不是 IT 岗位，是业务岗位。最好由业务部门的资深人员兼任，IT 提供工具和培训支持。
变更管理
主数据的任何变更都应该走流程：
变更申请 → 影响评估 → 审批 → 执行 → 验证 → 通知下游
特别是编码规则和命名规范的变更，影响面巨大，必须经过数据治理委员会审批。
---
常见踩坑清单
| 坑 | 现象 | 根因 | 解法 |
|----|------|------|------|
| 范围失控 | 第一期就想把所有域都做完 | 没有 MVP 思维 | 先做一个域（建议从客户开始），跑通流程再扩展 |
| 业务不参与 | IT 部门自嗨，业务部门不配合 | 没有高层 Sponsor | 必须有一个 VP 级别的治理委员会主席 |
| 标准不落地 | 编码规范写了没人用 | 缺乏强制执行机制 | 在系统入口做校验，不合规的数据根本存不进去 |
| 过度依赖工具 | 以为买了平台就万事大吉 | 忽视了流程和人的因素 | 工具只占 30%，流程和治理占 70% |
| 清洗只做一次 | 上线时数据很干净，半年后又脏了 | 没有增量清洗机制 | 规则引擎嵌入日常数据流，实时清洗 |
| 缺少度量 | 不知道数据质量是变好了还是变差了 | 没有建立质量指标体系 | 从第一天就建立看板和基线 |
---
MDM 是一个 Program，不是一个 Project
最后说一句大实话：主数据管理永远不会"做完"。它不像一个 ERP 实施项目，有个明确的上线日期就可以开香槟。MDM 更像是一种组织能力——你的企业能不能持续产出高质量的基础数据。
把 MDM 当 Project 做的公司，通常会在项目验收后的 12 个月内回到起点。把 MDM 当 Program 做的公司，会建立持续的治理机制、专职的团队、不断优化的规则，让数据质量成为业务增长的加速器而不是绊脚石。
六步法不是瀑布式的走一遍就结束。它是一个循环：调研 → 标准 → 清洗 → 合并 → 分发 → 治理 → 再调研。每一轮循环，你的数据质量都会上一个台阶。
关键是：先动起来，从最小可行域开始，快速验证价值，再逐步扩展。 别等到所有条件都具备了才启动——那一天永远不会来。
原文链接：https://wenyiblog.top/2026/06/master-data-management-six-steps/
首发于文艺技术笔记（wenyiblog.top），转载请注明出处。
浙公网安备 33010602011771号