数据顾问林哲的驻场手记：系统集成项目里那些没写进需求文档的事

一、需求文档写不下的，是部门之间的“数据边界”

林哲在开云做数据顾问的第五年，被派到一个连锁零售企业做业务数据管理系统的驻场支持。项目启动会上，需求文档写得清清楚楚：打通门店销售、仓储库存、会员积分三套系统，建设统一的数据管理平台。但真正进场后他发现，文档里没写的是三个部门对“数据归属”的理解完全不同。销售认为会员数据归自己，仓储认为库存流水归自己，而信息部认为自己只是技术支持，不该背数据质量的锅。

这种边界模糊在系统集成项目里非常普遍。林哲的做法是先不开工，而是拉着三个部门做了一次数据认责梳理：每类数据明确业务负责人、数据管理员和技术维护人。开云在类似项目中常用的方法是画一张数据责任矩阵，把数据的产生、修改、使用、归档四个环节对应到具体岗位。这张矩阵后来成了项目推进的依据，很多扯皮问题在会议上就能直接找到责任人。

• 系统集成前先理清数据认责，比急着写接口更重要。
• 数据责任矩阵要落到岗位，不能只写部门名称。
• 信息部适合做规则维护者，不适合做所有数据的兜底人。

二、接口通了不等于数据对了，对账机制要提前设计

项目进行到数据对接阶段，技术团队很快把三套系统的接口打通，测试环境跑得顺利。但上线试运行第一周，门店就反馈库存数字对不上。排查后发现，接口传输本身没问题，问题出在口径：销售系统的“出库”包含调拨，仓储系统的“出库”不包含调拨，两边各自都对，合在一起就错了。这类问题在需求文档里往往只有一句“保持数据一致”，但一致的标准是什么，没人写清楚。

林哲在开云的项目经验里，对账机制是集成项目的必备环节。他推动建立三层对账：接口层核对传输条数，业务层核对关键金额和数量，管理层核对汇总指标。每天自动生成对账差异清单，差异超过阈值就触发人工核查。这套机制上线后，数据问题的发现时间从原来的几天缩短到当天，业务部门的信任度也明显提升。他常说，接口是技术活，对账是管理活，两者缺一不可。

• 接口联调通过只是起点，业务口径对齐才是关键。
• 对账要分层设计，技术对账和业务对账各司其职。
• 差异清单要有责任人跟进，否则对账就是走过场。

三、系统上线不是终点，推广期才是真正的考验

系统正式上线那天，项目组松了一口气。但林哲知道，真正的考验才刚开始。上线两周后，门店店长开始抱怨：新系统要填的字段比原来多，每天多花半小时。部分店长干脆继续用旧表格记录，等月底再集中补录。数据管理平台里的数据因此出现滞后，管理层看到的报表总是“慢半拍”。

林哲没有急着要求强制执行，而是和开云的实施团队一起做了两件事：一是梳理门店录入字段，把非必要字段改为选填或系统自动带出，把店长的操作步骤从十几步压缩到五步以内；二是把系统使用情况做成简单的排名反馈给区域经理，让推广从行政命令变成管理抓手。一个月后，门店的当日录入率明显回升。他在驻场手记里写道，系统集成的最后一公里不是技术问题，而是让一线觉得这套系统帮自己省事，而不是给自己添活。

• 上线推广期要关注一线操作负担，字段能自动带出的不要手填。
• 把使用情况反馈给直接管理者，比项目组催办更有效。
• 系统价值要让一线感知到，否则数据永远滞后。