算法组的周报里写着：补货建议采纳率 72%。老板问：那剩下 28% 是没采纳，还是没采纳对了？会议室安静了几秒钟。
这个问题表面上是问一个率，实际上是问：建议系统到底创造了多少价值，以及出了问题该怪谁。我们花了差不多一个月，把这件事从”一个率”做成了一套归因方法。做完之后，周报上那个孤零零的 72%，变成了一张能回答四种”怪谁”的矩阵。
先定义”采纳”，比想象中难
计划员收到系统建议订 100 件，实际下了 95 件，算不算采纳？下了 0 件，是不采纳，还是那天仓库爆了根本没法收货？
我们拍板的口径是：实际下单量与建议量偏差在 ±10% 以内，算完全采纳。容差不是和稀泥，是承认计划员会做合理微调，把”微调”和”不采纳”分开。真正难的是第二种情况：没下单未必是不信系统，可能是库存已经够、在途太多、仓容爆了。归因的第一步不是算率，是把”不采纳”拆开。
观察窗：给每条建议一个公平的考期
一条建议有没有用，要看它到货之后那段日子的库存表现。建议下单日记作 t，供应商 VLT 是 L 天，采购间隔是 BP，那么这条建议的”考期”就是：
观察窗 = [ t + L , t + L + BP ]
货在 t+L 到仓，到下一次订货 t+L+BP 之前，这段时间的缺货和积压，才是这条建议要负责的。窗口之外的事算在它头上不公平，窗口之内的事漏掉了就是放水。窗口里库存分区天数不满的，整行剔除，宁缺毋滥。窗口内如果又插进来别的订单，不剔除，打个标记，后面单独分析，因为那说明这条建议的影响被污染了。
还有一个细节最容易被忽略：评估”当时预测准不准”，必须锁定建议生成那一刻系统看到的预测版本。预测每天滚动更新，拿今天的新预测去评价上个月的建议，是拿答案改考卷。
四象限：到底怪谁
把每条建议放进两个维度里：采纳了没有，当时的预测准不准。四象限一摆，责任立刻清楚：
- 预测准 + 采纳：系统的功劳区，这是价值的基本盘。
- 预测准 + 没采纳：计划员的动作值得看。如果这批建议事后证明是对的，那就是人把钱留在了桌上。
- 预测不准 + 采纳：算法的问题被忠实地执行了。这个象限最危险，因为它穿着”采纳率高”的好看外衣。
- 预测不准 + 没采纳：人替系统挡了枪，这是组织里最值钱的经验，要把这些 case 捞出来问计划员”你当时看出了什么”。
我们拉了一个月的明细（DEMO 量级：几万条建议），最大的惊喜来自第四象限。几位老计划员对某几个供应商的延迟规律了如指掌，预测还没来得及学进去，他们的”不采纳”几乎次次正确。这些经验后来被整理成规则，反哺给了策略层。归因的尽头不一定是追责，有时是挖矿。
这套方法的通用性，超出补货
现在几乎每个团队都在给业务做 AI 建议：销售建议、定价建议、投放建议。我的观察是，这些系统上线半年之后都会撞上同一堵墙——说不清自己有没有用。采纳率一个人人都能算，但它回答不了”没被采纳的那些，是系统错还是人错”。
观察窗、容差带、快照锁定、四象限，这四样东西搬到任何”AI 给建议、人来决策”的场景都成立。大模型时代这面墙只会更高：模型越像黑盒，归因越不能靠感觉。一个说不清自己价值的 AI 系统，预算被砍是迟早的事。
下一篇离开单仓视角，往网络层面走一步：仓和仓之间的关系怎么设计，RDC 到 FDC 到底该拉式还是推式。那是一个前提一改、结论全翻的故事。
附录：采纳率归因口径速查表
核心口径
| 项 | 口径 |
|---|---|
| 粒度 | 仓 × 商品 × 推荐下单日（一条推荐 = 一行） |
| 观察窗 | [ t+L , t+L+BP ]，L = 供应商物流天数，BP = 采购间隔 |
| 完全采纳 | 实际下单 − 建议量 的绝对偏差 ≤ 10% × 建议量 |
| 窗口越界 | 窗内库存分区天数不满的行，整行剔除 |
| 预测快照 | 必须锁定推荐生成时点看到的预测版本，禁止用事后预测 |
分析路径：先算总采纳率（分仓、分品类、分计划员分层）→ 未采纳先拆”客观无法采纳”（库存够/在途多/仓容满）与”主观不采纳” → 主观部分过四象限定责 → 第四象限 case 访谈，提炼人工经验反哺规则。
常见坑：拿最新预测版本评价历史建议（拿答案改考卷）；容差设 0，把合理微调全算成不采纳；不区分”没下单”与”下了小单”；观察窗随 BP 浮动时不做越界剔除。
供应链实战系列 · 第 05 篇 · 卷三「归因与网络篇」｜ 上篇：让 AI 帮你做决策 ｜ 下篇：仓网升级 文中数字均为 DEMO 示意，非真实业务数据。