去年我接手了一个零售供应链侧的预测与仓配规划项目标题写的是“菜鸟-需求预测与分仓规划”听起来像个练手demo实际做起来牵扯到的数据链路、库存策略和跨部门协作比想象中复杂得多。这个项目要解决的核心问题并不高深预测未来一段时间每个区域、每个仓库、每个SKU到底会卖出多少货然后决定这批货应该提前放在哪个仓放多少。但就是这两件事拆开做都能出活合在一起做就经常打架。预测说A区域要爆量但货全堆在B区域的仓里结果A区域订单发不出去B区域库存滞销。这篇文章就围绕这个项目把我踩过的坑、验证过的思路、以及最终沉淀下来的那套计算与规划方法完整拆开说清楚。1. 为什么需求预测和分仓规划必须放在一起做1.1 先看清楚这类项目到底解决什么问题很多人第一次接触“需求预测与分仓规划”时容易把它理解成两件独立的事先做个销量预测模型再做个库存分配模型。实际上这两件事是强耦合的。需求预测的输出不只是“全国总共卖多少”而是要落到“哪个区域卖多少”“哪个仓覆盖的区域卖多少”“哪个SKU在哪个渠道卖多少”。分仓规划则是在这个粒度上回答“每个仓应该备多少货”。如果只做全国总量预测然后按历史销量占比把货分到各个仓会遇到一个典型问题促销、季节性波动、区域偏好变化会让历史占比失真。比如某款商品在华东地区因为一次直播带货突然起量按历史占比分货的话华东仓的货第二天就卖光了而西南仓的库存还在慢慢挪。分仓规划必须依赖需求预测的区域粒度输出预测的粒度不对规划做得再精细也没用。1.2 预测准了但分仓不对照样成本翻倍还有一个常见误区认为只要预测准确率够高分仓随便分一分就行。实际情况是预测准确率哪怕做到90%以上如果分仓策略不合理履约成本依然居高不下。原因在于预测解决的是“总量对不对”的问题分仓解决的是“货在不在对的地方”的问题。总量预测准确但货放错了仓就会产生大量跨仓调拨、加急快递、甚至缺货赔偿。这些成本往往比预测误差带来的库存持有成本还要高。在我做的这个项目里有一个SKU的预测准确率已经做到92%但因为分仓时没有考虑区域内渠道结构的差异——该区域线上订单占比高、线下门店补货占比低——导致线上订单大量需要从外仓调拨。后来把分仓策略从“按销量占比分配”改成“按渠道时效约束分配”同样的预测结果调拨成本直接下降了30%左右。提示如果你正在做类似项目建议一上来就把“预测”和“分仓”放进同一个指标体系里衡量不要分开考核。分开考核的最后结果一定是预测团队追求总量准确率分仓团队追求库存周转两边各自达标但整体成本没降。2. 需求预测不是套一个LSTM就完事2.1 预测粒度怎么定从“区域总销量”到“仓SKU天”的四级拆分需求预测的第一个关键决策是预测粒度。我见过很多项目一上来就按“SKU天”做预测结果数据稀疏得一塌糊涂很多SKU在大部分日期销量为零模型根本学不到有效信号。也有一上来只按“品类区域周”做的粒度太粗分仓时完全没法用。在这个项目里我们最终采用的是四级粒度拆分一级SKU品类维度。目标是最小存货单元的未来需求总量建模时用长周期趋势、季节性和外部事件特征。二级SKU区域维度。在总量基础上预测各区域的销量占比重点捕捉区域偏好变化和促销投放差异。三级SKU仓配覆盖维度。结合仓的覆盖范围把区域销量映射到仓级预测。四级SKU仓天维度。用于补货计划和安全库存计算的最终输入。每一级预测不一定都用同一个模型。一级和二级通常用机器学习模型比如LightGBM、XGBoost因为特征空间大、非线性关系多三级和四级反而可以用一些规则加统计模型因为在总量和区域占比已经确定的情况下仓级和日级的预测波动性相对可控规则加统计会更稳定。2.2 数据清洗与特征工程的三个隐藏坑预测模型的准确率至少一半取决于数据和特征工程。这个项目里遇到的三个坑很有代表性值得展开说一说。第一个坑是促销数据的口径不统一。运营那边记录的促销活动有时候按订单维度记录有时候按SKU维度记录还有时候只记录了大促名称没有记录促销力度。我们一开始直接把促销标记作为特征丢进模型结果模型学出来的规律是“有促销就销量高”完全忽略了促销力度、促销时长和促销渠道的差异。后来花了两周时间把促销数据做清洗每个SKU每天的促销标记拆成“是否参与大促”“促销折扣率”“促销渠道数”“活动剩余天数”四个特征模型效果才明显提升。第二个坑是异常值的处理方式。供应链数据里的异常值比如某天某个仓的销量突然激增往往不是真实的需求增长而是因为补货集中在某一天到货或者某个大客户一次性下了大量订单。如果不做处理模型会把这种一次性的脉冲当成趋势学进去导致后续预测偏高。我们的做法是先识别异常值再进行“去脉冲处理”也就是把超出历史分位数且不可解释的销量值替换为历史均值或中位数而不是直接删掉——直接删掉会破坏时间序列的连续性。第三个坑是节假日效应的建模。很多日期特征比如“星期几”“是否月初”“是否节假日”直接丢进模型也能用但效果一般。更好的做法是把“距离最近节假日的天数”“节假日前后第几天”“是否假期结束后的回归日”这些相对位置特征加上。比如春节前一周和春节后一周的销量模式完全不同只有“是否节假日”这个特征根本无法捕捉这种差异。2.3 模型选型什么时候用统计模型什么时候上机器学习我的经验是不要迷信复杂模型。在这个项目里我们同时跑了ARIMA、Prophet、XGBoost和LSTM四个模型做对比。实验结果非常清晰模型SKU区域周预测MAPESKU仓天预测MAPE训练耗时ARIMA34%41%极短Prophet31%38%短XGBoost26%33%中LSTM27%35%长XGBoost在区域粒度上有明显优势但在仓天粒度上和Prophet差距不大LSTM在数据量不足时表现还不如XGBoost。最终我们采用了XGBoost作为主模型、Prophet作为兜底模型的策略当某个SKU的历史数据量不足90天时自动切到Prophet数据量充足时用XGBoost。这样既保证了整体准确率又避免冷启动问题。注意不要一上来就上LSTM。时间序列预测不是深度学习的强项场景尤其是在数据量小、周期性强的供应链数据上树模型往往更稳定。如果真的要试深度学习也要先跑通XGBoost和Prophet这两个基线再考虑是否值得为1%-2%的准确率提升付出数倍的训练和调参成本。3. 分仓规划库存位置决定了履约成本的下限3.1 仓网分层的底层逻辑区域仓、中心仓、前置仓的角色差异分仓规划的基础是仓网结构。不同定位的仓在规划时的目标函数完全不同。中心仓CDC一般设置1-3个承担全局库存蓄水池的作用。它的核心目标不是时效而是库存集约化——把不确定的需求集中在一起利用“风险共担”效应降低总安全库存。区域仓RDC覆盖若干个省或大区核心目标是时效与成本平衡。区域仓的库存要能满足正常情况下80%以上的订单当日或次日达但同时要避免重复备货。前置仓FDC离消费者最近核心目标只有一个——时效。前置仓不可能备所有SKU通常只备高周转SKU库存深度小、补货频率高。在项目里我们把仓网抽象成三层用一个简单的规则做了定位划分如果某个仓的覆盖区域内日均订单量小于某个阈值就把这个仓视为“区域仓下的一个波次补货点”而不是独立规划节点。这样做的好处是避免过度细化导致补货计划过于碎片化。3.2 库存在仓间的分配策略从“比例分配法”到“时效-成本约束法”分仓规划的核心是库存在仓间怎么分配。最朴素的做法是按历史销量占比分配但这个做法有两个天然缺陷一是历史占比滞后于真实需求变化二是完全没有考虑仓间调拨成本和时效约束。在这个项目里我们最终采用了时效-成本约束法核心逻辑如下首先确定每个仓库覆盖区域内的服务水平约束比如“95%的订单要在48小时内到达”。这个约束会转换成每个仓的最小库存深度。其次计算每单位商品放在不同仓库的边际履约成本包括存储成本、出库成本和调拨成本。最后在总库存一定的约束下用线性规划求解每个仓的分配量目标函数是总履约成本最小化同时满足时效约束。这个方法的关键在于第一步也就是服务水平约束怎么量化。我们用的公式是某仓最小库存深度 日均需求 × (采购提前期 补货周期) 安全库存 安全库存 Z × 需求标准差 × 提前期标准差系数的平方根这里的Z值根据服务水平确定比如95%服务水平对应Z1.6599%对应Z2.33。这个公式不复杂但很实用把“预测的不确定性”转化成“库存的确定性”是连接预测和规划的桥梁。3.3 安全库存和补货触发点怎么联动起来安全库存如果只是算出来放在那里不跟补货触发机制联动就只是个数字。在项目里我们把安全库存作为补货触发点的核心要素形成了一套简单的补货规则再订货点 日均预测需求 × 补货提前期 安全库存 目标库存上限 日均预测需求 × (补货提前期 补货周期) 安全库存 × 1.5当仓内可售库存低于再订货点时触发补货补货量 目标库存上限 - 当前可售库存 - 在途库存。这套规则看起来简单但实际运行中有一个非常关键的细节日均预测需求必须用滚动预测值而不是历史平均值。如果用历史平均值当需求趋势向上时补货永远慢半拍安全库存会被持续消耗当需求趋势向下时补货又会过于激进造成库存积压。我们每一版补货计划都要求预测团队给出未来7天和未来30天的分仓预测并用滚动的方式进行更新。每周一重新计算一次再订货点和目标库存上限周三和周五各做一次微调。这样既保证了计划的稳定性又能快速响应促销和突发需求。4. 预测与规划如何闭环把预测误差变成库存动作4.1 滚动预测机制T1、T7、T30为什么同时要看需求预测的产出不是一张静态的表而是一套滚动更新的计划。在这个项目里我们同时维护三个时间维度的预测T1日预测主要用于仓内波次计划和当天补货确认要求快速响应准确率不是第一目标及时性才是。T7日预测用于补货计划的核心输入决定未来一周每个仓的补货量和补货节奏。T30日预测用于仓网规划和库容准备特别是大促前的库存预分配。这三个时间维度不是各自独立的而是层层校准的关系。T30预测给出了一个总量方向的判断T7预测在这个方向上进行细化T1预测则用于T7预测的偏差修正。如果T1的实际销量连续几天明显偏离T7预测我们能很快识别出预测偏差并主动修正T7和T30的后续预测。4.2 预测偏差的监控与纠偏不要等月底算总账预测偏差的监控比预测本身更重要。如果只按月度统计预测准确率等发现预测不准的时候库存问题已经爆发了——该补的货没补不该补的补了一堆。我们在项目里设置了三层监控机制第一层是日粒度偏差监控。每个SKU仓维度计算实际销量与预测值的偏差绝对值超过阈值通常30%就告警。这一层主要用来发现问题。第二层是周粒度结构偏差监控。按区域和品类汇总看结构性的偏差方向。比如华东区域的整体预测偏低那不是某一个SKU的问题而是区域特征没学到需要调整区域维度的特征输入。第三层是月度偏差复盘。把每个SKU仓组合的偏差率分布拉出来识别出哪些SKU是“持续预测偏高”哪些是“持续预测偏低”再针对性地调整模型参数或分仓策略。提示偏差监控的关键不是追求零偏差而是要理解偏差的来源。是数据问题就修数据是模型问题就调模型是业务变化就更新业务假设。最常见的错误是把所有偏差都归结为模型问题结果调了一个月参数发现是促销数据口径变了。4.3 需求感知与分仓共振把“卖得快”的货往前推当预测偏差出现的时候不同SKU的处理策略应该不一样。我们按销量稳定性和偏差方向把SKU分成四类SKU类型销量特征偏差特征分仓策略稳定快销品日均销量高、波动小偏差率低保持各仓高库存深度按销量占比分配波动快销品日均销量高、波动大偏差率中等提高安全库存增加补货频率稳定慢销品日均销量低、波动小偏差率低集中存储减少分布仓数长尾新品日均销量低、波动大偏差率高前置仓少备货中心仓多备货按需调拨这套分类方法的价值在于不是所有SKU都值得每个仓备货。长尾新品如果也按快消品的标准分布到所有前置仓库存成本会迅速吃掉毛利空间。而波动快销品如果只在中心仓备货时效又达不到要求。分类分仓本质上是在“库存成本”和“履约时效”之间找平衡点。5. 计算逻辑与实际落地中的细节问题5.1 关于需求预测与分仓规划的最终落地建议最后聊几个项目落地过程中特别值得注意的细节问题这些在正常的教材和文档里很少会写但实际遇到时非常影响项目推进节奏。第一个细节是预测的“冷启动”问题。新SKU没有历史数据怎么预测我们用的是“相似品映射法”找到同品类、同价格带、同渠道结构的现有SKU用它们的销量曲线作为新SKU的初始预测再根据新SKU上架后的实际表现逐步修正。这个方法不算多高级但简单有效比冷启动模型好落地得多。第二个细节是分仓规划中的“库存不可拆分”约束。很多规划模型默认商品可以在仓间无限拆分但实际业务里一箱货、一件货往往有最小起订量。比如一件商品一箱12个预测某仓需要补5个但补货一箱是12个那实际补货量就是12安全库存会高于理论值。这种约束在做线性规划时就要提前设置否则模型给的方案在实操里根本没法执行。第三个细节是极端需求的“熔断机制”。每年都会碰到几次突发爆量比如某个商品因为短视频突然火起来几分钟内订单量是正常水平的几十倍。这种情况下预测模型和分仓规则都是失效的要提前准备一套“熔断预案”当某个SKU的实时销量超过阈值时自动停止该SKU的其他仓间调拨优先保障核心仓库存同时触发紧急采购和预售机制。第四个细节是预测结果的可解释性。算法给出来的预测结果业务部门不一定敢直接用。他们更相信“为什么预测高”的合理解释。所以每次输出预测结果时我们会附上一个简单的解释模块哪些特征贡献了预测值的上升哪些特征贡献了下降。这看起来像是额外工作但对推动业务落地非常有效能让业务从“挑战预测结果”转向“一起优化预测”。5.2 复盘从这套项目里沉淀的三条核心经验做完这个项目我最大的感受是需求预测和分仓规划不是两个独立的算法问题而是一套围绕“库存效率”的决策系统。预测的质量决定了库存成本的上限分仓的质量决定了履约成本的下限两者必须联动优化。第二条经验是模型是必要的但不应该是重心。项目周期里真正花在调模型上的时间不到四分之一剩下的时间都花在数据清洗、偏差分析、业务沟通和规则梳理上。如果一上来就埋头调模型很容易做出一个在测试集上很漂亮、在真实业务场景里却完全不可用的方案。第三条经验是从简单方案开始再逐步叠加复杂度。我们最开始用的分仓规则就是简单的周销量占比分配模型也是先用Prophet跑通全流程验证数据链路和业务口径没有问题再逐步替换成XGBoost、加入时效约束、做分类分仓策略。每一步优化都能用业务指标衡量这样迭代起来心里才有底。如果你正在做类似的需求预测与分仓规划项目我的建议是先把手里的数据盘清楚把预测粒度和分仓策略的匹配关系想明白再动手建模型。数据、模型、策略、监控四件事缺一不可。哪怕先从一个SKU、一个区域、一个仓库开始做闭环也远比一开始就铺一个大而全的方案更务实。