去年我帮一家做家居收纳的跨境卖家做补货复盘，他们上线 ERP 快一年半，SKU 从 400 多个涨到 1600 多个，店铺从 2 个开到 9 个，覆盖亚马逊、Shopee 和 Lazada。但他们的补货动作，仍然是两个运营每天早上打开各个平台后台，把库存截图粘到 Excel，再用计算器算「这个还能卖几天」。ERP 里存着完整的订单和库存数据，却没有一条能直接支撑「这周该给哪个 SKU 下多少采购单」。
这不是工具问题，是指标体系缺位，ERP 能记录发生了什么，但不会替你定义「什么叫做该补货了」。
这篇文章我想把「ERP 跨境电商管理要点」里最容易被跳过、又最影响现金流的一环讲透：采购补货的指标体系到底怎么设计。我不用「一键智能补货」这种话术，而是按我自己在几个卖家团队里落地的顺序，从口径、状态、需求、供给，一路推到补货量公式、ERP 落地方式和复盘闭环。看完之后，你应该能判断自己团队的补货逻辑卡在哪一层，以及下一步该先动哪个零件。
很多人把「指标体系」理解成 BI 看板上的十几个数字。这是个根本性误解。看板是输出物，指标体系的本质是一份团队内部对「补什么、补多少、什么时候补」的决策协议。协议不统一，看板再漂亮也只会变成吵架的工具，运营说该补，采购说没钱，老板说再等等。
结论一：指标体系的最终产出不是「一个建议补货量」，而是「一组可以追溯到原因的建议 + 分歧点」。系统的价值不在于算出一个数字，而在于告诉你这个数字是由哪些假设堆出来的。当采购不认可补货建议时，你们能立刻定位到是需求口径不一致，还是提前期假设不一致，而不是互相指责。
结论二：指标设计的正确顺序是「口径 → 状态 → 需求 → 供给 → 决策 → 复盘」，任何一步跳过都会返工。我见过最典型的返工是：先让技术团队把补货公式写进 ERP，跑了三个月发现数据全是错的，回头才发现「可用库存」这个字段在系统里根本没有明确定义，锁定的预售库存、待质检库存、退货在途全被算进了可售。
结论三：ERP 只是载体，没有口径的 ERP 只是把拍脑袋数字化。系统不会自动让补货变准，它只会把你原来的错误假设放大到 1600 个 SKU 上，并且以更高的效率执行错误。
先把场景说清楚。我接触过的卖家，绝大多数在 ERP 上线后的一年内，补货动作并没有实质性变化。变化的是「数据存到哪了」，不是「决策怎么做」。
那家家居收纳卖家的 ERP 里，每一天的订单、发货、库存变动都记得清清楚楚。但当运营要决定「这个 SKU 该不该补」时，他需要的是：未来 45 天的净需求预判、采购从下单到入仓的真实耗时、以及当前可动用的资金。这三样东西，ERP 的默认报表一样都不直接给。
于是运营只能退回到最原始的办法：看过去 30 天卖了多少，除以 30，再看库存能撑几天，凭感觉给个数量。这个过程里，「过去 30 天」包含了两次平台大促的销量峰值，实际日常需求被高估了将近一倍。
跨境电商和国内电商最大的区别在于，同一个物理 SKU 往往要在多个平台、多个国家、多个仓库之间调拨。这就带来三重口径冲突，任何一重没解决，补货建议就是废的。
第一重是平台口径冲突。同一个产品在亚马逊和 Shopee 上是两条独立的 listing，销量数据天然分离，但它们可能共用同一批国内库存。如果按平台单独算补货，就会出现两个平台同时下单、总采购量翻倍的情况。
第二重是仓库口径冲突。国内仓、FBA 仓、第三方海外仓、在途库存，四个位置的库存对补货决策的意义完全不同。FBA 仓的库存不能随便调拨，海外仓的库存不能退回，在途库存有到仓时间差。
第三重是时间口径冲突。采购看的是「下单日到入仓日」，运营看的是「入仓日到上架日」，广告投放看的是「上架日到起量日」。三个时间加在一起才是真正的补货提前期，但很少有团队把它拆开算过。
多平台数据归集是补货指标的第一步，也是最容易被低估的一步。我自己在梳理这类数据时，会用到数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）这类面向跨境场景的数据工具，把不同店铺、不同平台的订单和库存先拉到同一张表里，再往上叠补货指标。
这一步的价值不在于工具本身多强，而在于它能替你把「同一物理 SKU 跨平台销量合并」这个动作标准化。如果你的团队还在用 Excel 手工合并店铺数据，那么后面所有的需求预测和补货公式，都会建立在一份每周手动维护、随时可能出错的底表上。
这六个误区是我在不同团队里反复见到的，几乎每个都对应一次真实的库存事故。我按危害程度排序，越靠前的越容易造成大额损失。
「库存还有 800 件，不急。」这句话我听过太多次。800 件对于日销 5 件的 SKU 是 160 天库存，对于日销 80 件的 SKU 只有 10 天。库存绝对值不携带任何决策信息，唯一有意义的表述是「可售天数」。
更隐蔽的问题是，很多团队算可售天数时用的是「总库存 ÷ 日均销量」，而总库存里包含了锁定、待检、不良品。真实可售天数往往只有账面数字的六成。
月销量除以 30 是最常见的错误。它有两个致命缺陷：一是把大促峰值摊进了日常需求，导致淡季过度补货；二是把断货期间的零销量也算了进去，导致本就该多补的爆款被低估。
正确的做法是剔除断货日和大促日，只统计有货且有正常流量的天数。这两条规则一加，很多 SKU 的日均需求会变化 20% 以上，方向还不一定相同。
在途库存分很多种：已下单未发货、已发货未报关、已报关未到港、已到港未入仓、已入仓未上架。这五段的时间跨度和不确定性完全不同，把它们统一当成「在途」一个数字，补货建议的误差会非常大。
我的经验是，只有「已确认发货且预计到仓时间在补货周期内」的在途，才能按 100% 计入可用；其余部分要按到仓概率打折。采购在途未发货这一段，实际到仓概率可能只有 60% 到 70%。
「所有 SKU 统一留 15 天安全库存」是最省事也最贵的做法。安全库存的本质是对冲需求波动和提前期波动，波动大的 SKU 需要更多，波动小的 SKU 留 15 天纯属占用资金。
一个日销标准差 30 件、提前期波动 7 天的爆款，和一个日销标准差 2 件、提前期波动 2 天的长尾款，安全库存需求可能差 10 倍以上。
很多团队的「补货周期」只算供应商生产加国内发货，实际从决策到货架可售，中间还有头程运输、目的国清关、海外仓入库上架。这三段加起来，海运场景下往往比采购提前期还长。
漏算的结果是系统性缺货，每次补货都晚到两三周，运营只能靠临时空运救急，物流成本吃掉利润。
这是我见过最普遍也最难解决的问题。指标定义完了，看板也上线了，但缺货率的责任人是谁？滞销库存的责任人是谁？如果答案是「大家一起看」，那实际就是没人看。
有效的做法是把指标绑定到具体动作上：缺货率绑采购，动销率绑运营，滞销资金占用绑品类负责人，周转天数绑供应链负责人。没有责任人的指标，会在上线两周后自然消亡。
这一节是整个体系的地基。我在每个项目里都会先花两到三天把这三件事定死，再动任何公式。跳过这一步，后面全部是返工。
粒度决定了补货建议的颗粒度。常见的粒度有六种：父 ASIN、子 SKU、变体组合、店铺、平台、仓库。这六种粒度下算出来的补货建议可能完全不同。
我的建议是以「物理可采购单元」为主粒度，也就是你在采购单上实际会下单的那个东西，通常是最小销售单元加包装规格。然后在这个主粒度上附加平台、店铺、仓库作为维度，用来看分布，而不是用来做补货决策。
自然月的问题是有长有短、大促分布不均、月初月末效应明显。我会用滚动 7 天、滚动 14 天、滚动 28 天三个窗口并行：7 天反映短期趋势，14 天做主要需求估计，28 天用来看季节性基线。
同时建立一张「异常日标记表」，把平台大促、店铺自己做的促销、断货日、系统故障日全部标出来，这些天的销量在算日均需求时要剔除或单独处理。
库存状态必须是枚举值，不能是自由文本。下面这份状态字典是我在几个项目里反复迭代后的版本，可以直接拿去和 ERP 供应商对字段。
inventory_status:
AVAILABLE # 可售可用：能立即发货
RESERVED # 已售锁定：被订单占用，未出库
PICKING # 拣货中：已打印面单，出库流程中
QC_PENDING # 待质检：新到仓或退货入仓，未上架
DEFECTIVE # 不良品：不可售，待处理
IN_TRANSIT_FIRST # 头程在途：国内已发，未到目的国
IN_TRANSIT_LAST # 尾程在途：目的国已发，未到仓
IN_TRANSIT_PURCHASE# 采购在途：已下采购单，供应商未发货
RETURN_IN_TRANSIT # 退货在途：客户已退，未完成质检
补货计算中可扣减的库存：
sellable = AVAILABLE
有条件计入：
conditional = IN_TRANSIT_FIRST * 0.85 + IN_TRANSIT_LAST * 0.95
不可计入：
excluded = RESERVED + PICKING + QC_PENDING + DEFECTIVE + IN_TRANSIT_PURCHASE + RETURN_IN_TRANSIT
这段字典里最容易出错的是 RESERVED。很多 ERP 默认「库存数量」等于 AVAILABLE 加 RESERVED，如果直接拿这个数字算可售天数，未发货订单会被当成可售库存，导致该补的不补。
从平台后台看到的「销量」到补货能用的「净需求」，中间要过五道筛子。这五道筛子每道都会改变结果，必须显式记录，不能藏在代码里。
需求侧指标回答的是「未来一段时间大概要卖多少」。所有补货公式的基础都在这里，需求估错，后面全部白算。
日均净销量的定义是：统计周期内剔除断货日、大促日、非销售出库后的净销量，除以有货且有正常流量的天数。注意分母不是自然天数，而是「有效销售天数」。
我一般会并行计算三个口径：7 天净销量反映短期波动，14 天净销量作为补货主口径，28 天净销量用来识别季节性趋势。三个口径差异超过 40% 的 SKU，会自动进入「人工确认清单」，因为这说明它正处于趋势变化中，不适合自动补货。
动销率 = 有销量 SKU 数 ÷ 在架 SKU 数。这个指标主要用来看品类结构，而不是单个 SKU。健康的跨境店铺，30 天动销率通常在 55% 到 75% 之间，低于 50% 说明选品铺得太散，高于 85% 说明可能备货深度不够、断货拉低了上架完整性。
要注意动销率的统计周期。7 天动销率天然低于 30 天动销率，跨团队对比时必须统一周期，否则会得出完全相反的结论。
售罄率 = 某批次销量 ÷ 该批次到货量。这个指标在服装、饰品等有明显批次概念的品类里非常有价值，它反映的是「这批货好不好卖」，而不是「这个 SKU 好不好卖」。同一个 SKU 的不同批次，售罄率可能差一倍，直接影响下一批的采购量。
退货率 = 退货量 ÷ 销量。它对补货的影响是双向的：一是降低净需求，二是退货商品如果可重新上架，相当于增加了可用库存。高退货率品类（比如服装，退货率可达 15% 到 30%）如果忽略这一项，会系统性高估需求。
两个 SKU 可以有完全相同的日均销量，但一个是每天稳定卖 20 件，另一个是一周卖 0 件、一天卖 140 件。它们需要的安全库存和补货频率完全不同。所以日均销量必须和标准差、变异系数一起看。
我会把 SKU 按变异系数分成四档：低于 0.3 为稳定型，0.3 到 0.6 为一般波动型，0.6 到 1.0 为高波动型，高于 1.0 为脉冲型。脉冲型 SKU 一般不纳入自动补货，交给人工判断。
import numpy as np
import pandas as pd
def net_daily_demand(df, window=14):
"""
df 需包含字段: date, qty, is_stockout, is_promo, is_non_sales
返回剔除断货日、大促日、非销售出库后的日均净销量
"""
valid = df[
(~df["is_stockout"]) &
(~df["is_promo"]) &
(~df["is_non_sales"])
]
if len(valid) return np.nan # 有效天数太少，拒绝自动补货
return valid["qty"].sum() / len(valid)
def demand_volatility(df, window=28):"""变异系数 = 标准差 / 均值，用于判断能否自动补货"""
d = df[~df["is_stockout"]]["qty"]
if d.mean() == 0:
return np.inf
return d.std() / d.mean()
变异系数 > 1.0 的 SKU 走人工审核通道
需求侧算的是「要卖多少」，供给侧算的是「现在有多少、什么时候能到」。这两侧在补货点公式里会合流。
可售天数 = 可用库存 ÷ 日均净销量。这个比值是补货决策里最直观的指标，但它对两个输入都极度敏感，任何一个算错都会导致误判。
实际操作中我建议同时看三个版本：只用 AVAILABLE 算的「保守可售天数」、加上高概率在途算的「中性可售天数」、再加上采购在途算的「乐观可售天数」。三个版本的差距，本身就是提前期不确定性的度量。
在途库存是跨境电商补货里最混乱的一块。我的处理方式是按状态给计入系数，并且这个系数要根据历史准时率动态调整，而不是拍一个固定值。
| 在途状态 | 计入系数 | 调整依据 | 典型时间跨度 |
|---|---|---|---|
| 采购在途（已下单未发货） | 0.60 – 0.75 | 供应商历史准时发货率 | 15 – 45 天 |
| 头程在途（已发货未到港） | 0.80 – 0.90 | 货代历史准点率、清关异常率 | 20 – 40 天 |
| 清关中（已到港未放行） | 0.70 – 0.85 | 目的国清关平均滞留天数 | 3 – 15 天 |
| 目的国尾程在途 | 0.90 – 0.95 | 本地物流商时效稳定性 | 2 – 7 天 |
| 海外仓已入库未上架 | 0.95 – 1.00 | 仓库上架处理效率 | 1 – 5 天 |
| 退货在途待质检 | 0.20 – 0.50 | 品类退货可再售率 | 7 – 30 天 |
这张表的关键在于「调整依据」这一列。系数不是拍出来的，是从历史数据里算出来的。每季度用实际到仓时间和预测到仓时间做一次对比，更新一次系数，这个动作能让补货准确率提升非常明显。
库存周转天数 = 平均库存成本 ÷ 销售成本 × 统计天数。它衡量的是资金效率，主要给财务和老板看。跨境场景下要特别注意口径：平均库存是否包含在途、销售成本是否含头程物流和平台佣金，不同算法结果差异能到 30% 以上。
缺货率 = 缺货 SKU 天数 ÷ 总 SKU 天数。这个指标是补货体系最直接的效果反馈。如果缺货率没有下降，说明补货点或者补货量设置有问题；如果缺货率下降但周转天数上升，说明阈值设得太保守，用资金换来了安全。
前面所有指标都是为这一节服务的。补货决策指标要输出的是三个数：什么时候补（补货点）、至少要留多少（安全库存）、这一次补多少（建议补货量）。
补货点 = 补货周期内的需求 + 安全库存。这里的「补货周期」指的是从下单到货物可售的完整时间，包含供应商生产、国内发货、头程运输、清关、目的国入仓上架全部环节。
很多团队只算供应商交货期，把补货周期算成 20 天，实际完整周期是 55 天。这 35 天的差距，就是那家家居卖家每周都在「救火空运」的根本原因。
安全库存的经典公式是：安全库存 = 服务水平系数 × 需求标准差 × √补货周期 + 服务水平系数 × 平均需求 × 提前期标准差。
两个加项分别对冲需求波动和提前期波动。实践中最容易被忽略的是第二项，大部分团队的提前期标准差非常大，因为它不是一个稳定值，而是受工厂排期、船期、清关抽查共同影响的随机变量。
服务水平系数按目标缺货率查正态分布表：目标不缺货率 90% 对应 1.28，95% 对应 1.65，98% 对应 2.05，99% 对应 2.33。把服务水平从 90% 提到 98%，安全库存会增加 60%，这是一个明确的资金换安全感的取舍，必须由业务负责人拍板，不能由系统默认。
建议补货量 = 目标覆盖期需求 − 可用库存 − 有效在途 + 安全库存。这个公式看起来很干净，但直接用它下采购单，十次里有八次会被采购驳回。原因是它没考虑现实约束。
约束一是 MOQ，供应商最小起订量。算出来要补 180 件，供应商起订 500 件，这时候要么补 500 件承担多余库存，要么找其他供应商，要么接受缺货。
约束二是装箱率。算出来补 480 件，一箱装 60 件，那就补 480 件；算出来补 490 件，实际要补 540 件。装箱率的取整方向会影响几个百分点的库存水位，必须显式处理。
约束三是资金上限。所有 SKU 的建议补货量加总后，如果超过本期可用采购资金，就需要按优先级分配。这时候分级策略就派上用场了：保爆款、砍长尾、新品按最小起订量试。
约束四是物流方式。空运和海运对同一批货的到仓时间差 30 天以上，补货量必须和物流方式绑定计算，不能先算量再选物流。
def suggest_purchase_qty(
daily_demand, cover_days, safety_stock,
available_qty, transit_inbound,
moq, carton_size
):
"""建议补货量的基础计算，含 MOQ 与装箱率约束"""
target = daily_demand * cover_days + safety_stock
raw = target – available_qty – transit_inbound
if raw return 0
先满足 MOQ
qty = max(raw, moq)
再按装箱率向上取整
qty = math.ceil(qty / carton_size) * carton_size
return qty
注意：向上取整会系统性推高库存水位，
对长尾 SKU 建议改为向下取整 + 提高补货频率
这段代码里有一个容易被忽略的判断：向上取整还是向下取整，应该由 SKU 分级决定。爆款可以向上取整保住销售机会，长尾款应该向下取整，宁可断货几天也不要压一整箱库存。
用一个公式套所有 SKU，是补货体系最常见的失败原因。我会把 SKU 分成四类，每类给不同的覆盖天数、安全库存策略和复盘频率。
| SKU 分级 | 目标覆盖天数 | 安全库存策略 | 补货频率 | 取整方向 |
|---|---|---|---|---|
| 爆款（销量前 20%） | 60 – 75 天 | 按服务水平 98% 计算 | 每周复核 | 向上取整 |
| 平销款（中间 50%） | 45 – 60 天 | 按服务水平 95% 计算 | 每两周复核 | 向上取整 |
| 长尾款（后 30%） | 30 – 45 天 | 按服务水平 90% 计算 | 每月复核 | 向下取整 |
| 新品（上架 90 天内） | 按最小起订量试销 | 不设统计安全库存 | 每周人工判断 | 按 MOQ |
这张表里的数字不是标准答案，是起点。真正的参数应该在你自己的数据里跑 2 到 3 个补货周期后调整，尤其是目标覆盖天数，它和你的资金成本、仓储成本、断货损失三者直接相关。
前面七节是方法论，这一节讲落地。方法再好，如果每天要人工从九个店铺后台导数据，坚持不了两周就会荒废。
我在几个团队里推这套体系的顺序都是：先解决数据归集，再解决指标计算，最后才考虑把补货动作塞进 ERP 的采购模块。反过来做，也就是先让 ERP 输出补货建议，往往会在数据口径阶段就卡死。
数跨境（https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）这类工具解决的就是第一步：把多平台、多店铺的订单、库存、商品数据统一到一个可查询的数据层。它的价值主要体现在三件事上。
第一件是物理 SKU 的跨平台映射。同一个产品在不同平台的 listing ID 不同，需要用一张映射表把它们绑到同一个物理 SKU 上，否则需求会被拆散，每个平台都算出一份不完整的补货建议。
第二件是库存状态的统一表达。不同平台对「可用库存」的定义不一样，亚马逊的 Available 和 Shopee 的可用库存，口径并不相同。归集层需要把这些口径翻译成前文那份统一的状态字典。
第三件是历史数据的可回溯性。补货复盘需要半年甚至一年的日销数据，平台后台通常只给最近 60 到 90 天。归集层如果不做持久化存储，你的季节性和趋势分析就永远做不了。
我见过太多「什么都有」的看板，最后没人看。补货相关的看板，我建议只放三块内容。
第一块是补货建议清单，按紧急程度排序，每行显示 SKU、当前可售天数、建议补货量、建议下单日期。这一块是给采购用的，必须能直接导出成采购单草稿。
第二块是异常清单，包含三类：需求口径三个窗口差异超过 40% 的、在途超过预计到仓时间 7 天的、库存状态异常的。这一块是给运营和供应链用的，每天处理一次。
第三块是健康度概览，就四个数：缺货率、周转天数、滞销资金占比、预测偏差。这一块是给管理者用的，每周看一次趋势。
我不建议让系统自动下采购单，除非你的 SKU 结构极度稳定、供应商极度可靠。更现实的方案是系统生成建议，人工审核例外：符合规则的 SKU 直接通过，触发异常规则的 SKU 进入人工确认。
异常规则的伪代码大致如下，可以直接作为和技术团队沟通的输入。
def needs_manual_review(sku): if sku.demand_cv > 1.0: # 脉冲型需求 return True, "需求波动过大" if sku.valid_days return True, "数据样本不足" if sku.window_gap > 0.40: # 多窗口需求差异过大 return True, "需求趋势不稳定" if sku.transit_delay_days > 7: # 在途严重逾期 return True, "在途异常" if sku.is_new_within_days return True, "新品试销期" if sku.suggest_qty * sku.unit_cost > 50000: # 单笔金额过大 return True, "大额采购需审批" return False, "自动通过"
这套规则的意义在于，把人的注意力从 1600 个 SKU 收敛到 50 个真正需要判断的 SKU 上。我实测下来，人工审核量能降到原来的十分之一左右，同时不会漏掉真正的风险点。
同样一套指标体系，不同规模的团队落地路径差别很大。我按四种常见情况给建议，你可以直接对号入座。
这个阶段不需要复杂模型。我的建议是先做三件事：统一库存状态字典、算准日均净销量、给每个 SKU 设一个目标覆盖天数。
补货公式用最简版本就够：建议补货量 = 日均净销量 × 覆盖天数 − 可用库存。安全库存先按固定天数处理，等数据积累到 6 个月以上再引入波动率计算。
这个阶段最容易犯的错是过早引入自动化。SKU 少的时候，人工判断的准确率其实不低，把精力放在口径准确上，收益比引入算法大得多。
这是最需要指标体系、也最容易做错的阶段。核心问题是跨平台需求合并和库存共享。必须建立物理 SKU 映射表，并且明确哪些库存是共享的、哪些是平台独占的。
数据归集建议用工具而不是 Excel，用数跨境这类工具把多平台数据拉到统一层，然后在其上做指标计算。这个阶段如果还靠手工合并，数据错误率会高到让整套体系失去意义。
把 SKU 分成爆款、平销、长尾、新品四类，给四套参数。这个动作的投入产出比在整个体系里是最高的。
到了这个规模，补货问题会分裂成两个问题：补多少货到总仓，以及怎么在多个仓库之间分配。这两件事要用不同的指标体系。
总仓补货看总需求，用前面讲的完整公式。仓库分配看的是各仓的覆盖天数均衡度、调拨成本和调拨时效。很多团队把这两件事混在一起算，结果总仓补了货，海外仓还是断货。
这个阶段建议引入调拨指标：各仓可售天数极差、调拨在途天数、跨仓调拨成本占比。这三项共同决定分配策略。
这类团队的优势是提前期可控，劣势是产能约束。重点应该从「补货量」转向「产能排期」。
我会增加两类指标：一是工厂产能利用率与订单排期匹配度，二是原材料备料周期与生产周期之和。当补货周期的主要瓶颈从物流转向产能，补货点公式里的提前期就要用产能排期数据来算，而不是用历史物流时效。
指标体系不是越多越好，每个指标都有维护成本和解读成本。能不能砍掉一个指标，取决于它是否改变了你的行动。如果一个指标看了之后你不会做任何不同的事，它就不该存在。
长尾 SKU 占了库存资金的相当比例，但单个 SKU 的销售额很小。给它们做精确的需求预测，投入产出比极低。
我的做法是长尾 SKU 不做预测，只做规则：覆盖天数压到 30 到 45 天，安全库存用固定的小批量，补货按 MOQ 一次补最小量，缺货了接受缺货。牺牲一部分长尾的可得性，换来资金集中到爆款上，这是明确划算的。
一个能被团队真正用起来的补货指标体系，核心指标不应该超过 12 个。我的推荐组合是：需求侧 4 个（日均净销量、动销率、退货率、需求变异系数），供给侧 4 个（可用库存、可售天数、有效在途、缺货率），决策侧 2 个（补货点、建议补货量），复盘侧 2 个（周转天数、预测偏差）。
超过 12 个之后，最大的问题不是看不完，而是指标之间开始互相矛盾，团队会挑对自己有利的那个看。这是很多指标体系失效的真实原因，不是技术问题，是组织问题。
自动化程度应该和数据质量匹配。我的原则是：只有当某个 SKU 连续 3 个补货周期的预测偏差都低于 20%，才允许它进入自动补货通道。
这个门槛看起来严，但能避免系统在数据清洗还没做好的阶段，高效率地执行错误决策。自动补货的杀伤力在于它快，而快在错误口径下是负资产。
很多团队会问「有没有免费的跨境 ERP 能用」。这个问题的正确问法不是「免费吗」，而是「免费版本在数据归集、状态自定义、报表导出、API 这几项上的边界在哪」。
根据我看到的情况，免费或低价版本通常在四个方面有边界：一是店铺数量和订单量上限，二是自定义字段和状态字典的灵活度，三是历史数据保留周期，四是 API 或批量导出能力。前两项影响指标体系能不能建起来，后两项影响能不能做长期复盘。
我的建议是：把 ERP 当作执行层，把数据归集和指标计算放在更灵活的数据工具里。这样即使将来更换 ERP，你积累的历史数据和指标口径还能保留，不会被工具绑定。
最后给你一份可以直接执行的路线。我在几个团队推这套体系，从零到跑通基本是 4 周，前提是有人专职推进。
第一周只做一件事：把库存状态字典、物理 SKU 映射表、异常日标记表建起来。这一周不出报表、不做看板，看起来没产出，但决定了后面三周会不会返工。
交付物是三份文档和一份数据表：库存状态字典、物理 SKU 映射规则、异常日判定规则，以及一份清洗后的历史日销数据表。
第二周把第五、六节的指标算出来，先不做决策，只看数据是否合理。重点检查三件事：日均净销量和运营的直觉是否严重冲突、可售天数为负或超过 300 天的 SKU 有多少、在途数据是否和实际物流状态对得上。
如果可售天数有超过 10% 的 SKU 出现异常值，说明口径还有问题，不要急着进入第三周。
第三周开始输出补货建议，但只作为参考，不下采购单。把系统建议和采购的实际判断做对比，记录差异原因。这一周的价值在于校准阈值，你会发现某些品类的覆盖天数设得明显不合理。
同时上线异常清单，让运营和采购每天处理一次。处理速度和判断质量会在这周内快速提升。
第四周开始建立复盘机制。每周固定时间看四个数：缺货率、周转天数、滞销资金占比、预测偏差。重点是看趋势而不是看绝对值，任何一项连续两周恶化，就要回去检查对应的阈值或口径。
复盘的核心问题是固定的三句：这周哪些 SKU 的判断错了？错在需求侧还是供给侧？需要调整的是口径、参数还是流程？
回到开头那家家居卖家。他们后来做的事情并不复杂：先把库存状态拆成六种，再把日均销量按剔除大促和断货的口径重算，然后给 1600 个 SKU 分成四类，各给一套覆盖天数和安全库存参数。整套东西跑起来大概用了五周，中间返工了两次，都是因为口径没定死就急着上公式。
三个月后他们的缺货 SKU 占比从 14% 降到 6% 左右，滞销库存资金占比从 31% 降到 19%。但我觉得更有价值的改变不是这两个数字，而是运营和采购终于能就同一个 SKU 补多少展开有效讨论了。以前是「我觉得该补」对「我觉得不该补」，现在是「你的需求口径用的是 7 天还是 14 天」对「你的提前期假设有没有包含清关」。分歧还在，但从立场之争变成了参数之争，这是可以被解决的问题。
如果你现在正准备给团队搭这套体系，我的建议是从最小的动作开始：先花两个小时，把你们 ERP 里的库存状态字段全部列出来，逐个定义它能不能计入可售库存。这一个动作不需要任何工具，也不需要技术资源，但它会立刻暴露你们现有的补货计算里有多少水分。做完这一步，再决定要不要往下推进整套指标体系。
我之前上ERP后直接看库存数量补货，结果多平台库存对不上，采购建议忽高忽低。后来才发现SKU、仓库、在途、时间窗口这些口径没统一，想问到底先定什么。
先定四个口径。统计粒度至少到SKU加仓库加平台，不然多平台超卖无法追责；时间窗口用滚动7天、14天或30天净销量，大促日剔除或单独标记，避免峰值污染日常补货；库存状态必须分开可用、锁定、在途、待检、不良、退货在途，在途再分已发未发、清关、到仓，只有可用库存加有效在途能参与补货点计算；
责任人与动作要对应，比如可售天数低于阈值进采购建议，高于滞销线进清货清单。判断依据很简单，如果两个运营对同一SKU算出不同建议量，大概率不是公式问题，而是口径没统一。
我看了很多公式，可售天数等于库存除以日均销量，补货点等于提前期需求加安全库存，但实际用起来不是断货就是压货。我怀疑是需求波动和提前期不稳定没处理，想知道具体怎么修正。
公式本身没错，错在把不稳定数据当稳定用。可售天数等于可用库存除以日均净销量，日均净销量要扣退货、取消、刷单，建议用近14天或30天滚动中位数，大促剔除。
补货点等于采购提前期需求加安全库存，安全库存等于服务水平系数乘以需求标准差再乘以补货周期的平方根，服务水平系数按缺货成本定，爆款可取1.65即95%以上，平销取1.28即90%，长尾可低。建议补货量等于目标覆盖期需求减可用库存减有效在途加安全库存，再被MOQ、装箱率、资金上限修正。
判断依据是，如果预测偏差连续两周超过30%，先别调公式，先检查数据口径和促销剔除。
我们做速卖通、Shopee、Lazada多店，库存经常这边卖了那边还在建议补货，采购重复下单，最后压一堆货。我想知道ERP里到底怎么设库存共享和补货规则。
先把库存分成物理库存和渠道可售库存两层。物理库存按仓库归集，渠道可售库存按平台和店铺分配，设置安全缓冲或预留比例，比如爆款预留10%到15%给突发订单。补货建议只认物理可用库存加有效在途，不认各店铺前台可售数，否则会重复计算。
多平台共用库存时，补货点按合并需求计算，再按历史动销占比把建议量拆到采购单，但采购单合并下单。每天跑一次渠道库存对账，发现某平台可售库存与物理库存差异超过5%就查超卖或同步延迟。判断依据是，如果同一个SKU在A店显示可售、B店也显示可售，但物理库存只有一份，补货建议必须去重。
我们一开始给所有SKU设了同一个可售天数阈值，结果爆款老断货，长尾压了一堆库存。老板还问我为什么指标看板不直接给补货量。我想知道分级策略具体怎么定，ERP怎么落地。
不能。按动销和毛利分四级。爆款用高服务水平、短覆盖期、高频补货，比如可售天数低于21天触发，安全库存取95%服务水平；平销用中等，低于30天触发，90%服务水平；长尾用低安全库存，低于45天才看，且优先清库存而不是补；
新品没有历史销量，用同类目相似款或小批量试销，首单按预估30天销量的一半，两周后按实际动销修正。ERP落地时，看板给建议补货量和异常清单，自动补货只覆盖爆款和平销，长尾和新品走人工审批。
判断依据是，分级阈值每季度用缺货率、周转天数、滞销库存占比复盘一次，爆款缺货率高于5%就放宽安全库存，长尾周转超过90天就降覆盖期或停补。
读者评论
文章把可售天数、在途状态和平台归属讲得很实在。很多 ERP 上线后补货仍靠 Excel，就是因为可用库存没拆状态，尤其预售锁定和退货在途混在一起，算出来必然虚高。建议先统一库存状态字典，再谈补货公式。
六个误区里“只算采购提前期，不算头程和清关”最扎心。海运补货若漏掉清关和上架时间，系统建议再准也会晚到。按到仓概率给在途打折、把安全库存跟波动挂钩，比统一留 15 天更合理。
指标设计顺序“口径→状态→需求→供给→决策→复盘”是重点。很多团队先写公式后补口径，结果返工。用 BI 看板展示可解释率、缺货率、滞销资金占比，能推动采购和运营对齐，不然数字只会变成吵架依据。
责任绑定那段很有共鸣。缺货率挂采购、动销率挂运营、滞销资金挂品类负责人，指标才活得下去。另外多平台共用库存时若按平台单独补货，确实会重复下单，跨平台合并物理 SKU 是前提。