1800 个指标教会我的事

问题

十多年前，我在一家物流公司主导过一套企业级 BI 系统，覆盖运营、工程、财务、人力、物流、产品、时效七八个领域，指标数最后长到了标题里那个数字。当时我们把这当成骄傲：汇报材料里指标数永远是第一行，老板问起系统，回答总是从「又新增了多少指标」开始。指标数量就这样成了成功标准：好量化，容易体现进展，也符合所有人对「数据驱动」的想象。

问题在半年后浮出来。先是同一个「准时率」在三个部门是三个数字，各自都能自圆其说；再是每个领域都有一套「订单量」，同名不同义，开会先花二十分钟对口径。更难受的是：指标出了异常，找不到能拍板说它对或错的人。业务不是它的 owner，数据团队也不是，它只是在某次评审里被加进来，然后一直活着。

最后是业务不信数：会上真正拿来做决定的，是某位运营主管自己维护的表格，而不是我们做了一年多的系统。指标越多，每个指标被看到、被验证、被信任的机会越少。

约束

复盘时很容易把当年的自己写得很蠢，所以先交代约束。

第一是组织。每个部门都要「自己的指标」。运营看时效、财务看成本、人力看人效，角度确实不同；而各部门配合的前提往往就是「把我要的数放进去」。拒绝一个指标，常常意味着失去一个部门。

第二是交付周期。项目按季度验收，「上线多少指标」写在目标里。这种节奏下，做新指标远比合并旧指标划算：前者是进展，后者是返工。

第三是团队。二十多人的团队，大部分是第一次做企业级 BI，包括我。我们对 ETL 和建模越来越熟，但对「指标治理」没有概念，甚至没有这个词。

第四是技术栈。一个指标就是一段 SQL 加一个报表控件，没有语义层、字典和血缘。两个指标是否一回事，只能靠人逐行比对 SQL。

这些约束叠在一起，让「指标越多越好」成了理性的局部最优。团队没做错什么，只是没人意识到，局部最优会在一年后变成全局的债。

方案

真正动手治理，是「业务不信数」被摆上桌面之后。做了三件事。

指标分层

把指标拆成三层。原子指标直接来自业务过程，比如一笔订单的签收时间；派生指标是原子指标叠加时间、维度和修饰条件，比如「某区域近七天平均签收时长」；复合指标是派生指标之间的运算，各种率和比都在这层。直接收益是数量骤减：大量看似不同的指标，只是同一个原子指标在不同维度的投影。原子层定清楚，其余两层按规则生成，不必逐个开发维护。

口径 owner 制

每个原子指标必须有一位业务侧 owner 对口径签字，数据团队只负责实现和验证，不再定义业务含义。细节见决策记录。

指标字典与交付标准

建一份人人可查的指标字典，写清层级、定义、计算逻辑、owner 和上下游。新增指标要过门槛：先查字典有无同义项，再找 owner 签字，最后才进排期。验收标准也跟着改：不看「上了多少」，看「有多少被真正用到」。

取舍

当时的路线有三条。

第一条是走过的路。第三条听着稳妥，但只是把混乱从公司级切成领域级，跨领域对齐没解决。我们选第二条做主干：只在原子层较真，其余按规则放开；同时保留各领域的看板入口，部门的东西还在，只是底下的数是同一套。

另一条决策，是把口径定义权交出去。

结果

先说成效。活跃指标降了一个量级，对口径的会议基本消失，字典成了新人入门材料，系统终于出现在决策会议上，而不只在汇报材料里。这些变化用了约两个季度，比堆指标的时间短得多。

再说后来才看清的代价。第一，owner 制把治理压在个人身上。我离开几年后听说，几位关键 owner 陆续调岗，无主指标又多起来。第二，我们把治理当成了项目，有始有终，而它是持续的职能。团队转向新系统后，「新增要过门槛」慢慢没人守了。第三，也是最私人的：那一年多里，我衡量自己的尺子一直是「建了多少」，而不是「有多少被信任」。这个误判不是团队的，是我的。

可迁移的经验

这段经历之后，我在一家券商从零建数仓，选型 Greenplum 还是 Hadoop 之前，先花一个月做指标字典；后来在电商平台组建大数据团队，把「指标先有 owner 再有 SQL」写进交付标准。这是直接的迁移。

隔了很久才看清的，是它和我现在工作的关系。我现在做全球化数据合规与架构治理，日常打交道的是埋点和权限。埋点失控是：同一个行为有五个事件名，没人敢删，不知道谁在用；权限失控是：审批一路通过，权限只增不减，审计时没人说得清某个账号为什么能看某张表。

这和当年指标失控是同一件事：没有 owner 的资产会膨胀。三者有同一种经济学：新增便宜，删除昂贵；新增是进展，删除是摩擦；新增有人推动，删除没人负责。没有 owner，它们就一直长，长到没人再信任整个体系。

能迁移的不是工具，是几条原则：数量不是成功标准，使用率和信任度才是；会膨胀的资产都要有业务侧 owner，平台不能替业务担责；把「需要人定义的」和「可按规则生成的」分开，只在前者较真；新增要有门槛，退出要有机制；最重要的，治理不是项目，是职能。前四条当年做对了，第五条是用代价学会的。

系列下一篇写券商从零建仓和 Greenplum 到 Hadoop 的迁移。另一个故事，同一个起点：先把指标说清楚，再谈架构。