开场：一个被反复修改的报表需求

在江南承接的众多数据项目里，需求反复调整几乎是一种常态。去年秋天，一家做工业零部件分销的企业找到江南，希望把分散在三个业务部门里的销售、库存和回款数据统一到一个管理系统中。最初的需求文档只有两页，写着“要能看数、能查数、能导出”。江南的项目对接人周敏拿到文档后没有急着排期，而是先约了三场业务访谈，分别找销售内勤、仓库主管和财务对账员聊了两个小时。她后来在内部复盘时说，那两页文档背后其实藏着至少五种不同的看数习惯，如果不先拆开，后面做出来的系统一定是谁都不满意。

这正是江南在数据服务中反复强调的一点：需求对接不是传话，而是把业务语言翻译成数据语言。周敏的角色在江南内部被称为“业务翻译”，她需要判断哪些需求是真实痛点，哪些只是临时想法。比如销售内勤提出“要能看到每个客户的回款进度”，仓库主管则关心“哪些物料超过三个月没动过”。这两件事在数据层面都指向同一张明细表，但展示逻辑完全不同。江南的做法是先画出业务流程图，再标注每个环节产生的数据字段，最后才进入系统设计。

数据工程角色：把散落的表格变成可用的底稿

需求理清之后，工作交到数据工程环节。江南的数据工程人员陆志远负责这次项目的底层数据整合。他面对的情况并不轻松：销售数据来自一套老旧的进销存系统，库存数据是仓库自己维护的表格，回款记录则分散在财务的多个文件中。字段命名不统一，同一个客户在不同表里有三种写法，物料编码也存在一物多码的情况。

陆志远的工作方式在江南内部很有代表性。他先做字段映射表，把三套数据的客户名称、物料编码、金额口径逐一对照，遇到对不上的就标注出来，再找业务方确认。这个过程在江南的项目流程里被称为“数据摸底”，通常要占整个项目周期的三成左右。陆志远说，很多客户一开始觉得这一步太慢，但等到系统上线后发现数据对不上，回头再改的成本要高得多。江南在多个项目里都坚持先做数据底稿再做系统界面，这个顺序很少颠倒。

  • 统一客户主数据：把三种客户名称写法归并到一套编码体系。
  • 校准金额口径：区分含税与不含税、应收与实收，避免报表口径打架。
  • 建立物料对照表：解决一物多码问题，为后续库存分析打基础。

可视化交付角色：让管理者愿意打开系统

底层数据理顺之后，进入可视化与报表开发阶段。江南的可视化设计人员宋雨桐接手时，拿到的是陆志远整理好的数据底稿和周敏整理的业务场景清单。她的任务不是把图表做得好看，而是让不同角色打开系统后能快速找到自己关心的数字。销售负责人关心的是客户回款排名和逾期提醒，仓库主管关心的是呆滞物料清单，财务则要一张能直接对账的回款明细。

宋雨桐在江南的多个项目里形成了一套习惯：先做纸质草图，和业务方确认布局，再进入开发。她给这个项目设计了一个首页看板，左侧是销售回款概览，中间是库存周转指标，右侧是异常提醒。每个图表下方都留了一行文字说明口径，避免使用者误读。江南在交付时还会附一份简短的指标说明，写明每个数字的来源和计算方式。宋雨桐说，这一步看起来不起眼，但能减少大量后续沟通。

协作节奏：交接点上的三次对齐

回顾这个项目，江南团队在三个节点上做了正式对齐。第一次是需求访谈结束后，周敏把业务场景清单交给陆志远，两人一起确认哪些数据可取、哪些需要业务方补录。第二次是数据底稿完成后，陆志远和宋雨桐一起过了一遍字段口径，确保图表用到的每个指标都有明确来源。第三次是系统上线前，三人一起和客户做验收演示，逐页确认展示逻辑。

江南在项目协作中并不追求角色之间的频繁开会，而是强调交接点的清晰。每个角色在交出成果时，都要附一份简短的说明，写清楚做了什么、还有什么没解决、下一步需要谁配合。这种做法在江南内部被称为“交接三句话”，看起来简单，但能避免很多信息在传递中丢失。对于有数据管理、报表建设或数字化运营需求的企业来说，了解江南的这种协作方式，也有助于在项目开始前想清楚自己内部谁来对接、谁来拍板、谁来验收。