数据治理：AI 之前必须先做的那件事
数据治理最容易做成一个永远做不完的工程——三年过去了，还在"梳理主数据"。我们的做法相反：只治理 AI 项目用得上的那部分，在项目边界内补齐口径、质量与追溯，8-16 周能看到结果。
什么样的数据问题会让 AI 项目必败
同一指标三个数
生产说良率 96%，质量说 94%，财务按 92% 核算成本。模型学哪个？答案是不管学哪个，另外两个部门都不认。
关键字段长期缺失
设备参数靠人工抄录，交接班漏记；来料批次号时有时无。缺失超过一定比例，模型输出的不是预测，是臆测。
数据之间连不起来
工单里有设备号但没有产品批次，批次在 ERP 里但没记模具号。想做归因，先得把三条链拼起来。
这三类问题里，口径不一致最难解决，因为它不是技术问题，是权责问题——谁的数字被认定为"官方数字"，背后是部门话语权。
最小治理集：只补用得上的四样
不是不要治理，是不做与当前项目无关的治理。
| 治理项 | 做到什么程度 | 不做什么 |
|---|---|---|
| 主数据 | 只统一项目涉及的那几类实体：设备、产品、物料、工序 | 不追求全集团主数据平台 |
| 指标口径 | 把项目用到的指标定义、计算公式、取数来源写成文档并签字确认 | 不重写整个指标体系 |
| 质量规则 | 只对关键字段设校验：非空、值域、逻辑一致性 | 不做全量数据质量监控 |
| 追溯链路 | 把"设备—工艺—批次—产品"这条链打通到可查询 | 不建全公司数据血缘图谱 |
四样做完，通常 8-16 周。范围看似小，但它解决的是"这个项目能不能成"，而不是"公司的数据资产是否完美"。
"先治理三年再上 AI"，通常三年后还在治理
大治理的逻辑听起来很对：地基不牢，盖什么都会塌。但现实里的三个问题几乎必然出现：
- 没有业务压力，治理就没有优先级。数据治理不直接产生收入，一旦和交付冲突，永远排在后面。
- 范围无法收敛。"全公司数据资产梳理"是一个边界无限的任务，做三年也做不完。
- 做完也不知道有没有用。没有具体应用场景验证，无法判断治理是否到位。
所以我们的顺序是反的：先用一个具体项目把治理范围逼出来，做完这个项目，那部分数据自然就干净了。多个项目累积，才是真实可用的数据资产。
和业务项目同时推进，而不是先做完
第 1-2 周：定边界
从目标项目倒推，列出这个项目需要哪些数据、哪些字段、哪些口径。范围由项目决定，不由"应该治理什么"决定。
第 3-6 周：补口径与主数据
把关键指标的定义拉齐，涉及部门签字确认。主数据只做项目涉及的四类实体。
第 7-10 周：建质量规则
对关键字段设校验，把历史数据跑一遍看脏数据分布，该修的修、该标注的标注。
第 11-16 周：建机制
指定数据责任人、定更新频率、写入运维手册。没有责任人的治理，三个月后一定回退。
最后一步最容易被省略，也是治理能不能持续的唯一分水岭。交付时我们会明确写出每个字段谁负责，而不是交给"IT 部门统一管"。
怎么判断治理到位了
| 交付物 | 验收口径 |
|---|---|
| 数据范围与口径说明 | 项目涉及字段全部有定义、公式、取数来源，且业务方签字 |
| 主数据标准 | 四类实体的编码规则统一，历史数据完成映射 |
| 质量规则集 | 关键字段校验规则可自动执行，脏数据率有基线可对比 |
| 追溯链路说明 | 能从成品批次反查到设备、工序、来料批次 |
| 责任矩阵 | 每个字段有明确责任人与更新频率 |
验收不看"文档写了多少页"，看数据本身：抽 50 条真实记录，字段完整率、口径一致性、追溯可查询率是否达到约定值。
三个常见误区
- 把治理当成 IT 项目。口径确认必须业务部门参与，IT 单方面定不了"良率怎么算"。
- 只治理历史数据，不管新增。历史修干净了，新数据继续脏，三个月回到原点。质量规则必须卡在录入环节。
- 没有责任人。治理成果靠自觉维持，通常维持不过一个季度。
常见问题
数据治理要多久？
我们的数据很乱，是不是得先治理两年？
治理要用什么工具？
和做数据中台有什么区别？
治理完数据就一定能做 AI 了吗？
扫码加企业微信