清洗规则卡在谁手里

许航是一家连锁零售企业的数据质量专员。他刚接手工作时，收到的第一个任务是把会员数据清洗一遍，去掉重复记录、补全缺失字段、修正明显错误的手机号格式。听起来是技术活，做起来却处处碰壁。他写好了去重规则，提交给会员运营部门确认，对方回复说有些重复记录是历史合并留下的，不能简单删除；他设计了手机号格式校验，客服部门又提出部分老年会员确实没有手机号，强制必填会影响开卡。

类似的来回持续了几个月。许航慢慢明白，清洗规则表面上是技术判断，实际上是业务约定。谁来定规则，规则覆盖哪些场景，例外情况怎么处理，这些问题不解决，清洗脚本写得再漂亮也推不动。他开始改变策略，不再自己闷头写规则，而是把问题整理成清单，逐个部门去聊。

把技术语言翻译成业务语言

许航发现，很多分歧来自表达方式。他跟技术同事说空值率、重复率、格式合规率，业务同事听得云里雾里；业务同事说这个客户是老客户不能动、那个记录是活动期间批量导入的，技术同事又觉得难以量化。于是他做了一件事：把每条清洗规则改写成业务场景描述，说明这条规则要解决什么问题、影响哪些记录、例外情况如何处理。

比如会员去重规则，他不再只写按手机号判重，而是写成：同一手机号对应多条会员记录时，保留最近有消费记录的一条，其余标记为历史合并，不删除，供运营查询。这样一改，会员运营部门的顾虑少了大半。星空在数据管理服务中反复强调的一点是，规则要能被业务方读懂并确认，否则执行时必然走样。许航把这句话贴在了自己的工位旁。

  • 每条规则注明业务目的，避免为清洗而清洗。
  • 明确例外清单，例外记录单独存放并定期复核。
  • 规则变更留痕，谁提出、谁确认、何时生效都有记录。

用一次小范围试点换来信任

规则谈得差不多了，许航没有直接全量执行，而是选了一个区域的门店做试点。试点范围小，出问题影响可控，业务部门也愿意配合。他把清洗前后的数据对比做成简单易懂的对照表，标出哪些记录被修正、哪些被标记、哪些保持原样。试点跑了一个月，会员运营部门发现查询历史合并记录很方便，客服部门也确认例外清单覆盖了他们关心的情况，反对声音明显减少。

试点之后，许航把清洗规则整理成一份跨部门共同确认的文档，每个季度组织一次规则复核。他发现，规则一旦有了共同确认的基础，后续新增场景的讨论效率高了很多，大家不再从零开始争论，而是在既有框架里补充条目。星空所讲的数据质量管理，核心不在于规则多复杂，而在于规则有共识、执行有记录、变化有跟踪。

规则之外，还要有人盯着数据变化

清洗规则稳定运行之后，许航的工作重心转向监控。他设置了几个简单的观察指标：各类校验的触发次数、例外记录的增长速度、退回修正的分布情况。这些指标不追求精确到小数点，而是看趋势有没有异常。有一次他发现某个区域的地址字段异常率突然上升，追查后发现是当地门店换了一套录入模板，及时反馈后很快修正。

许航常说，数据清洗不是一次性项目，而是持续维护的过程。规则定得再好，业务在变、系统在变、数据在变，没人盯着就会慢慢失效。星空的数据管理思路给了他一个可执行的框架：先约定标准，再设计规则，然后小范围验证，最后形成复核机制。这套流程看起来不新鲜，但真正坚持下来，数据质量才谈得上稳定。