去年下半年，我帮一家做家居品类的亚马逊卖家复盘补货流程。他们的 ERP 已经上线一年半，采购、库存、海外仓模块全部开通，系统每天都会跑出一批补货建议。但采购主管给我看的一张 Excel 让我印象很深：一个月系统给出 1200 条补货建议，采购人工修改了 730 条，改单率超过 60%，其中 180 条直接弃用改成手工下单。
他们的第一反应是"ERP 的补货算法不行"。可我把数据拉出来对齐一遍后发现，真正的问题跟算法几乎无关：运营看的销量是"近 7 天含广告口径"，系统取的是"近 30 天自然销量"；FBA 在途数据靠运营每周手动填一次，平均滞后 5 天；安全库存所有 SKU 共用 15 天一个值；海外仓可用库存里还混着已经被平台活动锁定的量。口径不统一，再好的算法也算不出采购敢用的数。
这就是本文要回答的问题：跨境电商 ERP 的采购补货，指标体系到底怎么处理？我的核心判断是，补货指标体系的本质是"口径治理 + 阈值分层 + 动作绑定"，不是"算法选型"。指标不是报表字段，而是触发采购、调拨、发货动作的规则。下面我把这套判断的来龙去脉、四层框架、落地步骤和取舍逻辑完整讲一遍。
先说结论，再讲论证。补货指标体系失效，通常不是模型精度不够，而是同一个指标在不同部门有不同算法。采购按 A 口径看到的"可售天数"，和运营按 B 口径看到的"可售天数"，可能差出一倍。双方都在用同一个词，讨论的却是两个东西，最后只能靠开会拍板。
我在过去几年接触的跨境卖家里，补货建议的"可直接采纳率"大致落在三个区间：数据源靠人工填报的，采纳率通常低于 40%；数据自动接入但口径未统一的，落在 50%，70%；数据自动接入且口径写入指标字典的，能到 80% 以上。
这条规律的含义是：补货建议的可采纳率，天花板由数据口径决定，而不是由预测模型决定。模型再先进，输入的是口径混乱的数据，输出的一定是采购不敢用的建议。
我判断一个补货指标能不能进系统，会看它有没有五件事：
五个要素缺一个，这个指标就还停留在"报表字段"阶段，进不了决策链路。我见过太多 ERP 项目，指标算得挺全，但一个触发动作都没配，最后 BI 看板很漂亮，采购该催货还是催货。
国内电商补货，前置期短、仓库集中、平台规则简单，一个 7 天日均销量加一个安全库存就能跑。跨境要在同一套指标里同时容纳六种复杂性：
| 复杂性来源 | 具体表现 | 对指标的直接影响 |
|---|---|---|
| 多平台 | 亚马逊、Shopee、TikTok Shop、独立站销售节奏不同 | 同一个 SKU 需要多套日均销量基线 |
| 多仓 | 国内仓、海外仓、平台仓并行 | 库存要按仓拆开，补货要分仓决策 |
| 长在途 | 头程海运 30，45 天，空运 7，12 天 | 在途数据必须实时可见，否则补货点全错 |
| 平台仓规则 | 库容限制、入库限制、库存绩效门槛 | 补货量要额外受"能入多少"约束 |
| 供应端波动 | MOQ、装箱率、供应商交期不稳 | 补货量要按包装单位取整，不能只看理论值 |
| 财务因素 | 汇率、关税、退税、账期 | 同样的销量，不同时期的资金占用完全不同 |
这六种复杂性决定了跨境补货不可能用"一套阈值通吃"。下面这张图展示了口径分裂对人工改单率的影响，数据来自我对若干卖家项目的样本推演，不是行业统计。
我把前面那个家居卖家的场景完整还原一下。这个案例的所有数据我都做了脱敏和比例调整，但结构和断点位置是真实的。
卖家基本情况：3 个销售平台（亚马逊美国站、亚马逊欧洲站、独立站），3 个仓库（深圳国内仓、美国海外仓、亚马逊 FBA），在售 SKU 约 800 个，月均订单 2.6 万单，采购以国内供应商为主，海运为主、空运补急。
他们在 ERP 里已经开了补货模块，配置得很"完整"：有补货周期、有安全库存、有补货建议、有标签提醒、能生成采购计划。表面看，这套配置该有的都有了。
运营团队看的是"近 7 天日均销量含广告"，理由是"广告带来的销量也是真实需求"；ERP 补货模块取的是"近 30 天自然销量，剔除缺货日"；财务做预算用的是"近 30 天净销量，扣除退款"。
三套口径算出来的日均销量，同一个爆款 SKU 分别是 42 件、31 件、27 件。同一个 SKU 的需求基线差了 55%，补货建议当然对不上。采购每次下单选哪套口径，取决于当天先看到谁的表。
ERP 库存字段里有一个"库存数量"，但采购真正需要知道的是五个数：可用库存（能卖的）、锁定库存（被活动或订单占用的）、不可售库存（破损、待检）、在途库存（已发未到）、在制库存（已下单未发货）。
他们系统里只有前两个字段在实时更新，后三个靠运营每周手动填一次。结果就是：采购看到的"库存"包含了不能卖的部分，算出来的补货量系统性偏低。
海运在途平均 38 天，空运 9 天。他们的在途数据由物流专员每周五更新一次 Excel，再导入 ERP。这意味着周一采购在系统里看到的在途量，反映的是上周五的状态。
差这 5 天，在长在途场景下是致命的。在途数据的滞后会被前置期放大：前置期越长，前置期内发生的到货越容易被漏算，采购就会重复下单，或者反过来，已经到港的货没及时入账，系统以为还在途，建议继续补。
他们给所有 SKU 配了一套参数：补货周期 30 天，安全库存 15 天。结果是爆款经常断货，长尾品却压了一堆货。原因很直接：爆款的需求波动大、前置期长，需要更高安全库存；长尾品需求稳定但周转慢，15 天安全库存在它身上就是纯占用。
再叠加"所有平台共用一套阈值"，问题更明显：亚马逊美国站卖得快，独立站卖得慢，同一个 SKU 用一套补货点，必然一边缺货一边积压。
他们系统里有"库存天数"这个指标，也有"低于 X 天提醒"的功能，但提醒只发到运营主管邮箱，运营主管看不过来，也不会转给采购。指标算了，但没人执行。
这五个断点叠加起来，就形成了开头那张表：1200 条建议，730 条被改。改单不是采购不信任系统，是系统确实没法直接用。
上面是一个具体案例。把视角拉高，我在不同卖家那里反复看到七类结构性误区。它们不是配置错误，而是设计思路走偏。
库存天数（可售天数）是最直观的指标，也是最容易被滥用的。它的致命缺陷是：库存天数不区分需求波动，也不区分前置期长短。
两个 SKU 都是 20 天可售天数，A 前置期 45 天，B 前置期 7 天，风险完全不同。A 已经来不及补了，B 还可以再等等。只看库存天数，会把这两个 SKU 归到同一优先级。
这是我在几乎每个数据没打通的卖家那里都会看到的。可用、锁定、不可售、在途、在制混在一起，账面库存很充足，实际能卖的可能只有三分之一。
判断标准很简单：如果你的 ERP 库存表里，采购下单时需要的扣减项少于四项，这个补货公式一定不准。
安全库存的本质是对不确定性的缓冲。需求波动越大、前置期越长、前置期波动越大，安全库存就应该越高。用一个固定值通吃，等于对不确定性视而不见。
我通常建议至少按"销量分层 × 前置期分层"做一个二维矩阵，把 SKU 分成 3，4 个安全库存档位，再叠加平台和仓库维度做微调。
很多卖家以为补货问题的解决方案是"上一个更好的预测模型"。但预测和补货是两件事：预测回答"未来卖多少"，补货规则回答"现在下多少单、什么时候下、按什么包装下"。
预测精度提升 10%，如果补货规则没定义清楚，缺货率未必下降。反过来，预测一般但规则严谨，缺货率反而可控。这是我做了多个补货项目后最确定的判断之一。
指标必须绑人绑动作。一个没有责任人的指标，本质上是一条没人看的报表。我在项目里会强制给每个核心指标写清楚三件事：越线后系统做什么、谁在多久内处理、处理不了升级给谁。
跨境特有的坑。亚马逊 FBA 有库容限制、入库数量限制、库存绩效门槛，补货建议算出来的量，可能根本发不进去。如果补货系统不考虑这个约束，建议就是废的。
正确做法是：补货量先按需求算，再按平台仓可接收量截断，差额自动转成海外仓备货或延后建议。这个截断逻辑必须在系统里显式配置，不能靠人在 Excel 里手动改。
这三种销量的可持续性完全不同。广告停投后销量可能腰斩，活动结束后的回落也很常见，只有自然销量是相对稳定的基线。用混合销量做补货基线，会导致广告一停就积压。
我的建议是至少拆成三个字段，补货基线用"自然销量 + 广告销量的衰减后贡献"，而不是简单加总。
讲完问题，讲解法。我在项目里用的框架是把补货指标分成四层：需求层、库存层、供应层、执行层。每一层回答一个具体问题，层与层之间是递进关系，不是并列的功能清单。
需求层是所有补货计算的起点。它的输出是一个"需求基线"，也就是日均销量。这个数怎么算，直接决定后面所有公式的准确性。
我推荐的口径是：日均销量 = 有效销量 ÷ 有效销售天数。有效销量剔除退款、赠品、刷单、测试订单；有效销售天数是总天数减去缺货天数和未上架天数。
为什么要剔除缺货日？举个极端例子：一个 SKU 在 30 天里断货 12 天，总销量 180 件。不剔除缺货日算出来是 6 件/天，剔除后是 10 件/天。差了 67%，直接决定补货量差一半。
窗口长度没有标准答案，但有判断依据：需求波动越大、生命周期越短，窗口应越短；需求越稳定、季节性越强，窗口应越长。我的经验值是按品类分三档，再按月迭代。
需求层的第二个作用是筛选。动销率告诉你哪些 SKU 在正常出货，滞销率告诉你哪些 SKU 应该停止补货、进入清库存流程。我通常把 SKU 分成四类：
没有这个分层，补货系统会把资源平均分配，结果是爆款缺货、滞销款压仓。
库存层是把库存按状态拆开，并计算出可售天数和库存健康度。这一层最常见的错误就是只用一个数。
可用库存、锁定库存、不可售库存、在途库存、在制库存。补货公式真正参与计算的扣减项是：可用库存 + 在途库存 + 在制库存。锁定和不可售要单独列示，用来看风险，不直接抵扣。
国内仓、海外仓、平台仓不能简单相加。合理的处理是：先按仓分别算可售天数，再按"该仓服务的销售渠道"合并。
举个例子：亚马逊美国站的货来自 FBA 和海外仓，那这两个仓要合并算覆盖；独立站的货主要来自海外仓，就单独算。如果三个仓直接相加，会得出一个虚高的覆盖天数，掩盖某个渠道已经断货的事实。
| 指标 | 计算口径 | 用途 | 常见参考线 |
|---|---|---|---|
| 可售天数 | 可用库存 ÷ 日均销量 | 判断紧急程度 | 低于前置期即为风险 |
| 库存周转率 | 销售成本 ÷ 平均库存成本 | 评估资金效率 | 按品类设定，年度对比 |
| 缺货率 | 缺货 SKU 天数 ÷ 总 SKU 天数 | 评估保供能力 | 行业常见目标 3%，8% |
| 滞销占比 | 滞销库存金额 ÷ 总库存金额 | 评估库存质量 | 高于 15% 需干预 |
| 库容占用率 | 已用库容 ÷ 可用库容 | 评估补货空间 | 高于 85% 需预警 |
供应层是把前置期、波动、MOQ 这些约束纳入计算。这一层是跨境和国内电商差异最大的地方。
很多卖家填的采购提前期是"供应商承诺交期"，比如 20 天。但真实周期是：下单 → 供应商排产 → 生产 → 质检 → 发货 → 头程 → 清关 → 入仓。这个链条通常是 45，70 天。
用承诺交期算补货点，等于系统性地晚补 30 天。我的做法是让系统自动统计历史订单的"下单到入库"实际天数，取 P50 和 P80 两个值，P50 用于常规计算，P80 用于旺季和爆款。
安全库存不是拍一个天数，而是由三个变量决定：需求波动、前置期长度、前置期波动。经典的量级估算方式是：
安全库存 ≈ Z × √(LT × σ_d² + d² × σ_LT²)
其中：
Z = 服务水平对应的系数（95% 服务水平约 1.65）
LT = 平均前置期（天）
σ_d = 日需求标准差
d = 平均日需求
σ_LT = 前置期标准差（天）
实际项目中我不会要求卖家精确计算标准差，而是用简化档位：把 σ_d ÷ d（需求变异系数）和 σ_LT ÷ LT（前置期变异系数）各分三档，做成 3×3 的九宫格，每个格子给一个安全库存天数建议值。这样既保留了波动逻辑，又能在系统里落地配置。
理论补货量算完不能直接用。必须过三道取整：按最小起订量（MOQ）向上取整、按装箱率（每箱件数）向上取整、按柜型或运输方式的装载量优化。
这里有个容易被忽略的取舍：向上取整会让库存略高于理论最优，但如果取整幅度超过 30%，说明这个 SKU 的 MOQ 和销量不匹配，应该考虑合并采购或换供应商。
再订货点回答"什么时候下单"，补货量回答"下多少"。两者的关系是：
再订货点 ROP = 日均销量 × (采购提前期 + 物流时效) + 安全库存
建议补货量 = (覆盖周期天数 × 日均销量) + 安全库存
可用库存 – 在途库存 – 在制库存
最终下单量 = max(MOQ取整(建议补货量), 0)
再按装箱率向上取整
再按平台仓可接收量截断
这个结构看起来简单，但每一个变量背后都是一次口径决策。日均销量用哪套、前置期取 P50 还是 P80、在途包不包含已到港未清关的货，这些才是真正决定补货准确率的地方。
执行层是把上面三层算出来的结果，转换成系统里的具体动作。这一层做不好，前三层做得再精细也没用。
补货周期不应该是一个全局值，而应该按 SKU 分层配置。爆款可以每周跑一次，长尾品可以每两周或每月跑一次。分层的依据是销量占比、波动性和前置期。
系统跑完补货计算后，应该给每个 SKU 打上明确的标签，比如"紧急补货""常规补货""暂缓补货""停止补货""待清货"。标签的作用是把决策成本前置到规则里，让采购每天只需处理"紧急"和"异常"两类。
补货建议要能一键转成采购计划，采购计划审批后生成采购单；涉及海外仓的，要能生成调拨单；涉及平台仓的，要能生成发货计划。这条链路断在哪一环，哪一环就会退回 Excel。
这是我认为最被低估的一环。必须显式配置五类异常：数据缺失、数据超期未更新、建议量超出常规范围、平台仓不能接收、人工强制干预。每类异常要指定处理人和处理时限。
关于自动化，我的判断是：补货不该追求"无人干预"，而应该追求"规则触发 + 异常拦截 + 人工审批"。系统负责 90% 的常规 SKU，人负责 10% 的异常和重大决策，这才是健康的比例。
框架讲完，讲落地。四层指标体系要在系统里跑起来，前提是数据能自动接入、口径能统一定义、指标能输出到决策界面。这一步靠 ERP 的采购模块自己很难完成，通常需要一个独立的数据层。
我在项目里的顺序是固定的：先打通数据，再统一口径，最后才调算法。原因很直接，如果日均销量的口径每两周被改一次，算法再怎么调都是在追一个移动靶。
数据层的价值不是"更好看"，而是把口径从人脑和 Excel 里搬到系统里，变成可审计、可版本管理的定义。这一步做完，补货讨论的起点才会从"你这个数怎么来的"变成"这个阈值要不要调"。
补货指标体系要跑通，至少需要五类数据源接入：
这五类数据分散在三到五个系统里。我在项目里会用跨境电商数据平台做统一接入层。以数跨境（https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）为例，它的定位就是把多平台订单、库存、采购、物流数据汇总到统一数据层，再在此基础上定义指标口径并输出分析看板。
我特别看重这类工具的一点是：它能让"口径定义"从口头约定变成可配置项。比如日均销量这个指标，在数跨境里可以配置时间窗、剔除条件、是否含广告订单，配置完成后的口径是固定的、可追溯的，而不是每个运营各自算一版。
我在项目里会先建一份指标字典，把这个卖家最常用的十几个指标逐个写清口径。下面是简化版的一部分，对比的是统一前后采购实际使用的口径差异。
| 指标 | 统一前各部门口径 | 统一定义后的口径 | 差异影响 |
|---|---|---|---|
| 日均销量 | 运营用 7 天含广告，ERP 用 30 天自然销量 | 按品类分档，剔除缺货日与退款，广告销量按衰减系数折算 | 需求基线差异从 55% 降到 8% 以内 |
| 可用库存 | 账面库存减去已下单未发货 | 账面库存减去锁定、不可售、待检，按仓分别计算 | 可用库存被高估约 22% 的问题被修正 |
| 在途库存 | 物流专员每周手动更新 | 物流商数据每日回传，区分在途、到港、清关中三种状态 | 数据滞后从 5 天降到 1 天 |
| 采购提前期 | 统一填 30 天 | 按供应商统计历史实际入库周期，取 P50 与 P80 | 实际平均前置期为 52 天，低估 22 天 |
| 安全库存 | 全 SKU 统一 15 天 | 按需求波动与前置期波动九宫格分档 | 爆款安全库存上调，长尾品下调 |
| 补货点 | 库存低于 20 天触发 | 日均销量 × 真实前置期 + 分档安全库存 | 触发时点更贴合实际到货周期 |
口径统一后，我没有直接让系统接管下单，而是做了两周"影子运行"：系统每天照常生成补货建议，采购照常手工判断，但两边结果都记录下来做对照。
两周后我拿到几组对比数据，这些是我在这个项目里的真实观察值：
注意，这两周里我没有改任何算法，只是统一了口径、修了数据源、把阈值分档。这组数据的意义在于证明：补货准确率的提升，绝大部分来自数据治理而不是模型升级。
在做这个项目的缺货归因分析时，我发现一个反直觉的现象：约 20% 的 SKU 贡献了超过 70% 的缺货损失天数。而这 20% 里，绝大多数是"高销量 + 长前置期"的组合。
这说明什么？说明补货资源不应该平均分配。把最精细的规则、最高的安全库存、最频繁的计算频率，全部压到这 20% 的 SKU 上，整体缺货率就能明显改善。对剩下 80% 的 SKU，用简化规则加低频计算就够了。
框架和案例讲完，接下来是决策建议。不同规模的卖家，补货指标体系的搭建重点完全不同，我按四个维度给建议。
这个阶段不建议上重型指标体系。你的核心矛盾是"别断货、别压太多钱"，而不是"指标要多精细"。
我建议只做六个指标：日均销量（单一固定口径）、可用库存、在途库存、可售天数、前置期（一个经验值）、安全库存（按销量分两档）。用 Excel 或轻量数据工具维护，每周更新一次就够。
这是最需要补货指标体系的区间。SKU 数量已经超过人脑管理上限，但还没到需要自建数据中台的规模。
建议动作：把四层指标的核心项全部定义清楚，做一份正式的指标字典；数据从 ERP 和平台自动接入，尽量不用人工填报；安全库存按九宫格分 3，4 档；补货建议先跑影子模式，两周后再接管。
这个阶段必须把补货做成分仓分平台的独立决策，不能合并计算。同时要引入资金占用约束，补货量不只是需求问题，还要受现金流和库存周转目标约束。
建议增加两个指标：补货资金占用（预测补货量 × 采购成本）和库存资金周转天数，把补货决策和财务目标挂钩。
新品没有历史销量，日均销量不可用。我的做法是用"同类目相似款销量 × 上架位置系数"做初始需求估计，同时把安全库存设高、补货批量设小，用小批量多批次试错。
用标准四层框架，重点是前置期和阈值的准确性。这类 SKU 的规则一旦调好，可以长期不动。
必须引入季节系数。不要直接用历史同期销量，而要用"历史同期销量 × 今年趋势系数"。同时补货窗口要提前，因为跨境前置期长，等你看到需求上升再补，货到已经是淡季。
直接冻结补货，转入清库存流程。这一类的判断标准要写死在系统里，比如"连续 3 个统计周期动销率低于阈值"，避免人为拖延。
大促是补货体系最容易崩的时候。我的建议是三条：
第三条最容易被忽略。跨境前置期普遍 45 天以上，大促前两周才想起补货，货根本到不了。
补货指标体系没有最优解，只有取舍。下面五组取舍是我在项目里反复遇到的，每一组都需要根据业务阶段明确选边，最怕的是两边都想要。
这是最根本的一组矛盾。安全库存越高，缺货率越低，但资金占用和滞销风险越高。两者不可能同时最优，只能选一个更符合当前阶段的平衡点。
我的判断依据是毛利率：高毛利品类（毛利率 50% 以上）可以承受更高安全库存，因为一次断货的利润损失远大于多备货的资金成本；低毛利品类（毛利率 20% 以下）必须严格控制库存，宁可接受略高的缺货率。
追求高预测精度，通常意味着更长的历史窗口、更复杂的模型、更慢的迭代速度。追求响应速度，则意味着更短的窗口、更简单的规则、更快的反应。
我的经验是：在跨境场景下，响应速度通常比预测精度更值钱。因为前置期已经很长了，再等模型算出精确预测，窗口期就过去了。用简单规则尽快下单，比等一个精确预测更实际。
全自动补货看起来很吸引人，但实际操作中风险很高。一次数据异常（比如某天订单同步失败导致销量归零）就可能触发错误的补货决策。
我的建议是分层自动化：低价值、高频次、稳定的 SKU 可以自动生成采购计划；高价值、低频次、波动大的 SKU 必须人工审批。中间的常规款走"自动生成 + 抽检"。
集中补货的好处是简单、易管理、议价能力强；分仓补货的好处是贴近需求、响应快、不易出现局部断货。
我的判断依据是仓库数量和服务渠道的重叠度：如果多个仓服务的是同一批渠道，集中补货更合适；如果每个仓服务不同渠道或不同区域，必须分仓补货。
跨境场景下，我通常建议至少做到"平台仓与自有海外仓分开算"，因为亚马逊 FBA 的补货受平台规则约束，和海外仓的自由度完全不同。
自建的优势是贴合业务、可深度定制；劣势是成本高、迭代慢、对团队能力要求高。采购现成系统的优势是上手快、成本可控；劣势是标准功能可能不完全匹配你的业务细节。
我的判断标准是：如果补货逻辑是你核心竞争力的组成部分，且业务复杂度超出标准系统覆盖范围，考虑自建或深度定制；否则，用现成系统 + 数据层做口径治理，性价比更高。
对绝大多数中小跨境卖家来说，第二条路径更现实。核心投入应该放在数据接入和口径统一上，而不是从零写一套补货算法。
每增加一个分层维度，指标体系就更精准一点，但维护成本也更高。我见过卖家把 SKU 分成 27 类阈值，结果三个月后没人能说清每一类的含义，规则彻底失效。
我的经验值是：阈值分层的数量控制在 4，8 档之间。低于 4 档区分度不够，高于 8 档维护成本会迅速超过收益。
写到这里，我想把整篇文章的判断浓缩成一句话：跨境采购补货的指标问题，本质上是口径问题、分层问题和动作问题，不是算法问题。这也是我在多个项目里反复验证的结论，换系统、上模型、加算法的收益，通常远小于把口径统一、把阈值分层、把动作绑定这三件事做实。
关于独特观点，我想再强调三个可能和主流说法不太一样的地方。
第一，补货建议的可采纳率比算法精度更值得关注。如果采购只采纳 40% 的建议，剩下 60% 需要人工改，那么这个系统的实际价值就很有限。可采纳率是口径、阈值、数据新鲜度的综合体现，它比任何单点算法指标都更能反映体系健康度。
第二，补货不该追求全自动。健康的目标是"规则触发 + 异常拦截 + 人工审批"，让系统处理绝大部分常规 SKU，人处理少量高价值与异常决策。全自动在数据异常时缺乏拦截能力，风险不对称。
第三，精细化资源应该集中在 20% 的 SKU 上。把最精细的规则、最高的安全库存、最频繁的计算，压到贡献大部分缺货损失的那一小部分 SKU 上，整体改善效果远好于对全部 SKU 平均用力。
如果你现在就要动手，我建议按这个顺序走：
这六步做完，你会发现补货体系的改善大部分来自第一到第三步，而不是来自换一个"更智能"的系统。数据层和口径治理是地基，算法只是地基之上的房子。地基不稳，房子盖得越高风险越大。
如果你正在做多平台多仓的补货管理，建议先去数跨境的官网看看它的数据接入和指标看板能力，评估一下能不能作为你的口径统一层：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys 。评估时重点看三件事，能不能接你所有平台的订单和库存、能不能自定义指标口径、能不能把在途和采购数据一起纳入计算。这三件事决定了它能不能真正替你解决补货口径问题。
我们去年旺季就是全类目共用一套安全库存天数，结果 A 类爆款断货断到 listing 掉排名，C 类长尾却压了一堆呆滞库存。后来复盘才发现，问题不在公式本身，而在于我根本没按需求波动和供应波动给 SKU 分层。
不要所有 SKU 共用一套阈值，先分层再定参数。实操上按销售额或销量做 ABC 分类：A 类占销售额约 70%，供应链波动大、断货代价高，安全天数可以给到 14 到 21 天；B 类 10 到 14 天；C 类走低库存策略，5 到 7 天甚至按单采购。
公式层面记住两条关系：再订货点 = 日均需求 × 采购提前期 + 安全库存；安全库存 = 安全系数 Z × 需求与提前期的波动合成值。工程上常简化为安全库存 = 日均需求 × 安全天数，但安全天数必须按「需求波动档 × 供应波动档」做矩阵，而不是拍一个数字。
判断依据是：先用 90 天历史数据算出每个 SKU 的需求标准差和实际到货提前期的标准差，波动越大档位越高。这一步做完，同一套 ERP 建议才会对不同 SKU 给出不同答案。
我以前直接用 ERP 默认的近 30 天销量除以 30，结果断货那两周销量为 0，系统把日均算得极低，建议补货量明显偏小，采购还以为是系统算错了。大促之后更夸张，活动那几天的虚高销量被平均进去，下一轮又建议我超补。
主口径建议用近 28 天日均，因为 28 天对齐四个完整周，能抵消工作日和周末的节奏差异，同时用近 7 天日均做修正项，例如需求基线 = 0.6 × 28 天日均 + 0.4 × 7 天日均。
分母一定要用「有货可售天数」，缺货日为 0 的那几天要剔除，否则日均会被系统性低估，公式是 日均 = 非缺货非促销日的销量合计 ÷ 这些天的天数。促销日的处理有两条路：一是直接剔除，二是用活动前 14 天自然销量的倍数还原成常态需求，我更推荐逐 SKU 还原，因为不同产品的大促放大倍数差异很大。
新品或数据不足 28 天的链接，用同系列或同类目均值做冷启动，同时把这几类 SKU 单独打标，避免污染整体口径。判断口径是否合理的标准很简单：拿它跑回测，看预测日均和实际销量的偏差是否稳定，而不是看它算得快不快。
我们同时用国内仓、两个海外仓和平台仓，早期我图省事把所有库存字段加在一起看，结果出现了一个尴尬情况：账面库存显示够卖 45 天，实际可售只够 12 天，剩下的全在头程和清关路上，运营当场就慌了。
不能直接相加，按「可达时间」分层才是正确做法。库存状态至少拆成六类：可售库存、已下单未发货的锁定库存、不良或待检的不可售库存、国内仓在库、在途库存（头程、清关、尾程分开）、平台仓在库与入库中。日常看板建议区分两个指标：可售天数 = 各仓可售库存之和 ÷ 日均需求；
而补货判断要用「库存投影」，把每批在途按 ETA 落到时间轴上，算未来第 N 天的预计可用量，即 预计库存 = 当前可售 + 该时点前到货量 − 该时点前预测需求。多仓合并时还要加上调拨时效：从国内仓到海外仓的调拨周期本身要占掉一段供应时间，如果把它当成即时可用库存，补货建议一定会偏乐观。
判断库存是否健康的依据不是单一数字，而是可售天数、在途占比、缺货率、滞销占比这几个指标一起看。
我们上系统后最挫败的一点就是，系统每天生成一堆采购计划，采购同事照旧用 Excel 自己算一遍，改单率一度超过六成，大家干脆说系统不准。后来我把改单原因一条条记下来才看清楚，问题不在算法，而在主数据、阈值和异常处理都没理顺。
别急着让系统直接下单，先做 2 到 4 周的影子补货：系统建议只记录不落单，每天和采购的人工决策做比对，统计手工改单率。然后把每一次改单归因到五类，需求突变、供应异常、MOQ 与装箱率限制、库容或平台仓入库限制、数据错误。归因之后分两路处理：能规则化的写回系统，比如最小起订量、整箱倍数、包装重量;
不能规则化的做成异常拦截，强制人工审批。异常规则至少要覆盖：建议量超过近 90 天日均销量的 3 倍、供应商未确认交期、关键字段缺失、建议量与在途到货时间冲突。每一笔人工干预都要留操作日志和原因码，否则下一轮复盘没有依据。
衡量是否跑通的不是「建议采纳率」这一个数字，而是手工改单率、缺货率、库存周转天数、滞销占比这四个指标同步往好的方向走，并且改单原因中「数据错误」这一类的占比持续下降。
读者评论
从ERP实施角度看，这篇文章最有用的是把补货问题从算法拉回到口径治理。很多项目指标字段都建了，但数据源、时间窗、责任人没写清，最后看板很漂亮，采购还是靠Excel。先做指标字典和影子运行，往往比换模型更实际。
作为采购，三套销量口径差55%太真实了。我们也是运营看7天含广告，财务看净销量，系统算自然销量，同一个SKU补货量能差一半。自然、广告、活动销量必须拆开，广告衰减贡献不能简单加总，否则广告一停就积压。
文章对库存状态拆解很有启发，但图里改单率是样本推演，不能直接当行业基准。更稳妥的做法是先拿自己三类SKU回测，再分阶段统一口径。平台仓库容约束也要显式建模，不然建议量算得再准也发不进去。