第 4 章 · 报表做完了，为什么没人行动

经营会上，大屏把问题标得很清楚。

某一区域收入连续三个月下降，某类库存周转天数越来越长，某个渠道看起来销量不错，扣掉促销和退货以后却在亏钱。

数据团队讲完，领导点头，业务部门拍照。会议结束，下一项议题开始。

一个月后，同一张图又出现了。

数字更红了一点。

做数据的人遇到这种场面，很容易怀疑自己的工作：是不是分析还不够深？是不是预警不够及时？是不是图表没把重点突出出来？

于是再做一层下钻，加一个预测模型，给异常配上颜色和消息提醒。

这些改进可能有用。只是很多时候，问题并不在“有没有看见”。

问题在看见以后。

一张报表没有手和脚

库存积压是一个事实，处理库存是一串动作。

有人要判断是需求预测错了、采购多了、产品卖不动，还是供应商交货周期迫使企业提前备货。判断完，还要决定降价、调拨、退货、停采还是继续等。每一种动作都牵涉不同部门，也会伤害某些人的指标。

报表只能把问题送到门口。

门里面是谁，往往没有写在数据模型里。

负责看库存的人未必有权停采购，有权停采购的人可能担心缺货，销售希望保留更多现货，财务想先把占用资金降下来。大家看到的是同一张表，背后站着的却不是同一笔账。

所以“数据驱动”最容易被误解成：只要数据足够好，正确动作自然会发生。

现实里，数据很少自己驱动什么。它需要进入一个具体的责任结构：谁判断，谁批准，谁执行，谁承担做错的后果。

少了其中一环，报表就只是比较高级的通知。

不行动，有时是理性选择

数据部门常把“不行动”理解成业务不重视数据。

这句话有时对，有时太轻松。

一个区域经理看到利润下滑，不一定不知道该关掉低效网点。他可能知道得比总部更清楚，只是关店会让自己的规模指标难看；采购看到库存积压，也可能知道应该少订货，但供应商合同、最低采购量和缺货考核都压在另一边。

站在公司整体看，行动有道理。站在个人位置看，不动反而更安全。

这也是为什么有些企业报表很多，会议很多，行动很少。不是知识不足，而是每个人都在一套局部激励下做了合理选择。

1999 年，斯坦福教授 Jeffrey Pfeffer 和 Robert Sutton 把类似现象称为“知道—做到的鸿沟”。企业并不缺改善绩效的知识，却会让讨论、计划和演示代替行动。

数据平台可以缩短“知道”的时间，填不上所有“做到”的沟。

如果考核不变、权限不变、风险归属不变，给每个人多发几条预警，只会让通知栏更忙。

指标进入考核以后，就不再中立

很多数据项目有一个朴素愿望：把事实摆出来，大家按事实管理。

可指标一旦与奖金、晋升和部门评价挂钩，它就不再只是事实。

按收入排区域，有人会提前确认；按利润排，有人会争论成本怎么分；按客户满意度排，有人会把难处理的客户推给别组。指标没有撒谎，人会适应指标。

这不是说不要考核，而是提醒数据团队：指标发布以后，业务会反过来塑造数据。

一个预警系统如果只统计处理数量，团队可能优先关闭容易的异常；如果强调追回金额，又可能把时间都花在少数大单上。技术上最准确的指标，不一定产生经营上最好的动作。

报表设计到这里，已经碰到了组织设计。

谁来使用这个指标？他能采取什么动作？动作与他的利益一致吗？如果几项指标冲突，优先级由谁决定？

这些问题若在项目后期才问，通常已经晚了。

从“展示什么”改成“谁要做什么”

做 BI 时，需求访谈经常从页面开始。

老板要一个总览，部门负责人要趋势，业务人员要明细。大家讨论筛选条件、下钻层级和刷新频率。页面做出来，看上去很完整。

如果把问题倒过来，答案会不一样。

不要先问“你想看什么”，先问：

你最近反复做的一个决定是什么？做决定前需要哪些信息？什么情况下你会改变原来的做法？这个动作由你执行，还是要别人批准？做完以后，几天或几个月能看到结果？

这几句话一问，很多“必须要有”的报表就会显得没那么必须。

有些数据只是让人安心，并不对应动作；有些数据很重要，却只需要异常时提醒；还有些问题根本不缺数字，缺的是跨部门达成一套处理规则。

这不是反对看板。看板适合建立共同态势，让团队知道事情在哪里。但若目标是改变业务，就必须继续往下走到动作。

数据团队过去常在“提供信息”处停下，不全是能力问题。合同这样验收，组织也这样分工。分析人员若主动追问业务执行，容易被说越界；业务结果不好，又有人反过来问数据项目创造了什么价值。

这份尴尬，后来会落到 FDE 身上。

可行动，不等于自动行动

“可行动洞察”曾经是 BI 里很流行的说法。

它比“多出几张报表”进了一步，但仍然留着一个含糊处：谁来行动？

到了 Agent 时代，技术似乎终于可以补上手和脚。系统发现库存异常，可以生成处理建议；发现客户流失风险，可以起草跟进话术；发现订单不一致，可以准备工单。

可一旦真的准备动手，旧问题全部回来，而且更尖锐。

谁允许它停采？谁批准它给客户发消息？如果两个指标冲突，它听谁的？动作造成损失，责任算模型、工程师、业务负责人，还是批准人？

过去，报表没有行动，是遗憾。现在，Agent 贸然行动，可能是事故。

所以从 BI 走向 FDE，不是给报表装一个按钮那么简单。企业要把原来藏在人和组织里的判断、授权与责任，拿出来重新写一遍。

而这一步首先会碰到另一个老问题：

客户嘴里说出来的需求，真的就是他每天在做的工作吗？

本章资料

场景说明：本章经营会、库存和渠道场景为组织中常见矛盾的复合表达，不指向具体企业。