一、项目背景

某连锁商超在两个省有八十多家门店，在营 SKU 数千个，补货体系长期依赖采购员个人经验：每周固定日子看一遍报表，凭感觉报一批订单，供应商那头用电话和微信接单。结果是典型的双输：畅销品经常断供——某款饮料在夏季高峰断货一周，门店只能干看着；滞销品又压满仓库——盘点时翻出过一批积压近一年的进口零食。供应商也苦：订单忽多忽少毫无规律，产能安排全靠猜。我们进场时给管理层算过一笔账：断供损失加压货资金占用，一年侵蚀的利润相当可观。

项目目标是把补货从"人拍脑袋"变成"系统建议、人做确认"，并把供应商拉进同一个协同平台。我们采用 XpShop 供应链协同平台承载，实施周期约四个月。

二、落地场景

落地分四个层次。销量汇聚层：全部门店 POS 销售数据按 SKU×门店×日粒度实时汇入中台，剔除促销异常值后形成基线销量。补货建议层：系统按安全库存模型每日计算各门店、各仓的补货建议量，采购员在工作台上批量审核，一键下发采购单。供应商协同层：供应商在协同门户接单、确认交期、报送发货信息，交期变化实时预警；对账单系统自动生成。预警层：断供风险（可售天数低于阈值）与压货风险（周转天数超标）每天推送到采购员和品类经理的工作台，滞销品自动进入清货建议清单。

我们刻意没有做"全自动下单"——补货建议的采纳与否由采购员决定，但每一次人工改动都要选原因项，这些原因数据后来成了优化模型的重要输入。

三、关键技术挑战与解决思路

第一个挑战是安全库存建模。教科书公式在真实商超场景里水土不服：需求波动不是正态的，交期也不是常数。我们按 SKU 特性分层建模：A 类高频稳定品用标准安全库存公式，服务水平定 98%；B 类波动品叠加了周内规律因子（周末销量显著高于工作日）和天气因子（饮料、冷饮类接入天气预报数据）；C 类长尾品干脆不设安全库存，改按"卖一补一"的拉式补货。促销期间的量单独走促销备货流程，不污染基线。

第二个挑战是补货建议的"平滑"。初版模型每天重算，建议量抖动很大——今天建议补 30 箱、明天变 5 箱，供应商完全无法安排生产。我们加了两层平滑：建议量变化小于阈值时不更新订单；对核心供应商按周输出滚动预测（未来四周的预计订量），预测与实际订单的偏差率作为我们自己的考核指标。供应商拿到滚动预测后备货准确率明显上升，交期也稳了。

第三个挑战是数据质量。上线初期最大的坑不是算法而是脏数据：门店库存账实不符（盘点差异未及时处理）、SKU 主数据一品多码、退货冲减不及时。补货建议再准，输入是错的也白搭。我们停下来做了六周的数据治理：主数据归一、盘点流程整改、库存事务全部闭环，之后模型效果才真正显现。这段弯路值得所有同类项目引以为戒。

案例片段（已脱敏）：安全库存分层配置片段——yaml replenish_policy:  class_A: {model: "safety_stock", service_level: 0.98,            demand_window: 28d, leadtime_source: "supplier_actual_p90"}  class_B: {model: "safety_stock+factors",            factors: [weekday_pattern, weather_temp], service_level: 0.95}  class_C: {model: "pull", trigger: "sell_one_fill_one", review: weekly} smoothing:  min_change_pct: 15      # 建议量变化<15%不更新  rolling_forecast: {horizon: 4w, share_to: core_suppliers}上线后第一个夏季高峰，饮料大类零断供，而上一年同期断供 SKU 数是两位数。

案例片段（已脱敏）：一段采购周会纪要摘录——"系统建议采纳率本周 84%，人工上调的 31 单中 19 单事后证明系统建议更准；下调的 12 单中 9 单人工正确，主因是门店周边工地停工信息系统不掌握。"这类复盘每周做，模型和人各自的盲区都在收敛。

四、效果数据

上线六个月后的数据（脱敏示意值）：断供工单数下降约 72%；整体库存周转天数从约 45 天降至约 33 天；压货金额（周转超 90 天部分）下降约 55%；补货建议采纳率稳定在约 85%；采购员人均管理 SKU 数提升约 60%，把省出来的精力投到了新品引进和供应商谈判上；核心供应商交期准时率从约 78% 提升到约 93%。财务口径测算，仅资金占用一项每年节省的成本就覆盖了项目投入。

五、可复用经验总结

第一，补货先有销量汇聚再谈建模，数据治理不做扎实，任何模型都是空转，我们那六周的"停工治数"是全项目最值的投入。第二，SKU 要分层施策，A/B/C 类的需求特性完全不同，一套公式打天下必然失败。第三，建议量要平滑，供应商需要的是可预期的订单节奏而不是每天变脸的数字，滚动预测共享是供应商协同最实在的抓手。第四，保留人在回路并记录人工干预原因，人机各有盲区，原因数据是双向校准的养料。第五，协同优于口头，供应商门户把接单、交期、对账全部线上留痕，交期准时率的提升一半功劳在"透明"二字。

复盘下来，这个项目最大的价值不在算法多先进，而在把采购员从重复劳动里解放出来。上线前我们算过，一个采购员每天约三个半小时耗在打电话催货、对账、救火断供上，系统承接 routine 后，这些人转去做选品谈判，供应商谈判的条款肉眼可见地变好。我们也踩过一个坑：早期建议单太灵敏，采购员被淹没后干脆不看系统，反而退回 Excel。加了平滑之后单量降六成、质量升，人才重新信任工具。这条'建议单要少而准'的经验，后来成了我们所有补货类项目的默认配置。还有个细节：我们把采纳率当核心指标而非生成量，上线次月才 40%，拉着采购员逐条看被忽略的单子，发现阈值对促销期不敏感，补了外生因子后到 85%——辅助系统的成功标准是'被信了多少'而非'生成了多少'。这也反过来说明，补货类项目别急着堆模型，先把人的工作流接住最要紧。