很多人做数据分析，第一次被老板点名，不是因为 SQL 写得慢，而是因为同一个「订单数」，三个部门能报出三个数。视频作者「不知渭河」说，他第一次搭指标体系是入行一年半，起因就是老板发现全公司看数的口径太乱。这事听着像做报表，真做起来完全不是。📊

他把整个过程拆成好几层，我觉得比网上那些模型图实在得多，因为每一层都对应着一个具体的、会挨骂的场景。

第一层：先解决口径打架

最初的诉求特别朴素：把现存的指标收集起来，看看各部门到底怎么算，能不能整理进一张报表，让管理层的月报、周报对得上。这一步做成的标志，不是报表多漂亮，而是老板能快速定位到大部分问题。

举个共享出行的例子。广州下大雨，当天订单掉了一百万。这一百万掉在哪？80 万来自降水，20 万来自车辆；车辆这 20 万里，闲置车占 5 万，仓库车又占 5 万。指标要能这样一层层剥开，老板才知道该找谁，而不是听一句「今天天气不好」就散了。

这个阶段分析师干的活其实很土：写 SQL、跑业务部门调研、把口径对齐。骑行卡按 7 日留存还是 30 日留存算，定了一个，另一个口径就得跟着改，改动还会牵连下游所有报表。指标口径这四个字，背后是一堆又烦又容易出错的杂活，但它就是整套体系的地基，绕不过去。

OSM 模型能用，但它只是主干

网上流传最广的是 OSM：目标、策略、度量。作者说这套思路没错，沿着目标往下拆，要素基本不会漏，至少能保证你手上的清单是全面的。可 OSM 只给了树干，真正难的是怎么让它长出叶子，也就是指标拆解这一层。

他的原话很克制：思路是对的，但剩下的是你要靠自己的业务理解去填补。这句话其实在提醒，模型不解决脏活，脏活还得人干。

第二层：拆解是指标体系的深水区

总订单可以拆成用户乘频次，也可以拆成车辆乘频次；车辆乘频次再拆成闲置车和运营车，闲置车再往下拆成闲置天数、潜在订单损失、人力成本。每一层都会冒出一个偏「效率」的指标：说用户就看复购周期，说闲置车就看处理效率。

失联车辆：一个指标怎么从业务里长出来

他举的失联车辆最能说明问题。车锁靠太阳能板供电，晒不到太阳就失联，失联意味着资产可能丢。分析师眼里这是一个指标，业务眼里这是必须解决的结果。业务顺着原理找场景：车大多停在城管仓库里晒不到太阳，那就先确认车辆在仓库范围内，再调低定位上传频次，省电，失联数自然降下来。

顺着这个逻辑，他们又造了一个「失联车平均处理周期」，把处理时效、花了多少钱、投入多少人揉成一个人效投入产出比。指标不是拍脑袋想出来的，是从业务动作里反推出来的，所以业务一听就懂，也愿意背。

分析师要懂业务到什么程度

不用比业务更懂，但至少要把业务解决问题的思路完整走一遍，再翻译成指标。作者提炼了一条链：从目标拆到原理，从原理找到场景，从场景确认策略，再从策略回到目标上的变化。少一环，指标就是空中楼阁，看板上再多数字也只是装饰。

还有个很现实的提醒。很多分析师的成果被业务一句「这问题我早发现了」顶回来，甚至被补一刀「这个指标我们早就不看了」，根子在于从头到尾带着审查的姿态。换个姿势——我是来帮你拉通资源的——结果完全不同。同一个结论，说话的位置不一样，接受度差得远。

产出不是看板，是三件事

第一，能定位具体问题，比如订单下滑是城管仓库失联车变多；第二，能定位责任部门，失联车归资损部门，仓库车归另一个部门，老板可以直接摇人；第三，能量化影响程度，这个问题吃掉 3% 的订单，那个吃掉 1%，十几个问题里哪个最该先解决一目了然。

归因模型：把 20% 和 30% 拆开

量化这件事还有进阶玩法。同样做了两个活动，表面上对订单的影响一个 20%、一个 30%，用归因模型一算，真实贡献可能只有 10% 和 5%。这种结论写进看板，指标体系才算有了「质量」，而不是把一堆数字堆在屏幕上让人自己猜。

他还提到一个容易被忽略的落差：核心看板可能只有十几个指标，往下长却能长出几十个。留下哪个、砍掉哪个，靠的是数据说话——描述性统计能看出谁的影响最重，归因模型能拆开两个同时发生的动作各占几分。

全面、度量、组织、流程

作者最后给了自己的四步法。全面，是用指标描述所有业务动作，连未来可能发生的也留好位置，把缝隙填满；度量，是算清楚某个指标波动会带动总指标多少，老板才有依据重新审视目标；组织，是先动组织结构，指标体系才落得下去，部门职责跟指标对不上，再漂亮的体系也是纸面文章；流程，是让指标进月度复盘、进目标管理，每周每月都在管理层桌上被讨论，才叫有成果。

我很认同他最后那句话：能写进简历的，不是做了多少张看板，而是这套数据分析指标体系推动了什么问题被解决、为什么能解决。报表是副产品，业务归因才是主产品。🔍

顺带说一句，他没把 OSM 吹成万能公式，而是承认它成立的前提是目标对、策略对、部门之间没毛病。现实里这三样往往都不对，所以这套东西真正值钱的地方，是它逼着你去跟组织较劲。🧩