一份没人愿意接的字段校验清单

周德昌在恒茂零售做了六年数据管理员，同事习惯叫他老周。恒茂零售的门店数量这两年从四十多家扩到一百二十家，业务系统里的字段也跟着膨胀。采购、库存、销售、会员四条线的数据汇到一处，问题开始显形：同一个供应商在三个系统里有三种写法，商品分类的层级深度不一致，门店编码有的带区域前缀有的不带。老周手里有一份字段校验清单，是年初整理出来的，密密麻麻列了七十多条规则，但一直停留在文档里，没人把它变成系统里能跑起来的东西。

这件事拖了几个月，原因不复杂。业务部门觉得校验规则是技术的事，技术团队觉得规则背后的口径得业务来定。老周夹在中间，两边的话都听得懂，两边的话都推不动。直到第三季度，江南的数据团队介入恒茂的报表系统改造，老周才找到一个把清单变成行动的切口。

先解决“谁说了算”的问题

老周做的第一件事不是写规则，而是拉了一张表，把七十多条校验规则逐条标上“口径归属人”。供应商名称的规范写法归采购部，商品分类层级归商品管理部，门店编码规则归运营部，会员等级定义归市场部。标完之后他发现，超过一半的规则其实没有明确的责任人，之前大家默认“数据管理员来定”，但数据管理员并没有业务决策权。

江南的顾问给了一个很朴素的建议：每条校验规则在系统里落地之前，必须有一个业务侧的人签字确认口径。老周把这个建议带到了跨部门会上，会上争论最激烈的是商品分类。商品管理部坚持按品类分，运营部希望按销售贡献分，两边都有道理，但系统里只能有一套主分类。最后折中的方案是主分类按品类，销售贡献作为派生字段单独计算。老周把这次讨论的结论写进了字段定义文档，每个字段后面附上确认人和确认依据。

  • 校验规则必须绑定业务口径责任人，不能默认由技术侧兜底。
  • 同一字段存在多种分类诉求时，确定主分类与派生字段的分工。
  • 口径确认过程留痕，形成可追溯的字段定义记录。

校验规则怎么设计才不“误伤”

规则落地阶段，老周遇到的新问题是误报。最初上线的供应商名称校验用的是完全匹配，结果大量正常数据被拦下来。采购部提交的“恒茂优选供应链有限公司”和系统里的“恒茂优选供应链”被判为不一致，实际上是一家。老周和江南的技术人员一起把校验分成三层：格式校验管编码位数和字符类型，逻辑校验管必填项和取值范围，一致性校验管跨系统比对。一致性校验不追求完全相等，而是设定相似度阈值，低于阈值的才进入人工复核队列。

这个分层思路让误报率明显下降。老周在周报里记录了一组观察：格式校验基本不需要人工干预，逻辑校验的拦截量集中在少数几个字段，一致性校验则需要业务侧定期处理复核队列。他还发现，校验规则的提示信息写得太技术化，业务人员看不懂“正则表达式不匹配”是什么意思，后来统一改成“供应商名称包含特殊字符，请核对”。江南在报表系统的字段管理模块里预留了提示语配置项，老周把这批提示语逐条改了一遍。

三个月后的变化与没变的部分

三个月下来，恒茂零售的字段校验规则从文档里的七十多条变成了系统里的四十二个有效校验点，其余的被合并或判定为不必要。老周的感受是，规则数量减少不是坏事，能跑起来、有人认、误报少，比清单好看更重要。供应商主数据的重复率下降了不少，门店编码在新开门店接入时不再需要人工补录前缀。

没变的部分同样值得记录。跨部门的口径争议不会因为一次会议就消失，商品分类的派生字段仍然需要每月核对一次，会员等级的定义在市场部换了一版活动方案之后又有了微调。老周现在的工作习惯是，每次业务规则变动，先更新字段定义文档，再同步校验规则，最后在江南的数据管理模块里确认生效范围。他说这套流程谈不上多先进，但至少让字段校验从“谁提谁负责”变成了“谁定谁确认”。对一家门店数量还在增长的企业来说，这个转变本身就有价值。