ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

需求预测与分仓规划:供应链库存效率提升的实战拆解

需求预测与分仓规划:供应链库存效率提升的实战拆解 做供应链的人应该都有同感“需求预测”和“分仓规划”这两件事放在招聘JD里是两种岗位落到业务上却是一根绳上的蚂蚱。我在菜鸟体系里接触过不少类似的智能供应链项目这个标题看起来朴实实际上把电商物流最核心的库存效率问题全点出来了货备多少、备在哪、什么时候补过去这三个问题不解决后面谈时效、谈体验、谈成本都是空的。这个项目最值得说的不是哪个模型多精妙而是怎么把“预测”和“仓网”这两套逻辑真正咬合在一起。很多团队做预测只交付一个数字做分仓只拍一个网络拓扑结果预测报告做得漂漂亮亮仓库里该缺货还是缺货该积压还是积压。所以这篇复盘我想从业务定义、预测模型、分仓决策到落地踩坑把这一整条链路完整拆一遍。适合刚接手供应链计划、数据产品或者在做仓网优化项目的同学参考至少能少走几个月弯路。1. 先把业务问题定义清楚预测的是销量还是发货量需求预测看着是数据问题第一步却往往是业务问题。不把口径定清楚后面所有模型都是在给错误的目标做拟合。1.1 预测口径前台销量、GMV还是出库件数做电商的人对几个数字应该很熟前台页面上的销量、交易系统里的GMV、仓库实际发出的件数。这三个数字在某些场景下差别巨大。预售商品可以计入前台销量但仓库今天根本不出货用户下单之后退款了GMV记了一笔仓里不用拣货还有拦截、拒收、改地址每一个异常订单都在制造预测口径的偏差。在菜鸟这种仓配一体的场景里需求预测最终是给仓储作业和运输计划用的所以我建议直接把预测目标定成“可执行出库量”也就是某个SKU在某个仓库、某一天实际需要拣货并发出的件数。这个口径的好处是和WMS、TMS的执行数据完全对齐模型预测出来的数字可以直接对接到补货逻辑和产能排班。如果非要看GMV那只能作为辅助参考不能作为库存补货的依据。口径定错会引发一个典型问题前台销量看着很高预测模型按历史销量训练结果仓库库存早就被预售占用实际可售库存为负补货单却迟迟没触发。最后消费者等货运营催仓数据团队背锅。其实根子就在一开始没把“预测目标”和“执行目标”统一。我一般在项目启动前会和业务方对齐一个口径表至少包含四类订单口径、支付口径、出库口径、签收口径并且明确每个口径对应哪些状态字段。别看这一步简单能做到的团队真不多。1.2 预测粒度SKU×仓×日还是类目×区域×周口径定了下一个问题是预测的粒度。菜鸟的仓网是典型的区域仓加前置仓布局订单从哪个仓发决定了时效和成本。所以预测必须落到“SKU仓日”这个最细粒度也就是每个SKU在每个仓库每天的出库量。只有到这个粒度分仓规划才有意义否则你只知道全国要卖一万件却不知道这一万件该放杭州仓、广州仓还是成都仓等于白预测。但“SKU仓日”粒度听着干净做起来非常痛。长尾SKU在单仓单日可能只有零星的几单用任何模型都很难预测准新品的生命周期只有几周历史数据不足大促期间的流量剧变让日常模型训练出来的参数全部失真。所以我不建议所有SKU都硬上同一个模型而是分层处理。实际项目中我的做法是高周转SKU日销几十件以上用细粒度时序模型或机器学习模型逐仓逐日预测腰部SKU用类目和区域维度的模型再做仓内比例拆分长尾SKU干脆不单独预测直接合并到类目池里做整体水位管理配合安全库存兜底。预测的时间窗口一般滚动到14天、30天、90天三个版本14天给补货30天给调拨90天给仓网规划。这个分层策略看着不智能但非常实用。因为模型在稀疏数据上强行预测出来的数字误差大到没法用与其得到一个好看的“伪精准”结果不如承认不可预测用策略去补位。1.3 需求类型拆解日常需求、促销需求与新品需求如果把所有销量混在一起建模最后得到的是一堆互相污染的参数。日常需求通常平稳有周期性促销需求则是脉冲式的受流量、折扣、库存深度影响新品需求没有历史数据完全依赖相似品和流量预测。三者放在一个模型里模型会非常困惑。我习惯在特征工程和模型训练阶段就把需求拆开。日常需求用历史同期加趋势季節性建模促销需求单独看活动因子比如大促期间的流量倍数、转化率变化、价格弹性新品需求则用同品类老品做冷启动。尤其是大促的那一波一定要把活动标识、报名商品、折扣力度作为特征喂进去否则预测出来的数字会让人怀疑人生。拆完之后还要合回来。库存补货看的是总需求所以最后要把基线预测和增量预测相加而不是在同一个模型里“顺便预测”。这个加法要符合业务节奏比如大促预热期的预估单量、正式期的爆发量、返场期的回落量每一段的预测因子都不同。2. 需求预测的落地路径模型选型与特征工程很多同学一上来就聊DeepAR、Transformer、XGBoost我的建议是先别急着追新。模型选型是一个“从简单到复杂、从粗到细”的演进过程先用简单模型跑通链路再逐步替换否则你连bad case归因都做不清楚。2.1 先有基线模型再做差异化模型任何需求预测项目第一个里程碑都应该是一个可解释的基线模型。最简单的做法是取过去四周同仓同SKU的日均出库叠加周几系数、月末效应、节假日参数形成一个基准预测。这个基线可能不准但它能帮你检验数据管道、口径、评估体系是否正常。当基线模型稳定之后再按SKU分层引入更复杂的模型。在菜鸟这个项目里我们当时对高周转SKU用的是LightGBM加上时间序列特征因为树模型对特征交互的拟合能力强也能自然处理SKU、仓库、活动等类别特征。对部分特爆款也试过用时序深度学习模型做多步预测效果没有比LightGBM拉开质的差距但训练和调参成本高不少。关于模型我见过一个误区以为模型越复杂越准。实际上在高波动的电商场景里误差的主要来源不是模型能力不够而是数据里掺了太多业务异常。比如某个链接缺货两周复售后销量反而暴涨模型如果不知道断货事件很容易把这两周的低值算进历史均值。这类问题靠特征工程解决而不是靠换模型。2.2 特征体系除了历史销量还能利用什么销量预测的特征可以分成几类历史序列特征、日历特征、业务事件特征、外部环境特征。历史序列特征包括滞后N天的销量、滚动均值、滚动标准差、最近一天销量、周同比等。日历特征包括星期几、是否月初月末、是否节假日、距离最近大促的天数。业务事件特征包括价格、折扣、是否参加活动、库存深度、是否断货恢复。外部环境特征包括天气、热搜指数、流量预估等。这里我特别想讲两个容易被忽视的特征库存深度特征和生命周期特征。当可售库存接近零时销量会被截断模型看到的“实际销量”是被拍脑袋补货和限购扭曲过的。如果补货跟不上明明需求很强历史销量却很低模型会学到一个错误规律。所以我会把“当天库存是否断货”“断货持续天数”“恢复后第几天”这些字段作为特征引入让模型学会识别断货影响。生命周期特征则是给每个SKU打一个阶段标签导入期、成长期、成熟期、衰退期不同阶段的趋势和方差完全不同分阶段建模或加对应特征能明显降低预测误差。特征工程做完之后一定要做数据版本管理。我见过太多项目业务方改了一个字段定义第二天模型输出全变了排查半天才发现是上游表结构变了。预测链路越长越需要固化特征生产流程给每个模型的输入输出打上版本号。2.3 模型评价与纠偏别只盯着MAPE预测模型常用的指标有WAPE、MAPE、RMSE和Bias。很多人喜欢看MAPE但这个指标对低销量SKU特别不友好。一个日销1件的SKU预测错了1件MAPE就是100%一个日销1000件的SKU预测错了50件MAPE只有5%。如果直接按所有SKU的MAPE求平均长尾 SKU 会把整体指标拉得很差但业务上它只影响一两件货根本不需要精细预测。我建议评价指标分两层一层用WAPE看整体加权误差公式是绝对误差和除以实际值之和一层用Bias看系统性偏差公式是预测值之和减去实际值之和除以实际值之和。Bias比MAPE更贴近库存决策因为正的Bias意味着整体高估会导致库存积压负的Bias意味着整体低估会导致缺货。库存计划里我们甚至可以主动设定目标Bias比如爆款SKU的Bias略微为正保证现货率普通SKU的Bias尽量接近零控制周转。模型上线不等于工作结束还需要建立滚动回测机制。每周用历史数据重放一遍模型看最近四到八周的预测误差是否在容忍范围内一旦误差连续恶化马上排查原因。排查时先看数据管道是否异常再看业务事件是否没有被识别最后才怀疑模型参数需要重训。3. 分仓规划怎么做从预测结果到仓网布局需求预测只回答“要备多少货”分仓规划回答“货放在哪里”。这两个问题必须串联起来看否则很容易出现全国库存量看着充足但区域间调配不动、时效达不到的尴尬局面。3.1 分仓的本质把正确数量的货放到正确的仓不同地区的消费者购买偏好差别很大同一个SKU在江浙沪可能是日销上千的爆款在西北可能一周才卖几件。分仓规划的第一步就是把第一节算出的预测值按仓域拆解得到每个SKU在每个区域的需求分布。这一步做不好后面全是空中楼阁。拆解的方法有两种一种是先做全国性预测再按历史占比拆分到仓另一种是直接在每个仓维度做独立预测。前一种实现简单但拆出来的数字很容易在低销量SKU上失真。后一种更准但需要每个SKU在每个仓都有足够的历史样本。我实际用的混合方案是高销量SKU用仓级预测中低销量SKU用区域预测并叠加仓域吸收系数。所谓吸收系数就是根据收货地址聚类算出每个仓可以覆盖哪些区域的订单再把区域需求映射到仓。分仓规划还要考虑一个“风险共担”效应。把库存集中在一个大仓虽然时效变差但总安全库存可以降低把库存分散到多个前置仓时效好、覆盖广但每个仓都要备一份安全库存总库存就会上升。这个权衡在SKU层面差异很大高价值、长尾、需求波动大的商品适合集中存放低价值、高频、竞争激烈的商品适合前置铺货。这就是分仓里最经典的ABC分类逻辑。3.2 分仓数量与布点不是越多越好很多业务方会有个直觉仓越多时效越好客户体验越好。但仓越多租金和运营成本越高更关键的是每个仓都要放库存一旦需求波动某仓缺货、某仓积压的概率也在增加。所以分仓数量本质上是成本、时效、库存三者的一个权衡问题。在做布点规划时我习惯先拿历史订单数据做发货地址聚类找到几个候选城市。然后把这些候选仓组合成不同方案比如全国3仓、5仓、8仓、12仓跑一遍仿真把真实历史和预测数据灌进去按不同仓储成本和运输时效计算履约率、现货率、库存周转和总成本。最后不是选成本最低的方案也不是选时效最好的方案而是选一个“时效满足业务底线、总成本最优”的平衡点。以一个简化案例来说全国单仓方案库存周转天数大约25天但次日达覆盖率只有20%五仓方案库存周转天数上升至32天次日达覆盖率能达到60%八仓方案次日达覆盖率进一步到75%但库存周转天数到了40天且部分前置仓日均单量太低仓储人工成本明显增加投资回报率已经下降。这时候需要管理层拍板是用成本换体验还是用体验换效率。预测数据和仿真结果在这中间是拍板依据不是替代决策。3.3 补货与调拨让预测结果真正进入库存决策分仓布局定下来之后日常运转靠补货和调拨。补货计划的核心公式不复杂净需求 预测未来N天需求量 - 当前可售库存 - 在途库存 目标安全库存。这里的N就是补货提前期包括采购周期、运输时间、入库上架时间。预测越准安全库存就可以定得越低。安全库存的计算不能只看均值还要看需求波动和提前期波动。常用的安全库存公式是SS Z × σ_dlt其中Z是服务水平对应的标准正态分位数σ_dlt是提前期内需求的标准差。如果需求不稳定还要在前面的公式里考虑预测误差的分布而不是只依赖历史均值。我在实际项目中会把预测模型的Bias作为系数校准安全库存模型系统性偏低时安全库存自动加高模型偏移校正后再调回正常水平。仓间调拨则是在静态分仓之后做的动态兜底。当某个仓的库存水位低于未来两周预测需求且另一个仓有充足库存时系统生成调拨建议。调拨触发不能只看单一库存阈值要结合剩余可售天数、调拨提前期、干线运输成本、断货风险综合判断。比如某仓剩余可售天数只有3天从其他仓调拨需要5天那直接调拨就来不及这个仓应该立即触发紧急补货或对消费者展示预售/延期。这些逻辑如果不在系统里固化成规则分仓规划就永远停留在PPT层面落不了地。4. 实操中掉过的坑和排查方法再好的方案上线过程中总会遇到一堆意外。下面这几个坑是我在菜鸟这类供应链项目里反复遇到的写出来给大家排雷。4.1 预测不准可能是数据口径先出了问题有个让我印象很深的case某个类目的预测误差从10%突然飙到30%模型代码没人动过训练数据也没异常。排查到最后发现上游订单表里新增了一个“多仓拆单”逻辑一个订单如果跨仓发货拆成多个子订单订单表的行数变多导致历史“订单量”和“出库量”的关系被打破。而模型训练时用的是订单口径执行端用的是出库口径两边没有对齐。这种问题在大型供应链系统里非常常见最有效的排查方式是先画数据血缘图明确每个字段从哪个业务系统来、经过哪些清洗、变成什么口径。然后每天跑一个一致性校验订单量、支付量、出库量、签收量之间的逻辑差异是否在合理范围。只要校验不通过测试环境里的预测模型就不放量先把数据问题解决再谈精度。4.2 全国预测很准拆到仓就崩了这是分仓规划最常见的痛点。全国口径的WAPE只有12%看起来很不错但拆到仓级之后很多仓的误差超过40%。原因是各地需求结构不同全国模型拟合的是平均规律拆仓占比一波动预测误差就跟着放大。解决思路有两个。一是高销量SKU坚持仓级建模不要让占比拆分去做颗粒度转译二是对低销量SKU不要硬拆到仓而是采用“大区池仓内比例”的方式用策略兜底。另一个是可以通过仓间调拨来吸收误差即使仓级预测不准只要大区总库存合理调拨可以缓解局部缺货。前提是调拨频率和时效得跟上否则预测误差会直接转化成缺货或积压。4.3 新品和大促是没有历史数据的“双重灾区”做预测最怕遇到没有历史规律的东西新品和大促就是典型。新品上线没有历史销量我的冷启动方法是找同类目、同价格带、同流量层级的老品作为参考再根据新品近期流量趋势和转化率做缩放。也可以在模型里加入“新品年龄”特征让模型自己学习一个生命周期曲线。大促就更难了因为每次活动机制、流量渠道、参与商品都不一样。对于大促预测我一般会和运营团队提前对齐三件事整体流量目标、折扣计划和库存深度约束。然后基于这几个输入做情景预测给出悲观、中性、乐观三版需求。这样业务方可以根据大促实际进度在D-7、D-3、D-1三个节点不断刷新预测数值而不是拍死一个数字不动。这个“滚动刷新”机制比把模型调到多精确都管用。最后再说一个个人体会。需求预测与分仓规划这类项目真正难的不是算法而是让业务团队信任你的输出。我刚做项目的时候总想着优化模型指标后来发现业务方不关心WAPE从12%降到11%他们关心的是你为什么说这个品下周会缺货备货依据是什么如果预测结果不能给出可解释性的提示业务方最终还是会凭经验拍脑袋系统再准也推不动。所以我后来都会在预测报表里额外输出“预测原因摘要”本周销量上涨是因为活动因素、季节因素还是历史趋势。这种解释能力才是预测模型能被业务接受的关键。这个经验比任何模型参数都值钱。
返回列表