数据质量这事，甲方和乙方想的完全不一样

数据质量这事，甲方和乙方想的完全不一样

同一批脏数据，甲方半夜睡不着，乙方看了眼工单明天再说。两边想的根本不是一回事，我在两个位置上坐过，讲给你听。

数据质量出问题的时候，甲方和乙方的第一反应完全不同。

我在甲方干了十几年，G企数据治理项目里我是甲方项目经理，天天被业务部门追着问数据怎么又不对。后来转了乙方，给合资品牌做客户数据质量优化，坐在了另一边，才发现自己当年的很多抱怨，放在乙方位置上完全说不出口。

这篇不站队，把我两边看到的真实想法摆出来。甲方到底要什么，乙方到底怕什么，矛盾卡在哪，最后怎么解。看完你就知道，为什么数据质量项目十个有八个烂尾，剩下的两个是怎么活下来的。

---

甲方视角，我要的是结果

先说甲方。

G企那个数据治理项目，背景不复杂。销售系统一套客户信息，售后系统一套，会员系统一套，三边都对不上。同一个车主，销售那边叫张三，售后那边可能登记的是他老婆的手机号，会员系统里干脆是个新用户。做一次活动想圈选老车主，圈出来的人数比实际销量还多，业务部门直接拍桌子。

我作为甲方项目经理，压力全在业务满意度上。业务不懂什么数据治理方法论，他们就问三句话。这数据准不准，能不能用，什么时候能用。回答不上来，下一轮例会就是你的问题。

所以我当时的思路很简单，建监控体系，让质量问题暴露出来，然后一个个修。我们按DAMA的数据质量维度搭了规则，准确性、完整性、一致性、时效性、唯一性、有效性，每个维度都配了检查规则和告警。手机号少一位数的，身份证格式错的，姓名和性别对不上的，全部拦下来打回源头。

这套东西跑起来之后，质量报表的准确率从70%提到了95%以上。我以为这事成了，结果业务部门还是不满足。他们跟我说，你这些指标我不关心，我就问你，我下周的活动圈选，能不能一次到位。

这就是甲方，要的是结果，不是过程。监控体系建得再漂亮，规则再完备，对甲方来说都是手段。数据用起来顺不顺，报表对不对，营销圈人不跑偏，这才是他们眼里的数据质量。

---

乙方视角，我要的是验收

再讲乙方。

后来我转到乙方，给一家合资品牌做客户数据质量优化项目。项目需求写得很清楚，22个新数据源要接入，已有的质量监控规则要复用，从原系统搬到大数据平台，规则要做成UDF函数，异常数据要建闭环管理流程，出问题能触发工单，人工修正后再回流。

需求书厚厚一本，每一条都是白纸黑字。合同里写明了交付范围、里程碑、验收标准。到了什么节点交什么文档，功能清单上勾掉一项算一项。

作为乙方，我的心态完全变了。我不再关心业务部门周末的活动圈选准不准，我关心的是这周的迭代能不能按时提测，测试能不能通过，验收的时候甲方会不会在某个功能上卡我。质量规则上线了，就算交付。规则上线之后准不准，业务用起来顺不顺，那是甲方运营的事。

这话听着有点凉薄，但乙方就是这么活的。成本、人力、合同周期都是固定的，多投入一天就是多一天的成本。我见过太多乙方，验收一过，项目组撤场，剩下的人看一眼监控大盘，数据有没有问题，明天再说。

乙方不是坏人，是合同逼的。交付物是功能，验收标准是功能清单，那就按功能清单干。效果好不好，合同里没写。

---

矛盾的本质，两套标准对不上

把两边摆在一起看，矛盾就清楚了。

甲方按效果考核。数据质量好不好，看业务用起来顺不顺，报表对不对，活动效果达不达标。至于平台用了什么技术，规则写了几条，甲方不关心，也不该关心。

乙方按交付考核。功能上线没上线，文档交付没交付，验收通过没通过。业务最终效果如何，那是甲方运营能力的问题，跟乙方没关系。

这两套标准不在一个维度上，就注定要打架。

我踩过一个真实的坑。在乙方的时候，甲方运营拿着圈选结果来找我，说这波人群圈得不对，里面混了一大堆非车主，质量太差。我查了半天，平台侧一切正常，规则都在跑，问题出在源头，源头系统里一批车主的证件号本来就是错的，数据进来的时候就不准。

这个锅最后谁背了？我背了。因为在甲方眼里，数据从你平台出来的，就是你平台的问题。源头数据不准，那是你们乙方没做好数据校验。

这就是责任边界的模糊地带。数据质量问题的根子，八成在源头系统，但背锅的往往是最后加工数据的那个角色。甲方挨了业务部门的骂，转头把压力传导给乙方，乙方一肚子委屈，但合同里没写源头数据责任划分，只能咽下去。

---

怎么解，我的四个做法

两边都待过之后，我总结了几条能落地的做法。不是理论，是踩过坑之后的经验。

第一，把质量目标写进合同，量化成指标。

甲方要的效果，翻译成乙方能验收的指标。准确率、完整率、覆盖率、异常修复及时率，白纸黑字写进需求书。准确率从70%提到95%，这就是可验收的目标，验收标准就是95%。乙方不用猜甲方要什么，甲方也不用担心乙方糊弄。两边对着同一个数字干。

第二，质量规则跟业务共建，别闭门造车。

很多数据质量项目死在规则上。乙方团队自己定义了一堆校验规则，上线之后发现业务根本不认。为什么，因为规则定的是技术视角，完整性、准确性，业务关心的是能不能用。我的做法是拉业务部门一起过规则清单，告诉他们每条规则拦的是什么问题，优先级怎么排。业务参与过、认可过的规则，上线之后才有人用，出了问题也说得清。

第三，异常数据要闭环，监控不是终点。

监控大盘再好看，数据异常了没人管，等于白建。异常数据必须能追踪，发现异常，生成工单，指派责任人，修复完成，回流验证，每一步都有记录。那家合资品牌的项目里我们就是这么做的，质量监控发现问题，触发工单，该外呼外呼，该修源头修源头，修完的数据重新回流，再跑一遍规则。闭环跑起来，质量才能持续改善，而不是今天修明天又脏。

第四，给持续运营留空间，别交付完就散伙。

数据质量是持续运营的事，不是一次交付的事。业务系统天天在变，新数据源不断接入，规则要跟着调。如果项目验收完乙方就撤场，三个月后规则就过时了。甲方要留持续运营的预算，乙方要认持续运营的责任。数据质量项目想活下来，这一条最容易被忽略，也最要命。

---

写在最后

数据质量这事，没有一劳永逸的方案。系统在变，业务在变，数据天天都在进，质量就是一个动态过程。

甲方要认清一件事，你要的效果，得说出来，说得具体，说得能验收。光喊数据要准，等于没说。乙方也要认清一件事，交付不是终点，数据从你手里出去，质量责任就跟着出去了。

我两边都坐过，说实话，都不容易。甲方被业务追着跑，乙方被合同绑着走。但数据质量这活，最后拼的不是谁甩锅甩得干净，是两边能不能把标准和责任对齐。

对齐了，项目就能活。对不齐，投入再多也是打水漂。

---

作者，凌波，18年汽车行业数字化老兵，CDGP数据治理专家。从DMS运维到数据中台架构，干过甲方也干过乙方。

博客园「凌波微数」，持续分享数据治理、数据架构、企业数字化的实战经验。如果对你有用，点个推荐吧~~