一个返工故事：问题不在技术，在判断
周明远是一家制造企业的信息主管。年初他推动了一套统计报表系统的建设，目标是让生产、库存、销售三条线的数据在一个看板里对齐。项目上线两个月后，财务同事反馈：同一批出货数据，销售报表和库存报表对不上。技术团队排查了一周，发现两边取数的口径不同——销售按订单确认时间统计，库存按出库时间统计。问题不在代码，而在立项时没人把这件事说清楚。
这类故事在数据项目里并不少见。江南在服务企业客户的过程中也常遇到类似情形：方案结构看起来完整，真正落地时却卡在某个没人负责确认的细节上。数据方案的质量，往往不取决于工具多先进，而取决于参与的人在关键节点上做了什么样的判断。
需求调研阶段：谁在替业务说话
周明远的项目启动会上，参会的有IT部门、销售总监和财务经理，唯独没有仓库的一线主管。需求清单是IT同事根据往年报表整理的，看起来面面俱到，但缺少一个关键问题：仓库实际按什么节点记录出库。江南在类似项目里通常会建议客户做一件事——把需求调研拆成两轮，第一轮找业务负责人确认目标，第二轮找一线操作人员确认数据来源和记录习惯。
- 业务负责人关心的是报表能不能支撑决策，比如月度出货趋势是否清晰。
- 一线人员关心的是数据录入是否方便，比如出库单是否必须当天提交。
- 两轮调研的结论如果冲突，恰恰是需要提前定规则的地方。
周明远后来补做了这一轮，才发现仓库存在隔天补录的习惯，这直接影响了库存报表的时效性。这个发现没有增加多少开发量，却让方案的范围描述准确了很多。
方案选型阶段：工具之外的取舍
返工事件之后，周明远重新审视了选型过程。当初团队对比了几类报表工具，最终选了一套功能齐全的系统，但忽略了自家IT团队只有两个人能维护。江南在数据方案栏目里反复提到一个观点：选型不是选功能最多的，而是选团队接得住的。功能清单可以列得很长，但上线后真正每天用的是那几张核心报表，维护成本却摊在所有模块上。
他后来做了一个调整：把非核心报表改为定期导出，核心看板保留在系统内。这个取舍让运维压力下降了不少，也让团队有余力去处理数据口径这类更根本的问题。方案结构里的每一个模块，背后都应该有一个能说清楚“为什么需要它”的人。
上线运维阶段：故事没有终点
系统稳定运行后，周明远养成了一个习惯：每季度和业务部门开一次数据口径对齐会。会上不讨论技术，只确认一件事——这季度有没有新的业务规则出现，导致原来的统计方式不再适用。江南接触过的不少企业，数据方案在立项时做得不错，却在业务变化后逐渐失准，原因往往是没有人负责持续维护那份口径说明。
数据方案不是一份交付即封存的文档，而是一套需要人持续照看的约定。周明的故事没有戏剧性的转折，但它说明了一件事：在需求、选型、运维这些环节里，人的判断和沟通，往往比方案模板更能决定项目走多远。
