一个被反复退回的需求单

周敏是江南数据服务团队的实施顾问，接手临安一家五金制造企业的数据整合项目时，需求单已经被业务部门退回过两次。客户信息部写得很清楚：把仓库出入库台账、采购订单、生产领料三套数据打通，形成统一的物料流水视图。听起来是标准的整合需求，江南的工程师评估后也认为工作量可控。

但第一次方案评审会上，仓储主管只问了一句：“你们打算用哪个物料编码做关联？”会议室安静了几秒。信息部说用系统里的编码，仓储主管摇头，说仓库实际记账用的是另一套手写简码，两套编码对不上的物料大概占三成。这个细节没有出现在任何需求文档里，却是整个整合方案的地基。

周敏没有急着改方案。她向客户申请去仓库现场待几天，跟着出入库班组一起上下班。江南内部有个不成文的习惯：数据整合项目在写代码之前，先确认数据在真实业务里是怎么产生的。

三天里看见的三件事

第一天的观察集中在收料环节。供应商送货单上的物料名称、采购订单上的名称、仓库台账上的简码，三者指同一批货，写法却各不相同。仓管员老陶凭经验判断，遇到拿不准的就翻手机里存的老照片。周敏把这类情况逐条记下来，当天晚上整理成一份对照清单，第二天一早拿给老陶确认。

第二天她跟着发料班组走线。她发现简码并非随意编写，而是按货架区位加物料大类组合而成，有内在规律，只是从未被整理成文档。这个发现让江南团队调整了整合思路：不强行统一到系统编码，而是先建立简码与系统编码的映射表，保留仓管员的操作习惯，再在后台做归一。

  • 物料编码的混乱不是管理失职，而是历史系统切换留下的断层；
  • 现场经验里藏着可结构化的规则，需要有人蹲下来问；
  • 整合方案如果绕过一线操作习惯，上线后一定被绕开。

第三天下午，周敏和客户信息部、仓储主管一起过了映射表初稿。三方对着一张打印出来的清单逐行核对，当场确认了两百多条对应关系，剩下的疑难项单独列出，约定由老陶牵头补充。江南的项目经理后来评价，这三天省掉了上线后至少两个月的返工。

交付边界是在现场画出来的

回到江南后，周敏把现场记录整理成一份数据现状说明，附在实施方案前面。这份说明没有技术术语，只有业务场景、数据来源、已知缺口和责任人。客户负责人看完后说，这是他第一次看懂数据整合到底要动哪些地方。

周敏在项目复盘里写过一段话：数据服务的交付边界，不是合同里写的那几行功能，而是数据从产生到使用的完整链条。江南做数据整合，习惯把这条链条先走一遍，再决定系统里怎么建。仓库那三天没有写一行代码，却决定了后面所有代码往哪里写。

项目最终按计划上线。老陶现在打开系统就能看到自己熟悉的简码对应的流水，不用再翻照片。周敏偶尔还会收到他发来的消息，问某个新物料该怎么归类。这种上线之后还能继续对话的关系，在她看来，比验收单上的签字更有分量。