BI 报表为什么没人看：先定决策，再谈指标与看板分层

先给结论：多数 BI 报表不是做得不好看，而是从头到尾没有绑定过一个具体的决定。它回答的是「上个月发生了什么」，而开会的人真正要判断的是「这周该动哪一件事」。这两者之间隔着一层翻译，补不上这一层，表做得再细，三个月后也会变成收藏夹里没人点开的条目。这篇按行业这几年的变化讲起，说明为什么顺序应该是先定决策、再定指标、最后才轮到看板。

为什么报表上线三个月就没人打开了？

结论：因为报表交付的是数据，而使用数据需要一个事先约定好的动作。

上线时的场景往往很一致。业务部门说想看订单情况，IT 部门做了一张几十个字段的明细表，字段齐全、查询灵活、还能导出，验收会上人人说好。三个月后再看访问日志，除了做表的人自己，几乎没人打开过。

失效通常走三条路径。第一条是表只描述状态，不指向动作：看到转化率下滑，然后呢？没有规定谁在什么阈值下做什么，表就只剩下观感。第二条是数字和业务方的心理预期对不上时没有仲裁机制，财务算的和业务算的不是一回事，争论两次之后大家回到各自的表格文件，因为那里的数字是自己可控的。第三条是刷新时间不透明，打开页面不知道数据截到哪一天，每次用之前都要先问一句数是不是新的，问过几遍就懒得问了。

行业这一侧的验收口径也在变。前几年 BI 项目验收看的是报表张数、图表类型、有没有移动端；这两年越来越多企业把验收条件写成「这张表在哪个会上被使用、改变了哪个决定」。这个变化本身就说明，买方也发现张数不等于价值。

为什么先定决策比先定指标更重要？

结论：指标是描述世界的语言，决策是选择动作；先有动作清单，才知道该留哪几个指标。

指标字典这件事本身没错，错在顺序。如果先做字典，很容易做成一本很厚的册子，把能想到的口径都定义一遍，覆盖率看起来很高，但没有任何一个决定依赖它，最后它是一份文档，不是一个工具。

反过来做会简单很多。把过去一个月真正开过的经营会列出来，每场会列出被拍板的事项：要不要给某个渠道加预算、某个滞销品要不要清仓、某个仓的备货要不要提前。一条事项对应一张表，表里只放支撑这条判断需要的数字。对不上任何事项的需求，先不做。

这个做法会砍掉大量需求，也会让提需求的人不舒服，但它能换来一件很值钱的事：每张表都有明确的使用场景和使用者，删掉会有具体的人反对。一张删掉之后没人反对的表，本来就不该存在。

顺序定下来之后，指标才有归属。为决定服务的那几个指标需要精确到能被追责，其余指标可以粗放，只要趋势对得上就行。把全部指标都做到同等精度，是很多数据项目预算失控的起点。

看板为什么要分层，每一层该放什么？

结论：不同层的人做决定的时间尺度和颗粒度都不一样，混在一张表里，两层都用不了。

最常见的失败是把战略指标和执行明细放在同一页。老板打开先看到几百行明细，找不到重点；一线主管打开先看到利润率，不知道该处理哪一单。两边都觉得这张表不是给自己做的。

分层不是做四套系统，而是同一个数据集给不同角色不同的视图。

分层的核心是同一个指标在不同层用不同精度。订单量在战略层看月度趋势和结构占比，在经营层看周环比和渠道分布，在执行层看今天还有多少单没发货。名字相同，口径必须能对上，但展示的粒度和对比基准不一样。口径能不能对上，往往取决于上游系统：订单在交易系统、库存在仓储系统、回款在财务系统，同一个指标要跨三个系统拼出来，接口层的字段命名和统计时点不统一，三个层看到的数就会各说各话。

异常层单独拎出来，是因为它的触发方式不同。前几层是人主动去看，异常层是数据主动找人，靠阈值和责任人推送。把它混进执行层，告警会淹在报表里，没人当天处理。

为什么刷新时效该写成承诺，而不是越快越好？

结论：刷新频率的价值取决于决定的时间窗，超出时间窗的实时性买不到任何东西，只买到成本。

月度复盘用隔日数据完全够，因为讨论的是上个月的结构问题；当日调价、当日补货这类决定需要小时级；客服和风控看的是分钟级。把三者都做成实时，成本翻几倍，而月度复盘的人根本感觉不到差别。选型时容易被供应商的频率参数带走，原因就在于频率是可比较的数字，时间窗是要自己梳理的东西。

比频率更容易被忽略的是新鲜度可见。用户不信任一张表，往往不是数字算错了，而是不知道它截到哪一天。把新鲜度做成接口字段摆在页头，比在群里解释十次有用。

数据新鲜度接口字段
dataset_code：数据集编号
data_as_of：数据截止的业务时间
refreshed_at：最后一次成功刷新时间
latency_seconds：refreshed_at 与 data_as_of 的时间差
sla_seconds：该数据集承诺的时效上限
status：fresh / stale / failed
next_run_at：下次计划刷新时间
owner：指标责任人
判定规则：latency_seconds 不超过 sla_seconds 置 fresh；超出置 stale，页头显示数据未更新提示；连续两次刷新失败置 failed，直接通知 owner。

这段约定的价值在于可验证。方案里写「数据准实时」没有意义，写清 sla_seconds 是多少、超时之后界面怎么提示、谁来处理，才算把承诺落到系统里。很多报表失去信任，就是从一次没人解释的延迟开始的。

还有一层前提：新鲜度能不能算准，取决于上游接口怎么给时间。有的系统记创建时间，有的记审核时间，有的用本地时区，直接混在一起，latency 就成了一个说不清的数。这类问题最后都要落到接口层的字段约定上，业务时间和入库时间分开传，时区统一，否则页头那个新鲜度标签本身就是错的。

责任人制度为什么比工具选型更难落地？

结论：换工具是一次性成本，责任人是持续成本，后者才决定一张表能不能活过半年。

指标责任人要干三件事。定义，说清这个数怎么算、边界在哪、哪些情况不计入；变更，改口径前提前公告，给出新旧对照，避免同一张图前后不可比；解释，数字异常时最先被问的人，也是最先要去查的人。

行业里这两年有个明显转移。早几年数据团队既搭平台又背指标解释，业务方只负责提需求，结果数据团队变成取数窗口，需求越接越多，谁也说不清哪个数是对的。现在越来越多企业把指标解释交回业务侧，数据团队转为平台方和工具方，负责把口径变成可执行的配置和校验。这个转移不完成，上多少工具都只是把取数窗口做得更漂亮。

具体落地时有两个细节值得坚持：责任人写进指标卡片，而不是写在群里；一个指标一个责任人，不设共同负责，因为共同负责等于没人负责。前者解决查得到，后者解决推得动。

轮值还是固定，看业务节奏。指标少的公司固定到人更稳；指标多、人员流动快的公司可以轮值，但要有交接清单，交接时把当前口径、已知偏差、待确认问题一起交出去。没有交接清单的轮值，半年后口径一定会飘。

常见问题

下面几个问题在选型和验收阶段被问得最多，答案都建立在同一个前提上：报表是给决定用的，不是给展示用的。

BI 报表和手工表格能共存吗？

能，而且短期必须共存。手工表的价值在于灵活和即时，很多临时判断确实等不到建模。合理的分工是：进入会议的固定指标走系统，临时分析留在手工表，但手工表算出来的结论一旦要反复使用，就必须回到系统里固化口径，否则同一个数字会有两个版本，下次开会又要争一遍。

公司只有几十个人，也需要分层吗？

不需要四层，但至少要有两层。人数少的时候老板和一线经常是同一批人，可以只保留经营层和异常层：一层看趋势，一层看今天必须处理的事。分层的目的不是和组织架构对齐，而是让同一个人在不同时间看不同颗粒度，避免用日报的视角讨论季度问题。

指标定义改了，历史数据要不要重算？

取决于这个指标是否用于跨期比较。如果只是内部参考，标注口径变更日期即可，让使用者知道前后不可直接对比；如果要用来考核或者对外披露，就必须重算，并在页面上保留旧口径的快照。最怕的是悄悄改掉，图看起来平滑，结论全变了。

报表没人看，是不是该先换工具？

先别换。工具能解决的是展示和性能，解决不了这张表服务哪个决定。判断方法很简单：找出最近一个月真正被使用过的三张表，看它们分别在哪个会上被打开过。如果一张都想不出来，换工具只会让新工具也变成没人点开的收藏。

小公司没有专职数据团队，这套顺序还能走吗？

能，而且更需要。没有专职团队时，最耗不起的是反复返工，先把决定清单列清楚，需求会少一半。指标责任人可以由业务负责人兼任，但定义和变更公告这两件事必须留痕，写在一份共享的指标卡片里，而不是口头约定。