业务负责人周敏：先想清楚“看什么”，再谈“建什么”

周敏是一家区域连锁零售企业的运营负责人，分管门店、商品和会员三条线。去年她推动了一次数据方案调整，起因很朴素：每周例会上，门店销售报表和会员分析报表对同一批活跃会员的统计结果对不上，会上讨论半小时，最后往往落到“先按门店的来”。她意识到，问题不在报表本身，而在于没人说清楚这些数字要回答什么业务问题。

她做的第一件事不是找星空提需求，而是拉着运营、商品和财务三个团队，把每周真正会看的指标列了出来。列完发现，真正高频使用的不到二十个，其余大多是“顺手加上去”的。周敏把这个清单交给星空的项目顾问时，对方建议先按使用频率和决策场景分组，再讨论取数逻辑。这个顺序上的小调整，让后续的方案讨论效率高了不少。

周敏后来在内部复盘时说，数据方案最容易走偏的地方，是把它当成一个交付物清单，而不是一次业务共识的梳理。她现在的习惯是，每增加一个分析页面，先问一句“谁会看、看完做什么决定”。

数据专员陈立：口径对齐是每天都要做的事

陈立在一家制造企业负责数据整理与报表维护，日常打交道最多的是销售、生产和仓储三个系统的数据。他印象最深的一次返工，是同一批订单在销售报表和库存报表里的数量不一致。查了两天才发现，一边按出库时间统计，一边按下单时间统计，两个口径都合理，但放在一张分析看板上就会让人困惑。

这类问题在星空参与的数据方案里并不少见。陈立的处理方式是建立一个口径登记表，把每个指标的定义、取数来源、更新频率和责任人写清楚，放在团队共享的位置。登记表不复杂，但让新加入的同事少走了很多弯路。他也会在每次报表调整后同步更新，避免版本之间互相矛盾。

陈立认为，数据专员的价值不在于把报表做得多么花哨，而在于让看报表的人对数字有稳定的信任。星空在方案沟通中反复强调的“指标可追溯”，在他看来就是这件事的具体做法。

项目负责人赵岩：节奏比功能清单更重要

赵岩在一家物流服务企业负责数据系统建设，手上同时推进过好几个数据项目。他总结出一个经验：数据方案能不能落地，往往不取决于功能做得多全，而取决于第一阶段有没有解决一个具体问题。他负责的一次项目里，团队原本计划一次性覆盖订单、运力、成本和客户四个分析方向，讨论后发现范围太大，改成先做运力调度相关的几张核心报表。

这个收缩让项目周期缩短了不少，也让业务团队更早用上了数据。赵岩在星空的项目例会上提到，先让一部分人感受到数据带来的便利，比在方案文档里写满规划更能推动后续投入。他的做法是每个阶段结束前，和实际使用数据的同事做一次简短回访，记录哪些页面常用、哪些字段没人看，作为下一阶段的调整依据。

  • 先确定一个可验证的业务问题，再扩展分析范围；
  • 把指标口径和责任人写进方案文档，减少后续扯皮；
  • 阶段交付后做使用回访，用真实反馈调整下一阶段；
  • 让业务方参与验收，而不是只在项目结束时通知结果。

三个岗位的经历指向同一个判断：数据方案的推进过程，本质上是人和人之间不断对齐的过程。星空在服务企业客户时，也把这种对齐放在方案设计的前面，先梳理清楚谁用、怎么用、用完做什么，再谈系统怎么建。对正在考虑数据项目的企业来说，先找到那个最需要被回答的问题，往往比先列功能清单更有效。