我见过最容易失控的库存，不是完全没有系统的店铺，而是已经接入订单、仓库和采购系统，却仍然每天靠运营人员打开几张表格，凭经验判断“这个 SKU 该不该补”。在一个模拟的家居电商案例中，某主推收纳盒月均销量约 6,000 件，仓库可售库存看起来还有 1,800 件，但其中 700 件已被订单锁定、400 件属于质检库存、500 件已经在途。采购人员如果只看库存余额，很容易继续下单；如果只看可售库存，又可能忽略在途和活动后的需求回落。
补货计划自动化的起点，不是购买一套软件，也不是先设置一个“库存低于多少就提醒”的阈值，而是先建立统一的库存口径，再把“什么时候补、补多少、哪些商品优先补”拆成可计算、可审核、可追溯的规则。
本文会从补货决策的底层逻辑开始，拆解销售数据、可售库存、锁定库存、在途库存、采购交期、安全库存和活动因素之间的关系，并以九数云这类数据分析与可视化工具的应用方式为例，说明中小电商如何从表格预警逐步升级到补货建议和半自动采购流程。文中涉及的案例数据均为情景模拟或方法演示，不代表某一企业的真实经营结果。
很多企业把“自动补货”理解为系统检测到库存低于安全库存后，自动生成采购单。这种理解少了最关键的一步：系统必须先判断这个库存是否真的可用，以及未来需求是否会超过供应能力。
例如，某 SKU 当前库存为 1,000 件，近 30 天日均销量为 80 件，供应商交期为 10 天。表面上看，库存可以支撑 12.5 天，但如果其中 300 件已被订单锁定，200 件正在质检，真正可用于新订单的只有 500 件，实际覆盖天数只有 6.25 天。此时，系统的判断结果会完全不同。
我通常把库存自动化拆成四个层次：第一层是数据自动汇总，第二层是异常和低库存预警，第三层是补货建议，第四层才是对稳定 SKU 开放自动生成采购单。没有经过前面三层验证，直接进入自动下单，往往只是把人工错误变成系统化错误。
一个真正可执行的补货计划，至少要回答以下三个问题：
如果系统只能告诉采购人员“库存不足”，却不能解释库存不足的原因、建议采购数量和优先级，那么它仍然只是一个告警工具，还没有形成补货决策系统。
在实际项目中，我不会直接拿 ERP 的库存余额做补货计算，而是先要求团队明确库存状态。一个适合多数电商场景的基础口径可以写成：
可用库存 = 物理库存 – 锁定库存 – 不可售库存 – 质检占用库存 + 可确认入库的在途库存
这里的“可确认入库”不能简单等同于所有在途库存。对于供应商经常延迟、海运周期波动明显或入库质量不稳定的商品，在途库存应当按照预计到货可靠性折扣处理。例如，历史上只有 80% 的在途数量能够按计划在交期内入库，就不能把全部在途数量都当成未来可销售库存。
如果企业暂时没有足够数据估算在途可靠性，可以先把在途库存分成“已发货、预计到港、已入仓待检、采购已下单未生产”四类。不同状态分别纳入不同的补货口径，通常比使用一个笼统的“在途数量”更安全。
库存数字本身不是决策，库存变化的原因才是决策依据。一个 SKU 从 5,000 件下降到 2,000 件，可能是正常销售，也可能是一次大促集中出库；可能是订单真实履约，也可能是渠道调拨；还可能是盘点差异、报损或库存冻结。
如果系统只提供一个当前库存字段，采购人员就必须在订单系统、仓库系统、活动排期表和供应商沟通记录之间来回核对。最后形成的补货数量，自然会高度依赖个人经验。人员一旦休假、离职或换岗，补货逻辑也会跟着丢失。
日均销量是补货模型中最常见、也最容易被滥用的指标。近 30 天销量除以 30 得出的数字，未必代表正常需求。它可能包含大促、断货、价格调整、广告投放、平台活动和异常退货。
举例来说，一个 SKU 过去 30 天平均每天卖 100 件，但其中 7 天完全断货，5 天参加平台活动，3 天因为投放增加销量。如果把这 30 天直接平均，得到的日均销量既低估了缺货损失，也混入了活动增量。更合理的做法是同时保留自然销售日、断货日和活动日，并对不同时间窗口进行解释。
安全库存不是“所有商品都留 100 件”，也不是采购人员为了安心而设置的缓冲数量。它应该反映需求波动、供应商交期波动和缺货成本。
销量稳定、供应商交期稳定的标品，安全库存可以相对精细；销量波动大、供应周期长、缺货后会影响整套商品销售的 SKU，则需要更高的风险缓冲。相反，生命周期已经进入尾声的商品，即使库存偏低，也不一定值得重新采购。
我在评估补货方案时，不会只看“缺货有没有减少”。如果缺货率从 8% 降到 3%，但库存金额从 300 万元上升到 650 万元，且滞销库存占比明显提高，这并不能说明补货自动化成功。
补货方案应当同时观察订单满足率、库存周转、库存覆盖天数、滞销金额、紧急采购次数和供应商交期偏差。库存自动化的目标不是把库存压到最低，而是在服务水平、资金占用和供应风险之间找到可解释的平衡点。
补货模型至少需要同时观察近 7 天、近 30 天和近 90 天的销量。近 7 天适合捕捉近期趋势，近 30 天适合观察常态需求，近 90 天更适合识别季节性和长期变化。
但这三个指标不是越多越好，关键在于解释它们之间的差异。例如，近 7 天日均销量是 150 件，近 30 天是 100 件，近 90 天是 85 件，说明近期需求可能上升。采购人员需要进一步判断这是活动拉动、投放放量，还是产品自然增长。
我建议把以下字段纳入基础数据集：
在实际补货表中，我通常会把库存拆成现货可售、订单锁定、不可售、质检中和在途五类。不同企业还可能需要增加调拨中、退货待检、供应商寄售和平台仓冻结等状态。
这一步的价值在于，让每一个库存数字都具备业务含义。采购人员看到“在途 2,000 件”时，应当能够继续追问：这些货是否已发出？预计什么时候到？是否已经支付？是否存在质量或清关风险？
供应商交期不能只记录“平均 15 天”。更实用的字段包括承诺交期、实际交期、最长交期、交期标准差、准时交付率和最小起订量。
如果一个供应商平均 15 天交货，但实际交期经常在 10 至 30 天之间波动，那么补货模型不能只按 15 天计算。对于高缺货成本的商品，应当使用更保守的交期基准，或者为该供应商设置风险等级。
即使理论上需要采购 5,000 件，企业也不一定能够立即采购。仓储容量、现金流、供应商账期、起订量、包装倍数、采购预算和商品保质期都会影响最终数量。
因此，补货计划最好增加“建议采购量”和“批准采购量”两个字段。系统负责根据需求和库存计算建议值，采购或负责人再结合预算、仓容和供应商谈判结果确认最终值。这样既保留了模型的客观性，也避免系统忽略现实约束。
高销量 SKU 通常最容易被纳入自动补货，但销量高只能说明影响面大，不能说明需求稳定。如果一个商品最近连续参加大促，销量虽然很高，却没有稳定的自然需求，系统自动补货可能在活动结束后形成大量积压。
真正适合优先自动化的 SKU，通常同时具备几个条件：销量相对稳定、供应商交期稳定、库存状态准确、采购规格清晰、缺货后果可衡量，并且历史补货结果能够被复盘。
第一种是按销售贡献度分层，例如观察销售额、销量或毛利贡献。第二种是按需求稳定性分层，区分稳定品、波动品、季节品和新品。第三种是按缺货影响分层，识别配件、套装组成品和核心引流品。第四种是按供应风险分层，区分交期稳定供应商和经常延迟供应商。
| SKU类型 | 典型特征 | 建议补货方式 | 主要风险 |
|---|---|---|---|
| 高销量稳定品 | 销量连续性好，交期波动小 | 可采用日常自动预警，逐步开放半自动补货 | 参数长期不更新，导致趋势变化后反应迟缓 |
| 高销量波动品 | 活动、投放或价格对销量影响明显 | 系统生成建议，人工审核后采购 | 活动销量被当作常态，造成过量备货 |
| 季节性商品 | 需求集中在特定月份或节日 | 单独建立季节和活动参数 | 淡季补货后长期积压 |
| 新品 | 缺少历史销量，需求不确定 | 设置试销库存和复盘节点 | 初始预测偏差大，无法直接套用老品规则 |
| 滞销品 | 库存覆盖天数高，近期销量低 | 暂停常规补货，先处理库存 | 系统按最低库存规则继续生成采购建议 |
采购优先级不能只按销量从高到低排序。某个配件月销量只有 300 件，但它是多个套装商品的组成部分，一旦缺货，可能影响 2,000 个套装订单的履约。另一个商品月销量 2,000 件，但有多个替代品，短期缺货的影响反而有限。
我在设计优先级时，会综合以下因素：未来交期内预计需求、缺货后受影响订单数、商品毛利、替代品可用性、供应商风险和采购金额。这个排序结果通常比单纯的 ABC 分类更接近真实经营损失。
最基础的再订货点可以理解为：在供应商交货之前，企业预计会消耗的库存，加上为需求和交期波动保留的安全库存。
再订货点 = 交期内预计需求 + 安全库存
交期内预计需求 = 日均需求 × 采购交期天数
假设某 SKU 日均需求为 80 件，采购交期为 10 天，安全库存为 300 件，那么再订货点就是 1,100 件。当可用库存下降到这个水平以下时，系统应当生成补货预警。
但这个公式只适用于需求相对稳定、交期较明确的场景。如果商品处于活动期、销量正在快速上升，或者供应商交期经常变化，就需要调整日均需求和交期参数，而不能机械套用。
再订货点回答的是“什么时候需要关注”，并不等于“每次要补多少”。补货量还要看企业希望库存覆盖多长时间。
目标库存 = 目标覆盖天数 × 调整后日均需求 + 安全库存
建议采购量 = 目标库存 – 当前可用库存 – 可确认在途库存
如果建议采购量为负数，通常意味着暂时不需要补货。但在实际系统中，还要增加最小采购量、采购倍数和预算限制。例如，供应商要求每次至少采购 500 件，系统计算结果为 320 件，最终建议量可能需要向上取整到 500 件；如果仓储容量不足，则需要进入人工审核。
大促备货不能直接用平时的日均销量代替。更稳妥的方式是把活动拆成三个阶段：活动前备货、活动中销售和活动后回落。
活动前应重点估算活动带来的增量需求，并检查供应商能否按时交货；活动中需要提高库存更新频率，关注实际销量是否超过预估；活动后则要重新计算自然需求，避免系统继续沿用活动期间的高销量。
如果企业暂时没有成熟的预测模型，可以先建立“自然销量”和“活动增量”两个字段。活动结束后，保留活动标签并从常规日均销量计算中剔除，虽然不如复杂算法精细，但能够明显减少历史数据污染。
安全库存的本质，是为需求波动和供应波动买一份保险。需求越不稳定、供应商越不可靠、缺货损失越高，安全库存通常越应该提高。
不过，安全库存也不能无限提高。对于低毛利、易过期、生命周期短或仓储成本高的商品，库存缓冲过大可能比缺货更昂贵。因此，我更建议企业为不同商品设置服务目标，例如核心标品追求更高的订单满足率，长尾商品则允许更低的现货覆盖。
从实际落地角度看，九数云这类工具更适合承担“多源数据汇总、指标计算、可视化分析和预警看板”角色，而不是替代 ERP、WMS 或采购系统完成所有业务动作。企业需要根据自身账户、数据源和接口能力，核实具体连接方式与功能边界。
它的价值不在于单独展示一个库存数字，而在于把订单、销售、库存、在途、采购交期和供应商信息放到同一套分析视图中，让采购人员能够从“库存是多少”继续追到“为什么不足”“未来会不会缺”“建议补多少”。
如果企业已经有多个平台和仓库，数据经常分散在订单后台、仓储系统、供应商表格和财务表格中，那么先用可视化工具建立统一分析层，通常比一开始就要求所有系统重构更容易推进。
在九数云中搭建补货分析时，我建议不要从一个复杂的大屏开始，而是先建立五张能够相互校验的基础表。
这五张表的关键不在数量，而在于每张表都有明确责任人和更新时间。销售数据由运营或订单系统维护，库存快照由仓库或 WMS 提供，采购在途由采购维护，商品参数由供应链负责人审核，补货建议则由系统计算并交给采购确认。
很多库存看板喜欢展示“库存最多的 SKU”和“库存最少的 SKU”，但这两个排名对采购行动的帮助有限。更有用的看板应当直接围绕决策设计。
我会优先放置以下模块：
这样设计的好处是，采购人员打开看板后，不需要先从几千个 SKU 中寻找问题，而是直接看到今天需要处理的事项、需要审批的事项和需要调查的异常事项。
以下以某家居电商的收纳盒 SKU 为例。该案例是情景模拟，用于展示计算过程。
| 字段 | 数值 | 解释 |
|---|---|---|
| 近30天自然日均销量 | 80件 | 已剔除大促期间的异常增量 |
| 采购交期 | 10天 | 以最近三次实际交期中较保守的水平估算 |
| 安全库存 | 300件 | 用于覆盖需求和交期波动 |
| 目标覆盖天数 | 25天 | 结合采购周期和供应商起订量设定 |
| 现货可售库存 | 500件 | 已扣除锁定和不可售库存 |
| 可确认在途库存 | 160件 | 按到货可靠性折算后的数量 |
按照公式计算，再订货点为 80 × 10 + 300，也就是 1,100 件。当前现货可售库存只有 500 件，已经低于再订货点，因此应当触发补货预警。
目标库存为 80 × 25 + 300，也就是 2,300 件。建议采购量为 2,300 – 500 – 160，结果为 1,640 件。如果供应商采购倍数为 100 件，系统可以将建议量向上取整为 1,700 件，再交由采购人员审核预算和仓容。
如果当天恰好处于大促前一周，建议量不能直接沿用上述结果。系统应增加活动预估增量、活动持续时间和活动后回落系数，并将该 SKU 的自动下单权限改为人工审批。
第一阶段不要急着追求自动下单，先解决“大家看到的库存是不是同一个库存”的问题。企业应当选取一批核心 SKU，逐项核对订单系统、仓库系统、采购表格和实际盘点结果。
需要重点确认以下问题：
如果这些基础问题没有解决，后面的可视化只是把不一致的数据放到了一张屏幕上，并不会自动变得准确。
完成库存口径统一后，再针对核心 SKU 设置预警。预警条件可以从简单规则开始，例如可用库存低于再订货点、预计覆盖天数低于采购交期、在途延期超过三天。
预警信息必须包含原因，而不是只显示红色图标。一个好的预警应说明：当前可用库存、近 30 天日均需求、采购交期、在途数量、再订货点、建议动作和数据更新时间。
当预警运行一段时间后，再让系统输出建议采购量。此时建议量应当进入采购审核流程，而不是直接生成正式采购订单。
审核人员要记录“采纳、修改或驳回”的原因。例如，采购人员因为供应商涨价而减少采购量，因为活动排期变更而延后采购，或者因为仓库容量不足而拆分到货。长期积累这些原因，才能发现模型和现实业务之间的差距。
当某一类 SKU 连续运行数个补货周期，且数据质量、供应商交期和需求波动都比较稳定，才适合开放更高程度的自动化。
即使进入半自动阶段，也建议保留金额阈值、异常销量阈值、交期异常阈值和人工暂停按钮。系统可以自动生成采购任务，但高金额采购、活动备货和新品补货仍然应当经过人工确认。
稳定标品是最适合做补货自动化的对象。这类商品通常销量连续，供应商交期可预测，采购倍数明确，需求受活动影响较小。
建议每天更新库存和销量，使用近 30 天或近 60 天需求作为基础，并根据最近趋势适度修正。系统可以自动计算再订货点和建议采购量，采购人员重点审核金额、供应商和仓储容量即可。
活动商品不能简单沿用日常补货规则。活动前需要建立独立的活动需求假设，包括预计访客、转化率、客单量、活动时长、历史同类活动表现和广告预算。
如果活动预估不确定，我建议采用分批到货，而不是一次把全部预测量压给供应商。第一批覆盖确定性需求，第二批根据活动前几天的真实销售速度决定是否追加。这样牺牲了一部分供应链灵活性，却能降低活动结束后的积压风险。
新品没有足够历史数据，不适合直接使用老品的日均销量和安全库存。新品补货应当更像一个试验过程：先设定试销数量和观察周期，再根据点击、加购、转化、退款和复购等信号调整。
新品的补货看板应当突出“预测偏差”和“库存剩余”，而不是只看销售排名。如果商品转化率高但退货率异常，继续补货可能会放大售后和库存风险。
季节性商品需要按季节同比、去年同期、节假日位置和当前市场变化综合判断。单纯观察最近 30 天，可能正好处于淡季或旺季，无法代表下一阶段需求。
这类商品还要设置停止补货日期。很多积压并不是预测完全错误，而是商品已经接近销售窗口结束，系统仍然按照最低库存规则继续生成采购建议。
多仓场景下，补货计划不能只看企业总库存。一个商品在全国总库存充足，但华东仓缺货、华南仓积压，同样会造成履约问题。
系统应当分别计算仓库需求、仓库可用库存和仓间调拨成本。对于距离较近、调拨时间短的仓库，可以优先调拨；对于跨区域运输时间长的仓库，则应把调拨周期纳入补货交期。
| 业务场景 | 主要输入 | 自动化建议 | 不宜自动化的部分 |
|---|---|---|---|
| 稳定标品 | 连续销量、稳定交期、采购倍数 | 可自动预警，验证后半自动下单 | 超预算采购和供应商异常 |
| 大促商品 | 活动增量、投放计划、分批到货能力 | 自动汇总数据和输出备货建议 | 活动预测和最终采购量 |
| 新品 | 试销库存、转化率、退货率、评价反馈 | 自动跟踪销售和库存表现 | 首批采购和需求判断 |
| 季节品 | 历史同期、季节窗口、停止补货日期 | 自动提醒关键时间节点 | 季节峰值和尾货处理决策 |
| 多仓商品 | 分仓需求、调拨时效、区域库存 | 自动计算分仓覆盖天数 | 调拨与采购的成本取舍 |
纯表格适合 SKU 数量较少、仓库数量有限、订单波动不大且团队能够固定维护的企业。它的优势是启动快、规则透明、修改方便，采购人员可以直接看到公式和计算过程。
它的主要问题是数据更新依赖人工，容易出现版本混乱、重复复制、公式被覆盖和历史参数无法追踪。当 SKU 数量快速增加，表格通常会先在数据同步环节失控，而不是在计算公式环节失控。
九数云这类工具的适用价值，主要在于把分散数据连接起来，形成库存、销售、采购和供应商的统一分析视图。对于已经有订单、仓库和采购系统，但缺少跨系统分析能力的企业，这通常是一个相对务实的过渡方案。
它并不天然等于完整的供应链执行系统。企业仍然需要确认数据接口、更新频率、权限控制、异常处理和采购单回写方式。如果工具只能生成分析结果，而不能连接实际采购流程，那么它更适合作为决策支持层，而不是执行层。
当企业拥有多个仓库、多渠道订单、较多供应商和复杂的采购审批时，完整业务系统的价值会更明显。它可以将订单分配、库存扣减、采购下单、到货入库和财务结算连接起来。
但系统越完整，实施成本通常越高。企业需要投入主数据治理、流程梳理、接口开发、人员培训和持续运维。很多项目失败，不是系统计算能力不足，而是上线前没有明确 SKU 编码、库存状态和责任边界。
缺货率适合观察商品层面的断货情况，但订单满足率更接近客户体验。一个 SKU 缺货一天，可能只影响少量订单；另一个配件缺货，则可能导致多个套装订单无法发出。
因此，建议同时记录缺货 SKU 数量、缺货时长、受影响订单数和订单满足率。对于核心商品，还可以单独设置重点监控指标，避免大量长尾 SKU 的平均数据掩盖核心商品问题。
补货建议上线后，如果库存周转没有改善，甚至滞销金额持续上升，就需要检查是否存在目标覆盖天数过长、活动销量污染、滞销品未被排除或供应商起订量过大的问题。
我更关注库存结构变化，而不是单一库存总额。库存总额上升可能是销售增长带来的合理结果，但如果增长主要来自低周转 SKU，就说明补货规则正在把现金流推向风险更高的地方。
补货建议采纳率低，不一定说明模型失败，也可能说明系统没有纳入采购人员掌握的业务信息。关键是记录每次修改的原因。
如果大量修改来自供应商交期变化，说明交期参数没有及时更新；如果大量修改来自活动计划，说明活动数据没有进入模型；如果大量修改来自仓储容量，则说明建议量计算缺少经营约束。
一个计算精确但两天没有更新的库存看板，实际价值可能低于一张每天更新、但规则简单的表格。数据新鲜度应当成为补货系统的基础指标。
一次性把所有 SKU 纳入自动补货，往往会把新品、滞销品、活动品和稳定标品混在一起。不同商品的需求规律不同，系统会输出大量看似合理但无法执行的建议。
更稳妥的做法是先选取 20 至 50 个核心 SKU 做试点，覆盖稳定标品、活动品、新品和长尾品几种典型情况。试点的目的不是证明系统永远正确，而是找出数据和规则中最需要修正的地方。
固定安全库存最方便，但也是最粗糙的做法。销量差异十倍的两个 SKU，如果都设置 200 件安全库存，必然会出现一个库存不足、另一个资金浪费。
至少应当根据日均需求、交期、波动性和缺货影响做分层。参数不必一开始就非常复杂，但必须能够解释“为什么这个 SKU 是 300 件，另一个 SKU 是 50 件”。
系统按需求算出 1,640 件，供应商要求按 500 件起订；系统认为采购 2,000 件最经济，仓库却只能容纳 1,200 件。若模型不纳入这些约束，最终建议仍然需要人工推翻。
建议在补货建议表中增加“理论采购量”“按起订量调整后数量”“预算校验结果”和“仓容校验结果”，让采购人员清楚地看到数量是如何变化的。
活动销量不是不能使用，而是必须有标签、有时间范围和有回落判断。活动结束后，应当对比活动前后的自然销量，判断增量是否持续。
如果没有活动标识，至少应在数据表中增加活动日期字段，并在计算近 30 天日均销量时做排除或加权处理。这样做虽然不如专业预测模型复杂，却能减少最明显的误判。
看板上线后，企业必须明确谁负责查看预警、谁负责审核建议、谁负责联系供应商、谁负责更新交期、谁负责复盘结果。如果看板只是“大家都能看”，通常就会变成“没有人真正负责”。
我建议为每类预警设置处理时限。例如，核心 SKU 断货风险当天处理，普通 SKU 在一个工作日内处理，活动商品由运营和采购共同确认。系统记录处理人和处理结果，才能让自动化真正进入业务流程。
如果企业 SKU 少于几百个，仓库数量较少，采购人员能够掌握主要商品，可以先用表格建立最小可行版本。重点不是做复杂预测，而是统一可用库存、记录交期和计算覆盖天数。
如果企业已经有多个渠道、多个仓库和多个采购人员，最优先的工作通常不是直接更换全部系统，而是建立跨系统的数据分析层。此时可以评估九数云等工具，用于统一指标、建立补货看板和输出采购建议。
选型时要重点验证数据连接、更新频率、权限、计算逻辑、异常提醒和结果回写能力。不要只看展示效果，也不要把“能生成图表”误认为“能完成补货执行”。
对于多仓、多渠道、供应商数量多、采购金额高的企业，需要把库存自动化放入整体供应链架构中。ERP 负责业务主数据和采购流程，WMS 负责仓储状态，订单系统负责渠道订单，分析工具负责跨系统判断和管理看板。
这类企业应先选择一条业务线或一个仓库试点，明确库存口径、接口责任和审批规则，再逐步推广。系统越复杂，越不能跳过试点和主数据治理。
这类企业不应把目标设定为“所有 SKU 自动下单”，而应当把自动化重点放在活动前后的数据监控、分批备货和异常提醒上。
活动期间，系统每天甚至每小时更新销售速度、库存覆盖和预计断货时间；采购人员根据实际进度决定追加、延后或取消采购。对波动型商品来说，高频调整和人工决策并不是自动化失败，而是符合业务风险的合理边界。
电商库存自动化方案不应从“哪套软件功能最多”开始，而应从“企业能否解释每一个补货决定”开始。系统需要知道当前库存为什么变化，未来需求从哪里来，供应商什么时候能够交货，以及这次采购受到哪些现实约束。
如果企业还没有统一库存口径，第一步就是整理可售、锁定、不可售和在途库存；如果已经拥有较完整的数据，下一步就是建立 SKU 分层、再订货点和建议采购量；如果数据分散在多个平台，可以使用九数云这类工具构建统一分析层，但必须同时确认数据接口、权限和采购执行边界。
我最建议企业先做的，不是自动下单，而是让系统每天回答三个问题：未来交期内哪些 SKU 可能断货，哪些 SKU 的库存金额正在失控，今天的采购预算应该优先分配给谁。当这三个问题能够被稳定、透明、可追溯地回答，补货自动化才真正有了基础。
下一步可以从 20 至 50 个核心 SKU 开始，建立一张包含销售、库存、在途、交期、安全库存和建议采购量的补货表，连续运行四个周期，再根据缺货、积压和人工修改原因调整规则。先让数据和规则经得起复盘，再让系统替你执行。
我原本以为补货自动化就是采购一个能自动提醒的软件，后来才发现，同一个 SKU 在订单系统、仓库和采购表里的库存数量经常不一样。到底应该先整理哪些数据，才能避免系统根据错误库存做出错误补货建议？
补货自动化的第一步不是选系统，而是统一“可用于补货判断的库存”口径。实际梳理库存时，最容易踩的坑是把系统显示的库存直接当成可售库存，但系统库存里可能混有锁定库存、残次品、质检库存、已分配库存和已经下单但尚未入库的在途库存。
建议先把库存拆成以下几类，再决定哪些数据进入补货公式： 库存类型是否直接用于补货判断常见风险 可售库存是仓库盘点不准或同步延迟 锁定库存通常不应重复计入订单取消后未及时释放 不可售库存否系统库存很多，但实际无法发货 在途库存可以计入，但要按预计到货时间折算供应商延期导致虚假安全感 例如某 SKU 日均销量为 20 件，当前系统库存为 260 件，其中可售库存 150 件、锁定库存 30 件、残次品 40 件、在途库存 40 件。
如果直接使用 260 件计算，系统会认为库存还能覆盖 13 天；但真正可立即发货的库存只有 150 件，只能覆盖 7.5 天。我的判断是，库存自动化项目中最值得优先投入的不是复杂预测模型，而是库存字段治理。只要可售库存、在途库存和锁定库存没有明确区分，系统越自动，错误补货的速度反而越快。
启动时至少应建立 SKU、仓库、可售库存、锁定库存、不可售库存、在途库存、更新时间和数据来源这 8 个基础字段。
我以前只设置过一个安全库存值，库存低于这个数字就采购，结果有些商品仍然断货，有些商品却越补越多。再订货点和建议补货量到底是不是一回事，实际制定规则时应该怎么区分？
“什么时候补”和“补多少”是两个不同的决策，不能用一个安全库存阈值同时解决。前者关注库存是否已经接近风险区，后者关注补货后希望覆盖多长时间的需求。判断补货时点时，可以先估算交期内需求。一个简单的思路是：再订货点≈日均销量×采购交期＋安全库存。这个公式不是所有商品的最终答案，但适合用来搭建第一版规则。
假设某商品近 30 天剔除大促异常后的日均销量为 18 件，供应商平均交期为 7 天，交期波动较大，因此设置 50 件安全库存，那么再订货点约为 176 件。当可用库存加上预计能在交期内到货的在途库存低于这个水平时，系统才触发补货提醒。补货数量则应围绕目标库存计算。
假设企业希望该 SKU 补货后覆盖 21 天，目标库存约为 18×21＋50＝428 件；当前可售库存为 120 件，预计 5 天后到货的在途库存为 60 件，那么基础补货量约为 428－120－60＝248 件。若供应商要求 50 件为采购倍数，建议采购量应向上取整为 250 件。
实际测试规则时，我通常会额外加入三个限制：采购起订量、仓库容量和预算上限。因为数学上合理的 250 件，可能超过供应商最低采购量，也可能让仓库积压；因此系统输出的应该是“基础建议量＋约束条件修正后的建议量”，而不是一个脱离业务环境的固定数字。最容易被忽略的是在途库存的时间属性。
今天已经发货、预计两天后到仓的在途库存，和预计 20 天后才能到货的在途库存，不能用同一种方式抵扣需求。补货规则至少要结合预计到货日期，否则企业会在账面上有库存、实际履约时却发生断货。
我担心自动补货会把一次促销带来的异常销量当成长期趋势，导致采购过量；但如果所有订单都人工审核，自动化又失去了意义。有没有一种更稳妥的分层方法，可以判断哪些商品适合自动下建议单？
自动补货不应该按“所有 SKU 一套规则”设计，而应先按需求稳定性、缺货影响和供应链可靠性分层。销量高并不等于适合自动补货，稳定、可预测、交期可靠才是更重要的条件。
可以先用下面这套分层方式搭建规则： 商品类型自动化程度建议动作 销量稳定、交期稳定的常规品高自动计算补货量，金额低于阈值时可自动生成采购建议 销量高但受活动影响明显中系统计算，活动期间由运营或采购人工确认 新品或刚改版商品低设置试销库存和复盘节点，暂不自动采购 季节性商品或爆款商品中低单独维护活动参数和预测周期 滞销品、停售品或供应商不稳定商品禁止自动补货优先清理库存或切换供应商 促销是最容易让补货系统失真的场景。
例如某 SKU 平时日均销量 15 件，活动期间连续 3 天日销量达到 90 件。如果系统直接用近 7 天平均销量，计算出的日均销量会被抬高到约 47 件，后续可能持续建议大批量补货。更稳妥的做法是给销量数据增加事件标签，把自然销量、广告带来的增量、平台大促和异常订单分开。
活动销量可以参与专门的活动备货模型，但不应未经修正就进入常规补货模型。我建议把人工审核设计成“异常审核”，而不是让人工重新检查每一个 SKU。
比如当建议采购量超过过去 30 天销量均值的 2 倍、采购金额超过预算、供应商交期偏离历史平均值 30%，或库存数据超过 24 小时未更新时，系统才强制人工确认。这样既保留自动化效率，也能把高风险决策拦截下来。
我们目前只有订单后台、仓库表格和采购记录，SKU 数量大约 300 个，直接上复杂系统成本太高，但每天人工核对库存又很耗时。有没有一条从表格到系统的渐进式路径，而不是一开始就做一个很重的项目？
中小电商不必一开始就追求“自动下单”，更适合先建立一个可解释的补货建议流程。实际落地时，最稳妥的顺序通常是先统一数据，再做预警，最后才考虑自动生成采购单。
第一阶段可以用表格或轻量数据库建立最小字段集，包括 SKU、仓库、可售库存、在途库存、近 7 天销量、近 30 天销量、日均销量、采购交期、安全库存、再订货点、建议补货量、供应商、补货状态和最后更新时间。
例如 300 个 SKU 中，如果只有 60 个 SKU 贡献了 80% 的销售额，就不必一开始为全部商品配置复杂规则。可以先选出这 60 个高贡献 SKU，连续运行 4 周，观察建议补货量、实际销量和缺货情况，再逐步扩展到普通商品。
建议采用以下升级路线： 阶段目标验收标准 第一阶段统一库存和销量口径每天能解释库存差异来源 第二阶段生成低库存预警重点 SKU 不再依赖人工逐项查找 第三阶段输出补货建议每条建议都能追溯计算依据 第四阶段接入采购审批建议、审核、采购和入库状态可追踪 第五阶段对稳定 SKU 半自动补货异常订单和高金额采购仍需人工确认 第一版系统最重要的功能不是界面漂亮，而是让采购人员能回答三个问题：为什么现在要补货、建议补多少、这个数字使用了哪些数据。
如果系统只能给出“建议采购 500 件”，却不能展示销量、交期、在途库存和安全库存，采购人员通常不会真正信任它。上线后不要只看缺货率，还要同时观察库存金额、滞销库存占比、紧急采购次数、补货建议采纳率和供应商交期偏差。
自动化的目标不是把库存压到最低，而是在订单满足率、资金占用和供应风险之间找到可接受的平衡。对于数据基础较弱的团队，先把高频、稳定、金额可控的 SKU 做准，通常比一次性覆盖全部商品更容易成功。
读者评论
{"comments": []}