|
做数据质量项目久了，我越来越觉得，企业真正缺的通常不是“发现问题”的能力，而是“把问题解决掉”的能力。
现在很多企业其实已经能发现不少异常。
字段空值能查，重复数据能查，指标波动能监控，关键任务延迟也能报警。
但问题真正出现以后，现场往往还是很乱：
业务说报表不对，IT开始排查，数据团队继续往上游找。
最后发现问题可能来自源系统，也可能来自同步过程，还有可能只是业务口径本身没有统一。
所以我现在判断一套数据质量体系做得好不好，我更关心的是：
一条异常从出现开始，能不能被发现、定位、找到责任人、完成整改，最后用数据证明它真的已经解决。
如果这条链路跑不起来，质量规则越多，最后往往只是报警越多。
这也是为什么数据管理不能只停留在“发现问题”这一层。
像 FineDataLink 5.0 新增整合了库表管理、血缘分析、数据检测、全局清洗规则等能力：
既可以统一管理数据表、查看表结构和数据，也能通过血缘分析追踪数据表、API、任务之间的关联关系；
同时支持自定义数据质量检测规则，以及对重复性、敏感数据等问题配置全局清洗规则。
数据集成工具FineDataLink 5.0我放在这里，需要的可以自取：
https://s.fanruan.com/ns1l9
数据质量真正要做的，不是让平台看起来更完整，而是让一个问题从出现到关闭都有人管、有依据、有结果。
很多质量项目一开始就问：
“我们有多少张表需要做质量检测？”
这个问题看起来很专业，实际上很容易把项目带偏。
因为一旦按照表来做，后面很快会变成：
最后规则数量上去了，但业务可能根本感受不到变化。
真正应该先问的是：
哪一类数据一旦出错，会直接影响经营判断、业务动作或者外部报送。
所以规则建设最好从业务损失反推。
实际可以先做一张“关键数据质量清单”，至少把几件事说清楚：
这样一来，质量规则就不再按照“字段多不多”设计，而是按照“业务影响大不大”设计。
比如库存可用量，不应该只检查“不能为空”，还应该继续考虑库存是否出现负数、更新时间是否超过阈值，以及ERP和WMS之间的数量是否存在明显差异。
真正有价值的质量规则，一定是围绕业务风险设计，而不是围绕字段类型设计。
二、异常出来以后，先别派单，先判断“从哪一层开始错”
这是很多企业质量处理最浪费时间的一步。
最常见的做法是：
发现异常以后，先找IT。
但IT查了一圈以后，经常会发现问题根本不是数据平台造成的。
比如最终报表里“客户名称为空”，可能有几种完全不同的根因：
最终表现都是“为空”，但整改方式完全不同。
所以发现问题以后，第一件事不是派单，而是把数据链路“切层”。
比较实用的方法，是沿着实际数据流往回看：
源系统 → 数据同步 → 明细加工 → 指标计算 → 数据消费
排查时每一层只回答一个问题：
“错误是不是从这里开始出现的？”
比如最终销售额少了300万，可以这样查：
这样排查的效率比一上来查所有日志高得多。
还有一个特别实用的原则：
质量平台一定要能够看到异常明细。
如果系统只告诉你“完整性得分92%”，其实很难处理。
真正有价值的是知道：
哪327条记录出了问题，来自什么时间，属于哪个业务批次，在哪张表里第一次出现。
在这一步，FineDataLink 5.0 可以把规则检测结果和具体异常明细结合起来，
再顺着库表和任务血缘继续向上追，判断问题究竟来自源端、同步过程还是加工逻辑，这样定位就不再只是靠经验猜测。
先把问题定位到具体层级，后面的派单才不会变成IT内部来回转发。
数据质量做到这里，通常就开始从技术问题变成管理问题。
因为企业很快会发现：
很多数据问题，IT其实没有权力直接修。
所以质量问题不能简单统一派给数据团队。
更实用的方法，是提前把责任分成几类。
比如：
-
-
-
数据业务责任：谁有权判断这条数据业务上到底应该是什么。
这三类责任经常不是同一个人。
举个很典型的情况。
供应商分类错误，数据团队可以发现哪几条记录不符合规则，也能查到它们来自哪个系统，但供应商最终应该归到哪一类，还是采购部门说了算。
所以质量闭环真正需要的是一张“责任矩阵”。
至少把核心主题域对应到：
这样问题一出来，不是临时找人，而是按照问题类型直接找到真正有处理权限的人。
FineDataLink 5.0 的问题清单更适合承接这种管理动作，因为检测出来的异常可以继续记录责任人、处理状态、整改说明和后续结果，让问题从一条系统告警变成可以持续跟踪的事项。
派单真正解决的不是“把问题送出去”，而是让问题送到真正有能力改变数据的人手里。
数据团队最容易形成的习惯，就是看到问题以后先想：
“怎么在ETL里把它修掉？”
短期看确实很快。
但如果所有问题都这么处理，几年以后数仓就会变成一个巨大的“补丁中心”。
所以质量整改之前，必须先问一句：
这个问题应该在源头修，还是允许在下游临时补偿？
如果问题来自业务操作或者源系统规则，而且源系统能够改，就应该优先回源。
比如：
-
必填字段长期为空，就应该检查前端必填是否真的生效；
-
供应商重复创建，就应该检查新增流程是否缺少唯一性校验；
-
订单状态异常，就应该检查业务流程是否缺少状态约束。
只有源系统短期改不了，或者涉及外部平台，才考虑在数据加工层做补偿。
而且这种补偿最好明确标记为“临时”。
实际整改记录里，至少要留下：
因此，更合理的做法是把这些能力用于必要的数据修复，同时保留问题记录和整改状态，避免所有源端问题最后都被永久吸收到ETL逻辑里。
质量治理最怕的不是脏数据，而是企业逐渐习惯用下游清洗掩盖源头问题。
这一点特别容易被忽略。
比如规则发现：
客户证件号为空327条。
业务把这327条全部补齐。
重新跑一遍规则。
异常为0。
很多项目到这里就会关单。
但实际上，只能说明：
历史问题修掉了。
并不能说明以后不会继续产生。
真正的复核，要同时看两个层面：
如果第二天又新增20条空值，说明企业修的是结果，不是机制。
这时候就应该继续往上追：
所以质量问题关单，不建议只看“一次复测通过”。
更稳妥的方法是做连续验证。
比如核心规则整改以后，可以连续观察3天、7天，或者覆盖一个完整业务周期，确认没有新增异常以后再关闭。
借助FineDataLink 5.0，可以把检测任务嵌入定时任务里，整改以后可以继续按照相同频率自动执行原规则，
让复核不再依赖一次人工抽查，而是通过后续连续数据判断问题是否真正消失。
质量问题真正关闭的标准，不是“有人说改好了”，而是“后续数据持续证明它已经好了”。
六、质量做了一段时间以后，真正该看的不是异常量，而是处理效率
很多质量大屏特别喜欢放：
这些当然可以看，但真正想判断治理有没有改善，我更建议看问题处理效率。
比如几个指标就很实用。
同一种问题关闭以后，又出现了多少次。
如果重复率长期很高，说明企业只是在修结果。
从规则报警，到确认问题发生在哪一层用了多久。
这个指标能直接反映血缘、日志和排查机制是否成熟。
问题定位以后，到真正修复用了多久。
如果定位很快，但整改长期拖延，通常说明责任机制有问题。
多少问题最终回到源系统和业务流程解决，而不是长期在下游做清洗补偿。
这个指标非常值得盯，因为它能看出治理有没有真正往上游走。
不要把所有表平均成一个质量分。
更应该单独看收入、利润、库存、回款、生产达成率这类真正重要的数据是否稳定达标。
FineDataLink 5.0 在这类场景里的价值，也不应该只用“配置了多少规则”衡量，而应该结合异常记录、问题清单和持续检测结果，去看定位时间有没有缩短、整改周期有没有下降、重复问题有没有减少。
质量治理真正进步的标志，不是报警变得更多，而是问题越来越快解决、越来越少复发。
七、同一种问题每个月都出现，就别再只按普通工单处理
这个经验很重要。
如果某一条规则已经存在，但同一种异常还是每个月重复出现，那么继续加规则基本没有意义。
真正应该做的是：
把它升级成“机制问题”处理。
比如客户手机号缺失，每个月都在报警。
这时候就不要再只补数据。
应该继续判断：
如果问题连续出现三次以上，我会建议把它从普通质量工单升级成机制整改项。
这时候处理动作也要变化。
不再是“补掉这批异常”，而是要重新检查：
FineDataLink 5.0 在这里更适合作为持续观测工具，把重复异常、整改状态和后续检测结果保留下来，
让团队能够从一条条问题里看出哪些异常正在反复发生，再推动管理动作从“再修一次”升级成“改流程或者改系统规则”。
质量管理做到后面，最重要的不是处理更多问题，而是把高频问题从根上消掉。
八、做到后面会发现，质量问题其实是企业管理问题的投影
数据质量项目刚开始，很多企业会觉得这是数据部门的事情。
但做到后面，真正顽固的问题往往都不是单纯技术问题。
-
比如客户重复，背后可能是销售人员为了抢客户各自建档。
-
供应商分类长期不一致，可能是采购本身没有统一分类规则。
-
生产数据经常缺失，可能是现场操作和设备采集机制没有真正管来。
-
指标长期争议，则可能是企业经营管理本身就没有统一口径。
所以质量规则更像一面镜子。
它能够让企业看到：
哪里正在持续产生不可信的数据。
但真正要解决问题，通常还得回到：
这也是“以用促治”最有价值的地方。
不需要一开始就搭一套宏大的治理体系。
先从业务真正依赖的数据切入。
这时，FineDataLink 5.0 的数据质量模块在这里更适合当作一个持续反馈机制，
把经营分析、财务管报和生产管理中已经影响使用的数据问题沉淀成检测规则，再结合异常明细和血缘不断往源头追，最后推动业务流程或者系统规则真正变化。
数据质量做到最后，不再只是“IT把数据修干净”，而是企业开始重新管理数据是怎么被生产出来的。
很多企业发现、定位、派单、整改、复核都有了，但还是觉得闭环效果一般。
一个很常见的原因是：
“什么叫问题关闭”没有统一定义。
到底能不能关？
核心问题最好提前设关闭条件。
比如：
满足这些条件以后再关闭，质量工单才不是走流程。
另外，历史记录不要删。
因为半年以后同类问题再次出现时，企业需要知道这是新问题，还是旧问题复发。
这两种情况的处理方式完全不同。
我们公司一般会用FineDataLink 5.0 ，把异常明细、问题记录和后续检测任务结合起来，
质量问题从出现开始就能留下完整处理轨迹，关闭以后继续用原规则监测，也能判断它是不是再次出现。
真正完整的闭环，应该做到问题有来源、整改有记录、关闭有证据、复发能识别。
数据质量闭环真正做起来，其实没有那么像教科书里的“五步法”。
企业现场更真实的过程通常是：
-
-
-
-
-
-
修完以后继续观察一段时间，看同样的问题还会不会出现。
做到这里，才叫真正闭环。
所以数据质量最值得建立的，不是一套“发现更多问题”的能力，而是一套：
让问题越来越少重复发生的能力。
真正成熟以后，企业应该逐渐看到：
这才是数据质量闭环真正应该带来的变化。 | 
