模型算完只是一半：结论怎么才能真的落到门店

我们复盘过不少半途而废的分析项目，失败原因很少是模型不对，绝大多数是同一件事：结论到了一线，没有变成动作。下面几条是我们后来固定写进交付清单的东西。

结论必须落到”谁、在哪个系统、改哪个数“

“建议优化备货策略”这种话没有执行入口。可执行的版本长这样：区域经理每周一在订货系统里，把这 37 家门店的午市备货系数从 1.0 调到 0.85。谁、什么时候、在哪、改什么，四个要素齐了才叫落地方案。

所以我们在立项阶段就会问：如果模型算出来是这样，谁来执行？他在哪个系统操作？这个操作需要谁批？答不上来，说明这个项目要么找错了对接人，要么解决的不是真问题。

先给一小部分门店试，别一次铺全国

再有把握的模型，第一次上线也应该是灰度的。选一批有代表性的门店（不同城市层级、不同店型、不同业绩水平）先跑 4–8 周，同时留一批对照门店。这样做有两个好处：一是真出问题损失可控；二是有了对照组，效果才说得清——否则销量涨了，你分不清是模型的功劳还是当月天气好。

对照组是最容易被砍掉、也最不该砍的一环。没有它，项目结束时你只有一个说不清的“感觉有效”。

把结论翻译成一线看得懂的语言

店长不需要理解分位数和置信区间，他需要知道“今天这个数靠不靠谱、要不要自己再加点”。我们的做法是把模型输出转成三档提示：正常（照建议执行）、注意（不确定性偏高，建议留缓冲）、人工确认（有异常因素，请结合现场判断）。背后是统计量，前台是一句人话。

留一个“我不同意”的出口，并把它记下来

一线一定会遇到模型没考虑到的情况——门口修路、隔壁办活动。硬性要求必须执行只会逼出阳奉阴违。更好的做法是允许覆盖，但要求填一个简单的原因，然后把这些覆盖记录收集起来。

这批记录是金矿：它告诉你模型在哪些场景系统性失灵。我们见过好几次，模型的下一次迭代提升，主要来源就是分析这些“人工推翻”的样本。

约定复盘的时间和口径，写进合同

项目结束不等于结论生效。上线 4 周、8 周各做一次复盘，看的是什么指标、和什么比、达到多少算成功——这些要在项目开始时就写好，不是结束后再商量。事后才定标准，双方都会不自觉地往对自己有利的方向解释。

一个判断项目会不会烂尾的粗糙指标

看对接人是谁。如果对接的是数据部门，交付物大概率停在数据部门；如果对接的是要为这个决策结果负责的业务负责人（供应链总监、运营 VP），落地概率高得多。我们现在会主动要求业务侧的人参加中期评审——不是为了汇报，是为了让最终要用这个结论的人，在结论成型的过程中就在场。