数据治理是过去几年最容易被包装、也最容易失败的企业数字化品类。原因很简单：它的成果不可见。系统上线能看见界面，治理做完看见的还是那些报表，只是数字终于对上了。
所以甲方在采购时的第一道防线，就是问「怎么验收」。答不上来的服务商，基本可以排除。
先划范围，否则一定失控
数据治理的范围可以按三层界定：
- 数据层。治理哪些系统、哪些主题域、多少张表、多少主数据对象。这一层决定工作量。
- 规则层。数据标准、编码规则、指标口径、质量规则。这一层决定成果质量。
- 组织层。谁负责、谁审批、谁维护，以及制度与流程。这一层决定成果能否持续。
多数项目只做前两层，交付后半年数据又乱了。第三层不做，治理就是一次性清洗。
六类质量指标，要能量化
| 质量维度 | 含义 | 量化方式 | 常见问题 |
|---|---|---|---|
| 完整性 | 关键字段是否为空 | 空值率 = 空值记录数 / 总记录数 | 空值率统计口径不一致 |
| 准确性 | 数据是否与真实情况一致 | 抽样核对一致率 | 抽样样本不具代表性 |
| 一致性 | 同一对象在不同系统中是否一致 | 跨系统比对不一致记录占比 | 主数据未统一，永远对不上 |
| 及时性 | 数据从产生到可用的延迟 | 平均延迟时长、超时记录占比 | 只统计平均，掩盖长尾 |
| 唯一性 | 是否存在重复记录 | 重复率 = 重复记录数 / 总记录数 | 重复判定规则不明确 |
| 有效性 | 是否符合业务规则与值域 | 违规记录占比 | 规则库未随业务更新 |
六个维度都可以量化，也都可以写进验收条款。关键是在项目开始前就确定基线值——治理前的空值率是多少，治理后的目标是多少。没有基线，就无法证明改善。
落地顺序，主数据优先
合理的顺序是：主数据 → 指标口径 → 数据质量 → 数据资产目录 → 数据服务。原因是从「对不上」到「用得上」是一条因果链。
主数据（客户、供应商、物料、组织、人员）不统一，所有跨系统报表都会打架；指标口径不统一，同一张报表在不同部门有不同数字；质量问题不解决，资产目录就是一堆脏数据的索引。
反过来做——先上中台、先建目录、再做治理——是行业里最常见的失败路径。看起来很热闹，实际没人用。
组织层不落地，治理成果会反弹
制度写得再漂亮，没有明确的责任人就不会被执行。落地的关键动作有三个：指定每个主题域的数据 Owner、建立跨部门的数据管理例会、把数据质量纳入部门考核。
第二项最容易被跳过。数据问题从来不是技术问题，而是部门之间的口径分歧。没有例会机制，分歧会一直悬着，直到下一次报表打架。
第三项最难，但最有效。质量指标一旦与考核挂钩，业务部门才会在录入环节就把数据当回事，而不是等治理团队来清洗。
可验收的交付物清单
- 数据标准文档（字段、类型、值域、编码规则）；
- 主数据清单与清洗记录（治理前后对比）；
- 指标口径手册（含计算逻辑、数据来源、责任人）；
- 质量规则库与监控报表（可定时运行）；
- 数据资产目录（可检索、有责任人、有更新记录）；
- 管理制度与岗位职责（含考核办法）。
六项都能验收，也都能在合同中约定交付标准。把这份清单写进方案，客户对「你懂不懂」的判断会立刻不同。
中台不是必选项
这一点很少有人主动说：数据中台适合多业务线、数据量大、复用需求高的组织。对于系统不多、数据量有限的企业，先把主数据与报表口径理顺，收益远高于建中台。
敢说这句话的服务商，通常更值得信任。因为它证明你考虑的是客户的问题，而不是自己的产品。
相邻细分领域的白皮书
本行业的二级指南
白皮书矩阵总纲
本行业分类页：查看该领域全部内容。
常见问题
数据治理项目一般多久？
取决于范围。单一主题域的主数据治理通常 2–4 个月；覆盖多系统、多主题的全域治理常在 6–12 个月，并需持续运营。
DCMM 认证有必要做吗？
看用途。它对标数据管理能力成熟度，有助于梳理体系与对外证明能力，但认证本身不等于治理落地，需与实际问题结合。
数据中台一定要建吗？
不一定。业务线多、数据复用需求强时价值明显；系统少、数据量有限时，先做标准与口径更划算。
治理成果怎么持续？
靠组织与制度。需明确数据 Owner、建立质量监控与考核机制，否则交付后半年数据会重新劣化。
边界声明：本白皮书说明数据治理的范围界定与验收方法，不构成技术方案或实施承诺。治理范围、质量指标与验收标准应结合客户实际数据状况确定，涉及个人信息与重要数据的处理须符合相关法律法规要求。