数据治理：为什么“这数据不对”成了跨部门沟

一个高频出现的对话

“这数据不对。”

在某企业的会议室里，这句话几乎每天都会出现。

销售部对运营部说：“你们报的客户数不对，我们这边统计的比你们多。”运营部对财务部说：“你们算的订单量不对，和系统里的对不上。”财务部对销售部说：“你们确认的收入不对，发票没开那么多。”

每次说“不对”，都要花大量时间去核对。核对到最后，往往发现：数据本身没错，是口径不同、时间点不同、定义不同。

但下一次，同样的对话还会发生。因为没有人去解决“为什么总是不对”的根源问题。

这句话高频出现，本身就是数据治理不到位的信号。

---

第一章：“不对”的背后是什么

一句“数据不对”，背后可能藏着多种不同的问题。把这些问题分清楚，才能找到对应的解决方法。

第一种：定义不对

销售部的“客户”指签了合同的公司，客服部的“客户”指打电话来咨询的人。两个部门对“客户”的定义不同，统计出来的数字当然不同。

这不是数据错了，是定义没有对齐。

第二种：口径不对

“复购率”可以按人数算，也可以按订单数算。按人数算，一个人买十次算一次复购；按订单数算，一个人买十次算十次复购。同一个数据源，两种口径，两个数字。

这不是数据错了，是口径没有说清楚。

第三种：时间点不对

财务按发票开具时间统计收入，运营按订单完成时间统计收入。月底最后一天开的发票，可能到下个月初才进入运营的统计周期。

这不是数据错了，是时间基准没有统一。

第四种：记录不对

数据录入时填错了。客户名称填成了别家，物料规格选错了选项，数量多写了一个零。

这是真正的数据错了，需要从源头纠正。

第五种：同步不对

客户改了地址，只在CRM系统里更新了，ERP系统里还是旧地址。两个系统之间的数据没有同步。

这不是原始数据错了，是数据流转出了问题。

五种“不对”，原因不同，解法也不同。把原因混在一起谈，永远解决不了问题。

---

第二章：不同“不对”的不同解法

定义不对的解法：建立业务术语表

业务术语表是一份文档，记录企业里每个核心业务术语的明确定义。

比如“客户”：指与本企业签订了销售合同或服务协议的法人实体。不包括未签约的潜在客户，不包括已终止合作的客户，不包括个人消费者（如果有专门的个人客户定义，另列）。

比如“活跃用户”：近90天内有至少一次登录行为的用户。不包括仅浏览未登录的用户，不包括通过API接口访问的系统用户。

业务术语表不需要一开始就很全。从最常吵架的术语开始，一个一个定义清楚。定义达成共识后，发布出去，新员工入职时学习，老员工有疑问时查阅。

口径不对的解法：指标计算说明书

每个核心业务指标，都应该有一份计算说明书，写明计算公式、数据来源、统计周期、排除条件。

例如“客单价”：

• 计算公式：销售总额 ÷ 下单用户数

• 数据来源：订单表（订单状态为“已完成”）

• 统计周期：自然月

• 排除条件：退货订单已冲减，测试订单不纳入

有了计算说明书，任何人都可以按同样的规则算出同样的数字。

时间点不对的解法：统一时间基准

明确每个数据统计的时间基准。是按业务发生时间？按系统记录时间？按财务确认时间？

常见做法：业务系统以业务发生时间为准（如订单创建时间），财务系统以单据确认时间为准（如发票开具时间）。两个基准不同，跨系统对比时要做时间对齐说明。

记录不对的解法：源头控制和事后清洗

源头控制：在数据录入环节设置校验规则。格式校验、范围校验、逻辑校验、重复校验。不合规的数据在录入时就被拦截。

事后清洗：对于已经存在的错误数据，定期做清洗。按优先级分批处理，先清理影响最大的。

同步不对的解法：明确主数据源

每个核心数据实体，指定一个主数据源。客户主数据以CRM系统为准，物料主数据以PLM系统为准，供应商主数据以SRM系统为准。

其他系统从主数据源同步数据，不在自己的系统里直接修改。同步规则和频率要明确，同步异常要有告警。

---

第三章：一个具体的治理流程

以一个常见问题为例——“客户名称不一致”。

步骤一：发现问题

销售部在做客户分析时，发现同一个客户在系统里有多个名称。客服部在查客户信息时，也发现了同样的问题。

步骤二：归因分析

检查发现，原因有三类：

• 定义问题：有些“客户”实际上是潜在客户，不应该进入正式客户表

• 记录问题：录入时写错了字，或者用了简称

• 同步问题：CRM改了，ERP没同步

步骤三：制定对策

针对三类原因，分别制定对策：

• 定义问题：明确正式客户和潜在客户的区分标准，潜在客户单独建表

• 记录问题：客户名称字段设置查重校验，录入时提示已有相似记录

• 同步问题：配置CRM到ERP的自动同步接口，每小时同步一次

步骤四：执行对策

• 发布客户定义标准，全员知悉

• 配置系统查重规则

• 开发或配置同步接口

步骤五：验证效果

一个月后，复查客户名称不一致的情况。新产生的客户记录中，不一致率下降了80%以上。

步骤六：沉淀经验

把这次处理过程中形成的规则、流程、配置，写入数据治理规范文档。下次遇到类似问题，可以直接参考。

这个流程的核心逻辑是：不满足于“把这次的数据改对”，而是要去追究“为什么会产生错误”，然后从源头堵住。

---

第四章：新易编码能做什么

新易编码不解决所有“数据不对”的问题，但它在一个具体环节上有作用——编码和分类的不一致问题。

编码和分类是“不对”的高发区。物料一物多码、客户重复建档、产品分类不一致，这些都属于编码和分类的问题。

新易编码的具体功能：

编码规则的统一。 企业可以在平台上定义统一的编码规则。物料怎么编、客户怎么编、供应商怎么编，规则一致，不会出现A部门用一种规则、B部门用另一种规则的情况。

编码申请的查重。 用户在申请新编码时，系统自动检索已有编码库，提示是否重复。从源头减少一物多码。

编码的跨系统映射。 老系统里的旧编码不用立即废弃，新易编码支持新旧编码的映射。新旧体系可以并行运行，逐步切换。

编码质量的监控。 系统提供质量看板，展示编码的重复率、完整率、异常率。责任人可以定期检查，发现问题及时处理。

这些功能不解决所有“不对”的问题，但它们把编码和分类这个高频问题领域管理起来了。

---

第五章：几个容易被忽略的点

点一：数据治理的产出要可见

数据治理做得好不好，不能只靠感觉。要有可量化的指标：客户名称不一致率下降了百分之多少？对账时间缩短了多少天？因数据问题导致的业务异常减少了多少起？

指标不需要很复杂，但要能反映治理效果。有了指标，才能向管理层证明投入产出比，才能持续获得资源支持。

点二：数据治理不是IT一个部门的事

IT部门可以搭系统、设校验、建流程，但IT部门不知道“客户”应该怎么定义，不知道“复购率”应该按什么口径算。定义和口径，必须由业务部门来定。

数据治理的组织模式应该是：业务部门提需求、定规则，IT部门建工具、做支撑，管理层给资源、促协同。三方缺一不可。

点三：标准文档要“有人看”

很多企业有厚厚的标准文档，但没有人看。文档写出来不是目的，被使用才是目的。

标准文档要简洁、可查、可更新。不用写几十页，核心内容几页纸就够了。放在大家方便查阅的地方（如公司内网、协作工具）。标准有变更时，及时更新并通知相关人员。

点四：不要追求100%完美

数据治理不是追求零缺陷。有些数据的准确性要求很高（如物料编码、客户ID），有些数据的准确性要求没那么高（如客户的“兴趣爱好”字段）。

把治理资源集中在影响大的数据上。花80%的精力治理20%的核心数据，比花100%的精力治理所有数据更务实。

---

结语

“这数据不对”这句话高频出现，说明数据治理还没有做到位。

解决这个问题，不需要一次搞定所有数据。从最常吵架的那个指标开始，把定义定清楚，把口径写明白，把流程跑通。一个指标解决了，再解决下一个。

新易编码在这个过程中的角色是：在编码和分类这个具体领域，提供工具支撑。它不解决所有“不对”的问题，但它能让编码和分类的不一致问题大幅减少。

如果您所在的企业也经常说“这数据不对”，不妨从明天开始做一件事：找出公司里最常被质疑的那个数据指标，花一个小时把它的定义和计算口径写清楚。这一个小时，可能就是数据治理的突破口。


如果您有物料编码相关的问题，欢迎咨询新易物料编码