第一次返工：三个仓库，三种“在库”

老周在一家做工业配件的公司负责数据管理，星空的服务团队第一次进场时，他正被一张库存报表折腾得焦头烂额。采购部说报表里的在库数量偏高，仓储部说偏低，财务部干脆说两边都不对。老周把同一套统计逻辑跑了三遍，数字一模一样，问题显然不在计算，而在“在库”这两个字上。

采购部统计的是已下单未到货的在途量，仓储部统计的是货架上实际能盘到的实物，财务部则按已入库未结算的批次口径核算。三个部门各自维护一套表格，谁也没觉得自己的口径有问题。老周后来在会上说了一句话：报表没错，是我们把三种语言硬塞进了同一列。星空在梳理业务数据整合需求时，第一步做的不是写代码，而是把各部门对同一个字段的理解逐条列出来对照。

  • 采购视角：在途即占用，算在可用库存里
  • 仓储视角：只看实物，待检区不计入
  • 财务视角：以结算批次为准，退货单单独挂账

第二次返工：接口通了，逻辑没通

口径定下来之后，老周以为事情就顺了。星空帮他把仓储系统、采购系统和财务系统的数据接进统一的数据管理系统，接口联调当天全部通过。可报表一上线，仓储主管又找来了：退货区的货怎么算进了可用库存？

老周查了半天才发现，接口传的是“库存状态编码”，三个系统里同一个编码的含义并不一致。仓储系统里编码 03 是待检，采购系统里 03 是退货待处理。数据是通的，语义是断的。这类问题在系统集成阶段特别常见，星空在技术咨询中反复提醒客户：字段映射表不能只对字段名，要对业务含义和取值域。老周后来补了一份编码对照表，让三个系统的维护人共同签字确认，才算把这条链路真正打通。

他总结这段经历时说，集成不是把管子接上就完事，得有人蹲在管子两头看看流出来的东西是不是同一种液体。

第三次返工：业务确认不能只发邮件

前两次返工之后，老周改了一个习惯：每版报表上线前，拉上采购、仓储、财务各出一个人，坐在同一块屏幕前看同一组数据。第一次这么干的时候，仓储主管当场指出某类物料的计量单位在不同系统里是“箱”和“件”并存，折算系数还写死在旧报表的公式里。这个问题如果只靠邮件确认，大概率会被忽略。

星空在统计报表开发的流程里坚持一个做法：口径文档和报表原型同步交付，业务方在原型上直接标注疑问，而不是等开发完成后再提修改。老周把这条经验带回了公司，现在他们做数据可视化看板也一样，先让业务方在草图上圈出自己最关心的三个数字，再决定图表怎么排。

三次返工之后，那张库存报表终于稳定下来。老周在内部复盘时写了一段话：数据项目里最贵的成本不是开发工时，是部门之间来回解释“我说的不是那个意思”。把口径写下来、把编码对清楚、把业务方请到屏幕前，这三件事看起来慢，其实最快。