sku库存:仓库新手新手问答:补货计划做不好会出现哪些库存积压
很多仓库新手以为,库存积压就是“进货太多”,但我在实际盘点和补货复盘中看到的情况往往相反:同一个仓库既有某些 SKU 堆了几个月卖不动,又有另一些 SKU 天天缺货。问题通常不在仓库面积,而在补货计划没有把销量波动、采购提前期、库存结构和商品生命周期放在同一张表里判断。
补货做不好,最先出现的并不是“库存总量变高”这么简单,而是库存逐渐失去流动性:畅销品被不断追补,滞销品继续占用库位,促销品在活动结束后变成尾货,规格相近的商品互相分流,最后形成账面库存很多、可销售库存很少、现金却越来越紧张的局面。
第一个问题是:补货计划做不好,会不会直接导致库存积压?会,但更准确地说,补货计划会通过四条路径制造积压:补货数量过大、补货时间过早、补错 SKU、没有及时停止补货。
第二个问题是:库存越少是不是越安全?不一定。库存少但经常缺货,会损失销售机会、增加紧急采购和加急运输成本;库存多但周转健康,也可能是合理的季节性备货。真正需要控制的是库存的可销售性、周转速度和现金占用。
第三个问题是:只看库存金额能不能判断积压?不能。库存金额只能告诉你资金压了多少,不能告诉你哪些商品已经失去销售机会。一个成本很低但占用大量库位的商品,可能比高价但快速周转的商品更危险。
我的核心判断是:补货计划的目标不是把仓库填满,而是让每个 SKU 在正确的时间、以足够但不过量的数量到达。如果一个 SKU 预计 30 天只能卖 100 件,却因为采购周期被误判而一次买入 500 件,那么剩下的 400 件就不是安全库存,而是潜在积压。
新手可以先不用复杂的软件模型,先把每个 SKU 的库存判断拆成四个问题:还能卖多久、多久能补到、卖不动的概率多大、占用多少钱。
例如,某 SKU 当前有 900 件,近 30 天日均销量为 15 件,库存覆盖天数就是 60 天。如果供应商提前期只有 7 天,且商品销售稳定,这个库存未必危险;但如果该商品销售高度依赖一次活动,活动已结束,未来日均销量可能降到 3 件,那么实际覆盖天数会变成 300 天,积压风险就非常高。

仓库积压很少由一次特别离谱的采购决定。更常见的过程是:第一次多买了 20%,第二次因为促销预期又补了 30%,第三次没有扣除在途库存,第四次发现销量下降却仍按旧规则补货。每次看起来都不严重,几个月后却形成一批很难处理的尾货。
因此,盘点时不能只问“这批货是谁采购的”,而要追问“这个 SKU 连续三次补货时,使用的销量数据、在途数量和库存上限是否一致”。如果每次补货都基于不同的口径,积压就会被不断复制。
第一类是稳定销售品,例如常用耗材、基础包装材料和高频日用品。这类商品的销量相对平稳,补货模型比较容易建立,但也最容易被“感觉销量不错”诱导,采购人员会在没有核对当前库存和在途的情况下提前放大订单。
第二类是活动驱动品,例如节日礼盒、促销套装、季节用品。它们的历史销量不能直接代表未来销量。活动前销量快速上升,活动后可能断崖式下降。如果把活动期日均销量直接用于常规补货,活动结束后库存积压几乎是必然结果。
第三类是长尾规格品,例如颜色、尺寸、容量差异明显的商品。单个 SKU 销量很低,但采购人员常常按照整个商品系列的销量判断。结果是系列看起来卖得不错,具体规格却长期不动,最后出现“总品类畅销、单 SKU 滞销”的错觉。
我做仓库复盘时,第一步通常不是看库存总额,而是把库存按库龄和销售状态切开。库存总额只能看出资金规模,不能识别风险来源;而按库龄分层后,问题往往会立即显现。
| 库龄区间 | 通常代表的状态 | 需要关注的问题 | 建议动作 |
|---|---|---|---|
| 0,30天 | 新入库或正常流转 | 是否高于合理库存上限 | 核对补货批量和在途数量 |
| 31,60天 | 销售速度可能低于预期 | 近14天销量是否下降 | 暂停自动补货,观察销售趋势 |
| 61,90天 | 中度积压风险 | 是否存在规格错配或活动结束 | 调整售价、组合销售或转渠道 |
| 90天以上 | 高概率形成呆滞库存 | 商品是否仍具备正常销售价值 | 清仓、退供、改包装或停止采购 |
这里的天数不是所有行业都通用。生鲜、服饰、电子配件和工业备件的库龄标准差异很大。我的建议是先用企业自身的销售周期设定阈值,例如把“正常补货周期的 3 倍”作为第一道预警线,再根据毛利和商品生命周期调整。

假设某个收纳用品系列包含 10 种颜色,过去 30 天总销量为 1,000 件,平均每天销售约 33 件。仓库新手可能会认为整个系列需求旺盛,于是按每个颜色平均补货。
但进一步拆开后,可能只有黑色和白色贡献了 760 件销量,其他 8 个颜色合计只卖了 240 件。若按平均销量给每种颜色补货,畅销色仍然可能缺货,冷门色却会持续积压。这是典型的“品类级数据掩盖 SKU 级风险”。
补货决策必须落到最小可销售单元,而不是停留在商品名称、系列或大类层面。仓库、采购和销售如果使用不同的 SKU 编码,甚至同一规格存在多个编码,补货计划会从数据源头开始失真。
“上个月卖了 300 件,这个月就补 300 件”是最常见的做法,也是在需求稳定时最容易被接受的做法。但它忽略了库存起点、在途库存、销售趋势和采购周期。
如果上个月有一次大型促销,300 件销量中有 180 件来自活动,那么本月继续补 300 件就会把一次性需求当成长期需求。反过来,如果上个月因为缺货只卖了 100 件,那么直接按 100 件补货,又会低估真实需求。
我更建议新手至少同时看三个数:近 7 天日均销量、近 30 天日均销量、近 90 天日均销量。三个数的差异本身就是重要信号。近 7 天远高于近 90 天,可能是活动或增长;近 7 天远低于近 90 天,可能是需求下滑、价格变化或供应问题。
安全库存不是一个永远不变的数字。它应当随着销量波动、供应商稳定性和服务目标变化。如果供应商平均 5 天到货、最大可能 8 天到货,和平均 20 天到货、最大可能 45 天到货,使用同一个安全库存水平显然不合理。
更危险的是,很多表格会把“当前库存低于安全库存”直接等同于“需要采购”。但当前库存可能已经包含一批在途货物,也可能有大量不可销售品,或者销售趋势正在快速下降。下单前一定要计算库存位置,而不只是看仓库实物。
库存位置可以用下面的方式理解:
库存位置 = 可销售库存 + 已确认在途库存 − 已承诺未发库存
如果一个 SKU 可销售库存为 100 件,在途 300 件,已承诺订单为 50 件,那么库存位置是 350 件。此时即使仓库实物已经低于安全库存,也未必应该继续下单。
采购单价下降并不等于采购成本下降。批量折扣只减少了单位采购价,却可能增加仓储费、资金利息、损耗、过期风险和清仓折价。
例如,某商品正常采购价为 10 元,采购 500 件;采购 2,000 件时单价降到 9.2 元。表面看,2,000 件可以节省 1,600 元,但如果其中 800 件需要半年后清仓,平均每件损失 3 元,清仓损失就达到 2,400 元,还没有计算库位和资金成本。
我在评估采购优惠时,会把“折扣节省”与“额外持有成本”放在同一个公式里:
批量采购净收益 = 采购折扣节省 − 额外仓储成本 − 资金占用成本 − 预计清仓损失 − 额外损耗成本
只要净收益不明确,低价采购就不能被视为更优方案。

快消品、耐用品、季节品、定制品和备件的补货逻辑不同。高频低价商品更关注缺货率和补货效率,低频高价商品更关注资金占用和需求确认,季节品更关注销售窗口,定制品则应尽量采用订单驱动。
| 商品类型 | 核心风险 | 更适合的补货依据 | 不宜采用的做法 |
|---|---|---|---|
| 高频稳定品 | 缺货影响连续销售 | 再订货点、服务水平、滚动销量 | 只按固定日期大批量采购 |
| 季节活动品 | 活动后需求骤降 | 活动周期、预售量、历史峰值修正 | 把活动期销量当常态 |
| 长尾规格品 | 单个规格长期不动 | SKU级销量、替代关系、最低采购量 | 按系列总销量平均分配 |
| 高价值低频品 | 资金占用和过时风险 | 订单、询价、客户承诺、供应商响应 | 为了凑起订量提前备大量现货 |
仓库账面数量不能直接用于补货。待检品、破损品、已锁定订单、临期品、包装不完整品和系统重复库存,都可能让账面数量看起来比真实可销售数量更高。
我建议把库存至少分成五类:可正常销售、待检、已分配、不可销售、在途。只有第一类和经过确认的在途库存,才能进入常规补货计算。否则,系统会认为货很多,采购人员就不下单;等真正可销售库存耗尽时,才发现缺货已经来不及补。
基础需求可以用加权平均法估算。对新手来说,不必一开始就追求复杂算法,先建立一个透明、可解释的规则更重要。
例如:
预测日均销量 = 近 7 天日均销量 × 50% + 近 30 天日均销量 × 30% + 近 90 天日均销量 × 20%
如果近 7 天日均销量为 20 件,近 30 天为 14 件,近 90 天为 10 件,那么预测日均销量为 15.2 件。这个结果还要根据活动、价格调整、渠道变化和缺货天数进行修正。
特别要注意,缺货期间的销量不是低需求的证据。一个 SKU 连续缺货 5 天,系统记录的销量自然偏低。如果直接用这个销量预测未来需求,就会形成“因为缺货所以销量低,因为销量低所以少补货,因为少补货所以继续缺货”的恶性循环。
再订货点的基本逻辑是:在供应商送货期间,仓库还要能够满足正常销售,并留出一定缓冲。
再订货点 = 预测日均销量 × 采购提前期 + 安全库存
假设某 SKU 预测日均销量为 15 件,供应商平均提前期为 8 天,安全库存为 40 件,再订货点就是 160 件。当库存位置低于 160 件时,才进入补货评估,而不是看到实物库存低于 160 件就立即下单。
安全库存可以用历史需求波动和供应波动估算。在数据不足时,可以先使用“提前期需求的 20%,50%”作为测试区间,再连续观察 4,8 周,根据缺货率和剩余库存调整,而不是一次性把安全库存设得很高。

很多积压不是因为再订货点设置错误,而是因为补货量没有上限。采购人员只知道“低于某个数要补”,却不知道“补到多少就应该停止”。
目标库存可以按一个补货周期来设定:
目标库存 = 预测日均销量 × 覆盖周期 + 安全库存
如果一个 SKU 日均销量为 15 件,希望覆盖 21 天,安全库存为 40 件,那么目标库存为 355 件。当前库存位置是 180 件时,理论补货量约为 175 件,但还要考虑供应商起订量、包装整数、在途和促销计划。
目标库存不是越高越好。服务水平要求越高,安全库存和资金占用通常也越高。仓库管理的关键不是追求所有 SKU 都做到“绝不缺货”,而是识别哪些 SKU 值得投入更高的服务水平。
我通常会采用“销量贡献、需求波动、商品价值、库龄风险”四个维度进行分层。传统的 ABC 分类只按销售金额排序,实操中还不够,因为一个高销售金额商品可能波动很小,也可能高度依赖活动。

下面这个案例来自我整理过的一类典型仓库场景,数据经过脱敏和四舍五入。某家经营家居小商品的仓库,有一款容量规格较大的收纳箱,年初连续两个月销量增长,采购人员认为商品进入增长期,于是将月补货量从 800 件提高到 2,000 件。
问题在于,销量增长主要来自一次平台活动和一组短期投放。活动结束后,商品月销量从 1,600 件下降到 650 件,但补货计划仍沿用活动期间的预测。与此同时,供应商最低起订量为 1,000 件,采购人员为了避免反复下单,又在第二个月追加了 1,500 件。
| 月份 | 期初可销售库存 | 当月入库 | 当月销量 | 期末库存 | 库存覆盖天数 |
|---|---|---|---|---|---|
| 活动前 | 520件 | 800件 | 720件 | 600件 | 25天 |
| 活动月 | 600件 | 2000件 | 1600件 | 1000件 | 19天 |
| 活动后第1月 | 1000件 | 1500件 | 650件 | 1850件 | 85天 |
| 活动后第2月 | 1850件 | 1000件 | 520件 | 2330件 | 134天 |
从表面看,活动月库存覆盖天数只有 19 天,采购人员增加补货并不完全没有道理。但真正的问题是,活动月销量被误认为常态,而且采购没有等待活动后的数据回落。活动后第二个月,库存覆盖天数已经达到 134 天,后续即使销量维持在 520 件每月,也需要四个多月才能消化现有库存。

活动月结束后,采购人员至少应该做三件事。第一,剔除活动期间的异常销量,重新计算常态日均销量;第二,检查是否还有未发货订单、在途货物和其他渠道的促销安排;第三,把新增采购冻结一周或两周,观察活动后自然销量。
如果活动后常态月销量约为 550 件,供应商提前期为 15 天,安全库存设为 150 件,那么目标库存不需要维持在 2,000 件以上。按 30 天覆盖周期计算,目标库存约为 700,750 件。此时更合理的动作不是继续采购,而是通过组合销售、分渠道销售和适度折扣消化超额库存。
这个案例最值得新手记住的不是某个固定公式,而是补货计划必须有“事件结束后的重算节点”。促销结束、价格调整、渠道下架、竞品进入、季节转换和供应商涨价,都应该触发一次计划重算。
库存处理不能只看采购成本。采购人员常常因为“不想亏本”而继续等待,但库存每多放一个月,就可能产生库位成本、资金成本、包装损坏和商品过时风险。
我会用“继续持有价值”和“立即处理价值”进行比较。继续持有价值包括预计正常售价带来的毛利、未来需求概率和供应稀缺性;立即处理价值包括当前可实现的销售收入、节省的仓储成本和释放资金后的再投资收益。
| 情况 | 继续持有更合适 | 立即处理更合适 |
|---|---|---|
| 需求趋势 | 近4周销量稳定或回升 | 连续8周下降且没有明确恢复原因 |
| 毛利空间 | 正常销售仍能覆盖持有成本 | 未来需要大幅折价才能成交 |
| 商品生命周期 | 没有升级换代或过季风险 | 规格、包装或功能即将淘汰 |
| 资金压力 | 库存占用对现金流影响较小 | 资金被占用并影响核心商品采购 |
如果积压集中在少数 SKU,最有效的第一步通常不是全仓盘点,也不是大规模降价,而是立即冻结这些 SKU 的常规补货。冻结的意思是停止自动采购和经验性补单,但不影响已经确认的客户订单。
接着检查四个信息:近 14 天和近 30 天销量、在途数量、已承诺订单、可替代 SKU。很多积压 SKU 并不是完全没有需求,而是需求被相近规格分流。此时可以通过合并展示、组合销售或调整推荐顺序消化库存。
如果同一批商品、同一供应商或同一采购人员负责的多个 SKU 同时积压,问题通常不是某个 SKU 的偶然需求下降,而是补货规则出现系统性偏差。
我会重点核查以下事项:是否重复计算在途库存,是否将销售订单和出库数量混用,是否把含税售价当成采购成本,是否有多个编码指向同一实物,是否用整箱单位替代单件单位,是否把退货重新入库却没有扣除损坏品。
系统性问题必须从流程修复,否则今天清掉一批库存,下一轮补货还会重新积压。建议把补货表增加以下字段:预测日均销量、采购提前期、可销售库存、在途库存、已承诺数量、库存位置、再订货点、目标库存、建议采购量、冻结原因。
季节品最忌讳平均分配库存。一个商品剩余 60 天销售窗口时,库存覆盖 90 天并不意味着还能等三个月,而是说明必须在窗口结束前处理掉多余库存。
这类商品建议采用倒推方式制定计划:
如果商品已经错过主要销售节点,继续等待原价销售往往只是心理上的“保本”,不一定是经济上的最优。越早识别剩余销售窗口,通常越有机会以较小折扣完成消化。
高价值低频品的积压风险常被件数掩盖。仓库里可能只有 20 件,但每件成本 2,000 元,资金占用就是 4 万元。此类商品不应追求“库存看起来完整”,而要优先确认订单、客户意向和供应商交付能力。
如果供应商交期稳定、客户可以接受等待,建议降低现货量,采用样品或少量展示库存;如果客户要求即时交付,再根据客户等级和订单概率配置少量安全库存。对于没有明确需求的高价值 SKU,采购前应获得销售预测、客户询价或订单依据。

日常管理最容易陷入两个极端:要么完全凭经验,不看数据;要么每天重新计算所有商品,最后团队疲于填表。更实用的做法是设置异常阈值,只处理真正需要人工判断的 SKU。
每天可以关注四类异常:库存位置低于再订货点、库存覆盖超过上限、近 7 天销量较 30 天均值下降超过 30%、库龄进入高风险区。其余稳定 SKU 按周复核即可。
这样做的好处是把人工时间用在“需要判断”的地方。补货系统负责发现异常,仓库和采购人员负责解释异常,而不是让人工重复计算每一个商品。
补货会议不应该变成逐行念库存表。建议固定讨论以下差异:实际销量与预测销量的差异、实际到货时间与供应商承诺的差异、计划采购量与实际消化量的差异、系统库存与盘点库存的差异。
| 复核问题 | 需要的数据 | 发现异常后的动作 |
|---|---|---|
| 销量是否偏离预测 | 7天、30天、90天销量 | 调整预测权重或排除活动异常 |
| 供应商是否稳定 | 承诺交期、实际交期、缺货次数 | 调整提前期和安全库存 |
| 采购是否超过消化能力 | 入库量、销量、库存覆盖 | 降低补货上限或暂停采购 |
| 库存是否真实可用 | 盘点数、待检品、破损品、锁定量 | 修正库存状态和可销售数量 |
经验不是没有价值,但经验必须被写成可检查的规则。建议给每个 SKU 设置至少三条红线:
红线不是为了限制所有采购,而是为了让例外采购显性化。只要有明确订单、供应商即将停产或价格即将大幅上涨,例外采购可以成立,但必须留下依据。没有依据的“感觉会卖”不应该成为大额采购理由。
如果企业过去一直凭经验补货,不建议一次性给全仓所有 SKU 上新规则。可以先挑选 30,50 个 SKU,覆盖稳定品、活动品、长尾品和高价值品,连续运行 4 周。
试运行期间重点记录四个结果:缺货次数、紧急采购次数、库存覆盖天数、超过 60 天库龄的库存金额。规则调整时,每次只改变一个变量,例如先调整预测权重,再调整安全库存,避免多个参数同时变化而无法判断效果。

如果企业要求核心商品几乎不能缺货,就必须承担更高安全库存、更高库存金额和更高仓储成本。服务水平提高通常不是免费得到的,尤其在需求波动大、供应商不稳定的情况下,库存是对不确定性的付费。
但这不意味着所有 SKU 都要采用最高服务水平。应该把高服务水平集中在高贡献、高复购、缺货损失明显的商品上;对低贡献、可替代、低频长尾商品,则可以接受更长交付时间。
如果企业把库存金额压得很低,必然会有一部分订单需要等待补货。关键不是完全消灭延迟,而是让延迟可预期、可沟通、可控制。销售端可以把现货、预售和定制交付区分开,不要把所有商品都承诺为即时发货。
低库存策略适合需求波动大、生命周期短、资金成本高的商品,但不适合供应商交期长且缺货损失巨大的核心商品。策略选择必须结合商品属性,而不是跟随某种管理潮流。
供应商常用“再买一点就能降价”推动采购数量上升。采购人员需要把价格、运费、起订量、付款周期、仓储、损耗和清仓全部计算进去。
有时,小批量多次采购的单位价格更高,但总成本更低;有时,大批量采购确实值得,但前提是销售速度、销售窗口和现金流都能支撑。真正专业的采购不是永远压低单价,而是控制每个 SKU 的总拥有成本。

先不要急着建立复杂模型。第一步是补齐 SKU 编码、单位、入库数量、出库数量、退货数量和盘点数量。至少连续记录 4 周,形成日销量和周销量,再根据供应商提前期设置初步补货线。
如果完全没有历史数据,可以使用销售订单、询价数量、同类商品销量和供应商交期做临时估计,但必须标记为试运行参数。等积累了真实销售数据后,再替换掉临时假设。
不应该直接加大。先确认上涨原因,是活动、投放、自然增长、竞品缺货,还是此前长期缺货导致订单集中释放。只有当上涨原因可持续,且销售窗口和供应能力都明确时,才适合逐步提高采购量。
更稳妥的做法是分批采购,先覆盖一个较短周期,观察销量是否持续,再决定下一批。一次性把短期上涨放大成长期库存,是最容易制造积压的方式之一。
只有在库存位置仍低于再订货点时,才考虑继续补货。必须先确认在途货物的状态,包括是否已发货、预计到货日期、数量是否准确、是否存在部分交付或质量问题。
如果供应商交期不稳定,可以把“确认在途”和“未确认在途”分开计算。未确认在途不能完全当作可用库存,否则供应商延误时会突然暴露缺货风险。
不一定。降价只是处理手段之一。可以先尝试搭配销售、渠道转移、包装重组、赠品消化、样品投放、供应商退换和内部消耗。是否降价,要看商品生命周期、销售窗口和未来持有成本。
但如果商品已经过季、升级或连续多个周期没有真实需求,继续坚持原价通常只会增加损失。清仓不是承认管理失败,而是停止让错误继续产生成本。
没有一个适用于所有 SKU 的固定答案。可以从提前期需求的 20%,50%开始试算,再结合缺货率、需求波动和供应商稳定性调整。
如果安全库存长期没有被动用,可能设置过高;如果每个补货周期都被轻易消耗,可能设置过低。但也要区分需求增长和供应延迟,不要因为一次异常就永久提高库存。
先建立一张“SKU补货与积压看板”,不要先追求复杂系统。看板至少包含 SKU、可销售库存、在途库存、已承诺数量、近7天销量、近30天销量、采购提前期、库存覆盖天数、库龄、建议动作和责任人。
每天更新异常项,每周复核规则,每月检查积压原因。只要能够连续记录三个月,很多原本靠感觉的问题都会变成可解释、可追踪的管理问题。
补货表的作用是提出建议,而不是替代判断。销量变化、活动结束、供应商延误、客户订单取消和商品生命周期变化,都可能让昨天正确的建议今天失效。
我更看重补货计划是否具备三个能力:能解释为什么补、能说明补多少、能在什么条件下停止补。只有“建议采购数量”而没有“冻结条件”和“复核时间”的表格,往往会把错误自动延续。
库存积压的本质,不是仓库里货太多,而是企业没有及时承认需求已经改变。好的补货计划不是一次性算出一个“完美数量”,而是持续发现偏差、及时停止错误、把有限现金留给真正值得库存的 SKU。
如果你现在就要开始排查,建议先找出三类商品:库龄最长的 SKU、库存金额最高但销量下降的 SKU、近期开过活动却仍在按活动销量补货的 SKU。把这三类商品列出来,通常比先统计全仓库存总额更快找到积压的源头。
我刚接手仓库时,以为库存积压就是某些商品卖不动,结果盘点后发现,有些 SKU 是重复采购,有些是规格错配,还有一些只是被系统分散到不同仓位。我想知道,仓库新手应该先区分哪些积压类型,避免一上来就盲目打折清货?
补货计划失控后,库存积压通常不是单一原因,而是“数量买多、时间买早、规格买错、结构失衡”几类问题叠加。实际复盘一个包含 1200 个 SKU 的仓库时,我把库存积压拆成四类,发现真正需要优先处理的并不是库存金额最高的商品,而是周转已经停止、后续还会继续补货的商品。
积压类型典型表现优先处理动作 数量型积压库存覆盖天数远高于销售周期暂停补货,制定去库存计划 时间型积压淡季提前采购,旺季需求未兑现重新校准预测周期 规格型积压大包装、特殊颜色或冷门尺寸滞销拆分组合销售或转换用途 结构型积压畅销款缺货,关联配件却大量沉淀按商品组合重新规划采购 我判断积压严重程度时,不只看库存金额,而是同时看“库存覆盖天数”和“最近 30 天出库次数”。
例如某 SKU 库存金额只有 3000 元,但连续 45 天没有出库,且供应商交期为 7 天,它的风险往往高于一个金额 2 万元、每天稳定出库的畅销品。
建议先建立一个简单的积压筛选表:库存覆盖天数超过目标周期 2 倍、最近 30 天出库次数低于 2 次、未来 14 天仍有采购计划的 SKU,直接列入一级预警。这样做的价值是先阻止积压继续扩大,再讨论促销、退货、换货或报损。
我以前直接按照上个月销量乘以一个比例来补货,结果销量一波动,采购量就跟着失真。有的商品长期堆在仓库,有的商品却频繁缺货,我想知道补货点和安全库存到底应该怎样结合实际销售与供应周期来计算?
仓库新手最容易犯的错误,是把安全库存理解成“多买一点以防万一”。安全库存不是越高越安全,而是用来覆盖需求波动和供应延迟的有限缓冲。如果没有明确的服务目标、交期和销售波动,安全库存最终会变成积压库存的合理化理由。我在一次 90 天销售数据复盘中,先剔除春节、促销和一次性大客户订单,再计算日均销量。
对普通 SKU,我使用的基础公式是:补货点 = 日均销量 × 供应周期 + 安全库存。比如某商品日均销量 18 件,供应周期 10 天,安全库存设为 60 件,那么补货点就是 240 件。
指标示例值含义 日均销量18 件剔除异常订单后的平均出库量 供应周期10 天从下单到可销售入库的实际时间 安全库存60 件覆盖波动与延迟的缓冲量 补货点240 件库存低于该数值时触发采购评估 但补货点不是采购数量。采购数量还要扣除现有库存、在途库存和已锁定库存。
实际下单前,我会用“建议采购量 = 预测需求 + 目标安全库存 – 可用库存 – 确认在途库存”重新计算,避免把已经下单但尚未入库的货再次买进来。对于销量波动特别大的商品,不建议直接把安全库存提高到 30 天甚至 60 天。
更稳妥的方式是缩短复核周期,例如从每月复核改为每周复核,并把促销订单、季节性订单单独标记,否则一次异常销量就可能把未来几个月的采购量整体推高。
我遇到过供应商要求最低采购 500 件,但仓库每月只卖 120 件的情况。采购人员说不买够就拿不到价格,销售人员又用一次促销活动的数据来预测长期销量,我想知道这类决策应该怎样判断,才能避免低价采购变成高成本库存?
采购单价低,并不等于采购成本低。只要起订量超过合理销售周期,仓储费、资金占用、过期损耗和降价处理成本都会吞掉单价优惠。我复盘过一笔“买满 500 件每件便宜 2 元”的订单,表面节省了 1000 元,但其中约 230 件在 6 个月内没有出库,后续通过折价处理,实际损失超过了采购优惠。
判断起订量是否合理,不能只问供应商能否优惠,而要比较“起订量对应的库存覆盖天数”。计算方法是:起订量 ÷ 校正后的日均销量。例如每月稳定销售 120 件,供应商最低采购 500 件,那么仅这一批货就覆盖约 125 天;如果商品保质期、款式生命周期或资金周转目标低于这个周期,起订量就已经偏高。
方案单价变化预计库存覆盖主要风险 一次采购 500 件低 2 元约 125 天资金占用、滞销 采购 250 件并接受常规价单价较高约 63 天采购单价上升 分批交付 500 件保持优惠按需入库需要供应商配合 促销预测也要单独处理。
一次活动带来的销量,不能直接当作基础日均销量,至少要拆成活动新增销量、自然销量和活动后回落销量。我的做法是活动结束后观察 2 到 4 周,如果自然销量没有回到新的稳定水平,就只把活动增量作为临时需求,不写入长期补货参数。
当起订量确实不可谈时,可以优先争取分批交付、寄售、混批采购或替代规格,而不是简单接受整批入库。对库存管理来说,供应商账面上的“采购优惠”,只有在商品能够按计划卖出去时才是真正的优惠。
我现在主要靠销售人员提醒采购,通常等到仓库已经堆满,才发现某些商品连续几周没有出库。我想建立一套不依赖个人经验的预警方法,既能提醒缺货,也能在补货过量前及时拦截订单。
补货预警不能只设置一个“库存低于多少就采购”的条件,因为这只能识别缺货风险,无法识别库存越买越多的问题。我建议至少同时设置缺货预警、过量预警和呆滞预警,让系统回答三个问题:什么时候该买、什么时候不该买、什么时候要停止销售预测带来的自动采购。
预警层级触发条件示例处理动作 缺货预警可用库存低于补货点核对在途和订单后再下单 过量预警库存覆盖天数超过目标值 2 倍暂停自动补货,复核需求 呆滞预警连续 30 天无出库停止采购并制定去库存方案 异常预警预测销量较过去 8 周均值高 50%核验是否为促销或一次性订单 在实际执行中,我会把“采购申请”和“采购批准”拆成两个动作。
系统可以自动生成建议采购量,但只要 SKU 同时满足过量预警、呆滞预警或预测异常增长,就必须由仓库、销售和采购共同确认,不能让建议单自动转成正式订单。
每周例会上不要平均检查所有 SKU,而是优先看三张清单:库存金额最高的前 20 个 SKU、覆盖天数增长最快的前 20 个 SKU、连续无出库但仍有在途订单的 SKU。这样一次会议通常只需要检查 30 分钟,却能抓住大部分积压风险。我最看重的不是预警数量,而是预警关闭率和重复发生率。
比如某月产生 80 条过量预警,处理了 70 条,看起来关闭率不错;但如果其中 30 条下个月再次出现,说明问题不在执行,而在补货参数、起订量或销售预测逻辑。只有把重复预警降下来,预警系统才真正帮助仓库减少积压。


读者评论
文章把“库存多”与“库存积压”区分开这一点很实用。尤其是库存位置的计算,很多仓库只看实物库存,却忽略在途和已承诺订单,确实容易重复下单。
对活动品和长尾规格的分析比较贴近实际。系列整体销量好,不代表每个颜色、尺寸都值得补货,建议再结合退货率和最低采购量一起判断。
批量折扣不等于真正省钱,这个例子很有参考价值。不过不同企业的仓储费、资金成本和清仓能力差异较大,实际应用时还需要替换成自己的数据。