2025 年 6 月，我陪一个做家居收纳类目的卖家复盘他们上半年的库存账。他们 4 月刚完成一轮 ERP 升级，采购模块、库存模块、财务模块全部打通，老板当时的期待是"以后再也不用为补货吵架了"。结果 6 月第一周，一款折叠收纳箱在亚马逊美国站断货 11 天，同期德国站同一款产品压了 2600 件在海外仓卖不动。采购负责人说系统给的建议一直是"暂不补货"，运营说后台明明显示快要断货了。两边看的是同一套 ERP，却得出了完全相反的结论。
这件事几乎浓缩了我这几年在跨境卖家那里反复见到的困境：ERP 升级解决的是"数据能不能流过来"的问题，但补货准不准，取决于"流过来的数据按什么口径解释、按什么参数计算"。这篇文章不推荐任何具体系统，只讲采购补货自动化真正卡住的地方，以及我在实际项目中验证过的参数体系、数据口径和分层落地路径。
很多卖家在讨论 ERP 升级时，默认把"补货不准"归因为系统不够智能，所以决策路径变成"换一个带 AI 预测的系统"。我跟踪过的样本里，这个判断方向大部分是错的。
我把近两年接触过的卖家补货问题做过一次归类统计，把每次"补货建议明显不合理"的原因追溯到最底层。结果如下，需要说明的是这属于样本推演数据，来自约 40 个卖家的访谈归类，不是行业普查，请按参考而非结论来读。
由此得出四条我认为可以直接作为决策前提的结论。
第一，补货自动化的瓶颈通常不在工具，而在参数缺失与口径不统一。先补齐决策逻辑，再谈系统升级，顺序颠倒的代价是几万到几十万的实施费和半年时间。
第二，正确的升级顺序是"口径统一 → 参数体系 → 规则自动化 → 预测驱动 → 异常协同"。跳过前两步直接上第四步，预测模型会输出看起来很专业但完全不可用的结果。
第三，自动化不等于无人化。人的角色会从"算数量"转移到"管参数、审异常"，这个角色转换如果没有在设计阶段考虑进去，上线三个月后必然回退到手工 Excel。
第四，验证指标必须先定义口径再测量。否则"缺货率下降了"这句话在运营、采购、财务三个部门那里会有三种解释。
抽象地讲"补货不准"没有意义，因为不同类型的失准，对应的病因和药方完全不同。我把它拆成三种我见得最多的形态。
这是最典型也最容易被误判为"系统互相打架"的场景。前面提到的家居卖家就是这一类：美国站提示断货风险，德国站提示库存过剩。
真正的原因往往是两个站点的库存池、补货逻辑和销量口径各不相同。美国站走 FBA，库存以亚马逊可售为准；德国站走第三方海外仓，ERP 里的"可用库存"包含了已锁定但未出库的部分；而两个站点的销量口径，一个扣除了取消订单，一个没有。三个口径叠加，系统算出来的缺口自然南辕北辙。
这类问题不是靠"打通两个平台"就能解决的，因为数据早就打通了，问题是打通之后没有做归一化。
这是我认为最隐蔽、杀伤力也最大的一种失准，很多卖家至今没意识到它的存在。
逻辑链条是这样的：某 SKU 因为一次头程延误断货 12 天。断货期间，平台显示的日销量从 40 件掉到 0。如果系统直接把"过去 30 天日均销量"作为需求输入，那么这个 SKU 的日均需求会被算成大约 24 件。系统据此给出的补货建议，比真实需求少了约 40%。补货量不足，到货后很快又断，下一轮再复习一次同样的失真。
三轮循环下来，这款产品在系统眼里"需求只有 15 件/天"，而在真实市场上它的需求是 40 件/天。运营看到的解释是"这款产品不行了"，于是主动降权、停投广告，产品真的就死了。
第三种形态出现在季节性品类上。系统显示库存周转天数 68 天，看起来健康，但其中 40% 是上一季的配色和尺码。这些库存按 SKU 维度看"能卖"，按可售性看已经死了。
问题出在系统只按 SKU 维度管理库存，没有按"款式生命周期阶段"打标签。补货建议只看总量缺口，不看结构缺口，于是出现"总量够、结构全错"的局面。
上面三种场景背后，是三类我在项目里反复纠正的认知误区。我给出每一类的自查现象，如果你中了两条以上，说明你的 ERP 升级顺序需要调整。
这一类卖家认为自动化是 ERP 里一个叫"自动补货"的功能键，打开就完事。他们的判断依据是"系统有没有这个功能"。
自查现象：如果你在选型时会问供应商"你们支持自动补货吗"，而不是"你们的补货建议里，缺货期的需求怎么修正"，那你大概率在这一类里。
实际发生的情况是：功能打开了，系统每天生成一批补货建议，采购看一眼觉得不对，改几个数，慢慢就变成"系统建议 + 人工全改"。三个月后，大家直接绕过系统用 Excel，功能开关还开着，但已经没人看。
这一类卖家的问题往往出在数据而非工具，但他们会持续更换工具。我见过一家卖家在两年内换了三次 ERP，补货准确率没有实质性变化。
自查现象：如果你在描述问题时说的是"这个系统太笨了"，而不是"我们的在途数据是从哪来的、多久更新一次"，那你在这一类。
判断依据很简单：如果换系统就能解决，那么第二次换系统就应该解决了。没解决，说明问题不在系统。
这一类最难自查，因为它藏在日常操作的默契里。典型表现是：运营说"可售"，指的是平台后台能卖的数量；采购说"库存"，指的是仓库里有的数量；财务说"存货"，指的是资产负债表上的金额。三个词都被叫做库存，但没有任何两个是同一个东西。
自查现象：让运营、采购、财务各自用一句话定义"缺货"，如果三句话不一样，你就在这一类里。这个测试我在十几个团队做过，一次通过的只有两家。
我习惯把补货从一个"动作"还原成一个"求解问题"。任何一个补货决策，本质上都是在三个约束条件之间找可行解，缺任何一层，解都不可靠。
需求侧要回答的核心不是"能卖多少"，而是"在哪个维度上、用哪套口径、预测多长时间"。
维度必须细到 SKU × 站点 × 履约仓。因为同一个 SKU 在美国站和德国站、在 FBA 仓和第三方海外仓之间，库存不可互调，需求也不可互串。很多系统的默认粒度是 SKU 层面，这在单站点时期没问题，在多仓多站点阶段就是错误源头。
口径上最关键的三个动作是：剔除取消订单、修正缺货期失真销量、剥离促销峰值。其中缺货期修正是最容易被漏掉、也是收益最大的一步。
修正方法不复杂：对断货天数超过 3 天的时段，用断货前后各 14 天的日均销量做插值，或者用"该 SKU 在同站点相似款在售期的表现"做参照，把这段时间的销量回填成"潜在需求"而非"实际成交"。这一步做完，很多 SKU 的需求判断会直接上修 30% 以上。
供给侧最大的认知错误是用平均提前期做规划。
假设某供应商的平均交期是 25 天，头程海运平均 30 天，总提前期平均 55 天。但如果交期的标准差是 8 天，头程的标准差是 10 天，那么"55 天"这个数字在真实世界里只有大约一半的概率能达成。补货点在 55 天上设置，意味着一半的补货会迟到。
专业做法是把提前期拆成"均值 + 方差"两个参数，均值用于计算提前期需求，方差用于计算安全库存。这个逻辑在教科书里是标准答案，但在实际卖家系统里，我见过超过七成只用了均值。
另一个被低估的变量是装箱率。系统算出的理论补货量是 137 件，装箱率是 24 件/箱，MOQ 是 200 件。实际下单量会被推到 216 件或 240 件。如果系统不做整箱向上取整，采购手工补，那么"系统建议"和"实际下单"永远对不上，久而久之采购就不再信任系统建议。
资金侧决定的是"你能承受多少次判断错误"。安全库存不是越高越好，它是缺货损失和库存资金占用之间的一个显式定价。
这里有一个必须理解的非线性关系：服务水平从 95% 提到 99%，对应的安全库存系数从 1.645 涨到 2.326，安全库存要增加约 41%。很多老板说"我要 99% 的满足率"，但没有意识到这句话的代价是安全库存直接涨四成。把这张账算清楚，往往比讨论要不要上系统更有价值。
把三层约束写成公式，再订货点的计算逻辑大致如下。这段不是代码，而是可以直接搬到 Excel 或 BI 工具里验证的计算顺序。
再订货点 ROP = 提前期需求 D_L + 安全库存 SS
其中：
D_L = 修正后日均需求 × 补货提前期天数
SS = Z(目标服务水平) × sqrt(提前期天数) × 日需求标准差
Z(95%) ≈ 1.645，Z(99%) ≈ 2.326
建议下单量 Q = ROP + 目标覆盖天数 × 修正后日均需求
− 可用库存 − 在途库存
最终下单量 = 向上取整到装箱率倍数
且不低于 MOQ
且不超过平台仓容与资金上限
参数的可怕之处在于：它们会随时间失效，但系统不会主动告诉你。头程时效从 35 天变 50 天、供应商换人导致交期方差扩大、平台仓容政策收紧，这些变化都不会触发任何告警，但会让原本正确的补货逻辑慢慢变错。
下面是我建议纳入日常复核的六个参数。每个参数我都会说明它解决什么问题、初始值怎么估、以及如何回测修正，而不是给一个"标准数值"，因为脱离 SKU 特性的标准值本身就是伪命题。
| 参数 | 解决什么问题 | 初始值怎么估 | 回测修正方式 | 常见踩坑 |
|---|---|---|---|---|
| 安全库存 / 服务水平 | 对冲提前期内的需求与交期波动 | 先定服务水平（建议新品类 95%、成熟爆款 97%-98%），再用 Z 值 × 提前期标准差反推数量 | 统计过去 6 个月的实际缺货次数，若远低于目标缺货率，说明安全库存偏高，可下调 | 直接给"30 天库存"这种天数指标，忽略了不同 SKU 的波动率差异 |
| 再订货点 | 触发补货动作的库存水位线 | 提前期需求 + 安全库存，按站点、按仓分别设置 | 统计触发后再下单的平均延迟天数，若延迟超过 2 天，说明触发点偏晚 | 全公司用同一个触发规则，不考虑站点履约差异 |
| 补货提前期（含头程） | 决定提前期需求的大小 | 取过去 10-15 批次的实际到仓日期，计算均值与标准差，不要用供应商承诺值 | 每季度重算一次均值与标准差，波动率上升超过 30% 时触发参数复核 | 只用均值不用方差，导致安全库存系统性低估 |
| MOQ 与采购倍数 | 让系统建议与采购实际下单量对齐 | 从供应商合同和装箱单直接读取，录入到系统主数据 | 统计"系统建议量"与"实际下单量"的偏差率，目标控制在 5% 以内 | MOQ 存在采购口头约定里，没有进系统，导致建议永远不能用 |
| 季节性 / 促销系数 | 防止大促峰值污染基线预测 | 按类目历史数据测算月度和周度系数，大促单独设置事件标记 | 对比预测销量与实际销量，若某月偏差持续超过 20%，重新校准系数 | 把黑五当周销量直接放进基线，导致次年 3 月还在按旺季水平补货 |
| 呆滞与清货阈值 | 区分"库存"和"能卖的库存" | 按类目设定：超过 X 天无销量、或剩余销售周期超过 Y 个月，标记为呆滞候选 | 每月复盘标记准确率，统计被标记 SKU 中实际清仓的比例 | 只有总量周转率指标，没有结构性的呆滞识别机制 |
关于参数复核的节奏，我建议的做法是：核心爆款每月复核，常规 SKU 每季度复核，长尾 SKU 每半年复核。复核不等于调整，但必须有记录，这样半年后回看时才能知道是哪一次参数变更导致了效果波动。
这一节是我认为整篇文章里最容易被执行、也最容易被忽略的部分。它的投入不大，主要是几场跨部门会议和一份口径文档，但收益直接体现在系统上线后的可用性上。
要解决的核心问题是：同一个物理商品，在亚马逊、独立站、ERP、财务系统里，可能有四个不同的编码。
（1）组合品与变体的拆解关系必须显式定义。一个"三件套收纳箱"卖出后，系统该扣减三个子 SKU 的库存，还是扣减一个组合 SKU 的库存？如果两边规则不统一，库存会被重复计算或漏算。
（2）多平台映射表要落成系统里的主数据，而不是存在运营的 Excel 里。我见过太多团队，映射关系只掌握在一两个老员工手上，人一离职，补货逻辑就断了一半。
库存至少要被拆成五个状态：在仓可售、在途、已锁定未出库、退货处理中、不可售（残次/待检）。
系统里的"可用库存"如果只等于"在仓总量"，就会把已锁定和待检的部分算进去，导致补货建议偏乐观。正确的可用库存应该是"在仓可售 + 在途预计可按时到仓"，且需要扣除安全库存。
销量口径要回答三个问题：算不算取消订单？算不算退货？断货期间怎么算？
前两个问题是部门立场的差异，纯粹靠协商解决。第三个问题才是技术性的，也是收益最大的。我在前面已经展开过缺口螺旋的机制，这里只补充一个执行细节：缺货期修正要在数据层做，不要放在人工判断里，否则永远无法规模化。
要统一的是交期定义（下单日到出厂日，还是下单日到到仓日）、账期（对资金测算有直接影响）、以及含税与不含税口径。
这里面最容易被忽略的是交期定义。如果采购理解的是"出厂日"，系统理解的是"到仓日"，两者差着整段头程，任何安全库存计算都会失真。
前面讲的都是方法论，这一节讲一个具体样本，说明"口径统一"这件事在实际工具层面怎么落地。
需要先声明：下面的案例来自我 2024 年底到 2025 年初跟进的一个卖家，细节做了脱敏与合并处理，不指向任何特定公司的真实经营数据。同时，任何工具的具体功能边界都应以官方说明为准，我这里只讲它在这个样本里承担的角色。
这个卖家年 GMV 约 2200 万元，SKU 约 850 个，覆盖亚马逊美国/德国/日本三个站点，外加一个独立站，履约方式包括 FBA、第三方海外仓和国内直发。团队 18 人，采购 2 人，运营 5 人。
他们当时的典型症状就是我前面说的第一种：同一个 SKU 在不同站点给出相反建议，采购每天要在三个后台之间来回核对。
他们没有直接去买一个补货算法，而是先花了两周时间做口径盘点。具体做了三件事：把所有平台的订单、库存、在途数据归到同一张主数据表；确定"有效需求"的计算规则（剔除取消、修正断货期、标记促销期）；把所有 SKU 的平台编码、组合关系、装箱率、MOQ 整理成可维护的映射表。
在工具选择上，他们选择用数跨境作为数据整合与经营分析的中间层，官网为 https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys 。在这个样本里，数跨境承担的角色不是替代 ERP，而是把多平台、多店铺、多仓的订单与库存数据按统一口径汇总，让补货参数的计算有一个可解释的数据底座。
我要强调的是这个定位差异：补货自动化的关键不是"哪个工具算得更准"，而是"算之前数据是不是同一个意思"。数跨境在他们这个场景里解决的正是后者，把分散在四个平台后台的库存与销量口径先归一，再让补货逻辑有统一的输入。
他们做完口径归一之后，在原来那套 ERP 里重新跑了一次补货建议，没有更换 ERP，也没有引入任何预测算法。三个月后的变化如下，这些是脱敏后的方向性数据，不是精确审计结果。
需要说明的是，这里面有一部分改善来自他们把缺货期销量修正规则固化了下来，而不是单纯换工具。这也是我一直强调的观点：先修口径，再谈工具；口径没修，换什么工具都只是换一种方式出错。
不是所有卖家都需要走到最高层。我见过的失败案例里，有相当一部分是把 L3 的方案硬套在 L0 的基础设施上。下面这条路径，建议你只往上走一层，走稳了再走下一层。
适用条件：SKU 在 200 以内，站点不超过 2 个，月订单量在 5000 单以下。这个阶段强行上系统，投入产出比很低。
风险：所有规则存在个人脑子里，人员流动即断档。
升级信号：当采购需要每周花超过 15 小时做补货表，或者出现过因漏看数据导致的断货，就该考虑 L1。
适用条件：SKU 200-800，多站点运营，已经有一套 ERP。这是我认为大多数卖家当前应该站的位置。
核心动作是：把安全库存和再订货点参数按 SKU × 站点录入系统，让系统自动生成补货建议，采购从"算数量"转为"审异常"。
典型风险：参数录进去就不管了。我建议在上线时就设定参数复核日历，把复核责任落到具体人头上。
升级信号：当规则自动化稳定运行 3 个月以上，但遇到季节性品类和大促备货时仍需要大量手工干预，就该考虑 L2。
适用条件：SKU 800 以上，或季节性/时尚类目占比超过 40%，且 L1 阶段的参数体系已经稳定。
这一步的关键前置条件是数据质量。如果缺货期失真、促销污染这两件事没解决，预测模型会把噪声学成规律，输出比人工更错的建议。
升级信号：当补货问题的形态从"算不出量"变成"发现了量但来不及响应"，说明你需要的是 L3。
适用条件：多平台、多海外仓、多团队协作，且补货决策涉及采购、运营、财务三方博弈。
这一层的核心不是算得更准，而是让异常被自动识别并分配到人：交期超期预警、库存结构失衡预警、呆滞风险预警、仓容超限预警。补货从一个人的工作变成一条有责任边界的流程。
验证环节最常见的错误是：只测改善幅度，不定义口径。结果是运营说改善了、财务说没感觉、采购说不确定。我的建议是把口径定义放在测量之前，并且用同口径做上线前后对比。
当这五个指标里有三个在三个月内稳定改善，且人工工时同步下降，才能说明自动化真正生效。如果只有缺货率改善而工时上升，那大概率是靠人力堆出来的，不可持续。
下面按四种典型处境给出具体动作，你可以直接对号入座。每一条都是从"这周能做什么"开始，而不是从"半年后要建成什么"开始。
不要急着买系统。先把三件事做完：把缺货期销量修正规则写进你的 Excel 公式；把每个 SKU 的安全库存和再订货点算清楚，哪怕先按季度更新；把组合品与变体的拆解关系写成文档。
这三件事做完，你的手工补货准确率会明显提升，而且这套规则未来可以直接迁移进系统，不会白做。
先做一次"参数体检"。把系统里所有 SKU 的安全库存和提前期参数导出，看有多少是空的、有多少超过一年没改过。我做过统计，这个比例在大多数团队里都超过 60%。
补完参数之后，把系统建议和采购实际下单量做一次比对，看偏差率是多少。如果偏差超过 20%，说明主要的偏差来源不在参数，而在数据口径，需要往第六节的方向排查。
优先解决口径问题，而不是换系统。建议做一次为期两周的口径盘点，把所有平台的订单、库存、在途数据归到同一张主数据表上，明确"有效需求"的计算规则。
在执行层面，可以先用数跨境这类数据整合工具把多平台数据按统一口径收敛，再回到 ERP 里跑补货逻辑。这个顺序比"先上补货算法再修数据"要稳妥得多。
先做一次前置条件检查：缺货期失真修正了吗？促销峰值剥离了吗？提前期方差算了吗？这三个问题的答案如果有一个是"没有"，就先不要上预测模型。
预测模型的价值在于捕捉规律，而规律的前提是数据本身干净。数据不干净时上模型，只会得到一个更难解释的错误。
任何方案都有代价。我不想只讲该做什么，也想讲清楚每个选择要放弃什么，这样你才可能在团队内部把账算明白。
定高的代价是资金占用和呆滞风险上升，收益是缺货损失下降。定低则相反。
我的判断标准是：看这个 SKU 的缺货损失和滞销损失哪个更大。如果缺货会导致排名掉、广告权重损失、顾客流失，缺货损失远大于滞销损失，安全库存就该往高定。如果产品是季节性强、迭代快、清货折价幅度大，滞销损失更重，就该往低定。
这里没有万能解，只有把两边的损失量化之后的选择。而大多数团队之所以争论不休，恰恰是因为从来没有把这两笔损失算成钱。
复核频率高的代价是管理成本，收益是参数及时性。频率低则相反。
我建议按 SKU 的销售额贡献做分层：贡献前 20% 的 SKU 每月复核，中间 50% 每季度复核，长尾每半年复核。全量月度复核在 800 个 SKU 以上就不现实了，最后会变成走过场。
自动执行的收益是响应速度，风险是参数出错时批量放大错误。人工确认的收益是安全，代价是响应延迟和人工成本。
我的建议是分阶段：上线前三个月全部人工确认，同时记录每次人工修改的原因；三个月后，把修改率低于 5% 的品类转为自动执行，修改率高的继续人工确认。用修改率作为自动化的准入标准，而不是用感觉。
自建的收益是掌控力强、可深度定制，代价是需要至少一名懂业务又懂数据的人，且要承担长期维护成本。引入外部数据层的收益是上手快，代价是对工具的依赖和数据迁移成本。
我的判断标准是团队规模。补货相关岗位少于 3 人时，自建数据层的隐性成本往往被严重低估，这时候把数据归一这件事交给成熟的数据工具更划算。当团队超过 10 人且有专职数据岗，自建的边际收益才开始显现。
回到开头那个家居卖家。他们最后没有换系统，做的第一件事是花两周把三个平台、三个仓的库存和销量口径写成了一份文档，明确"有效需求"怎么算、"可用库存"包含哪些状态。第二个月，系统给出的建议被采购直接采纳的比例从三成左右提升到了接近七成。
我想说的独特观点是：采购补货自动化的终极形态，不是一个不需要人干预的黑箱，而是一套每一笔建议都能追溯到参数和口径的计算体系。当采购质疑系统为什么建议补 744 件时，他能看到这个数字是怎么从 24 件/天的原始销量，经过缺货修正、促销剥离、提前期建模、安全库存叠加、整箱取整一步步得来的。能做到这一点，系统就会被信任；做不到，再智能的算法也会被绕过。
如果你现在就要动手，我建议的下一步只有一个：这周找运营、采购、财务各一个人，用十分钟让他们分别写下一句话，定义什么是"缺货"、什么是"可用库存"。三句话如果不一样，你就知道该从哪里开始了。
这件事不需要预算、不需要立项、不需要供应商配合，但它决定了你后面所有的 ERP 升级和自动化投入，最终能不能变成真实的库存效率。
我们做亚马逊加独立站，SKU 有六百多个，之前老板拍板统一设 30 天安全库存，结果旺季断货、淡季压货两头挨骂。我自己也说不清这个 30 天是怎么来的，想找个能算出来、还能回测修正的方法。
不要直接套天数，安全库存是算出来的，不是拍出来的。第一步先算需求波动：取该 SKU 近 6 到 12 个月的日销量，剔除缺货期和促销期这两类失真数据，算出平均日销和日销标准差。
第二步算提前期波动：把采购下单到海外仓可售的全链路拆开，分别统计工厂生产、头程运输、清关、到仓上架的实际耗时，取平均值和波动上限。第三步用「波动缓冲」而不是固定天数：需求波动大、提前期不稳的 SKU，安全库存要覆盖提前期内的需求波动再加一段交期延误缓冲；波动小的标品可以压到更低。
跨境场景还要单独加一层头程缓冲，因为海运时效波动通常大于平台仓补货。落地做法是先按这个逻辑给每个 SKU 算一个初始值，再拿过去 12 个月做回测，看在这个值下缺货率和库存周转天数分别是多少，然后逐月修正。判断标准是：如果某个 SKU 连续两个月都没触发安全库存预警，说明设高了；
如果一个月内触发三次以上还断货，说明设低了或者交期数据不准。
我们已经上了 ERP，安全库存、再订货点都配了，但系统给的补货建议跟运营的判断经常相反，同一款产品两个平台一个让补一个让清。我怀疑是数据问题，但不知道从哪儿下手排查。
优先查销量口径，这是补货失准最常见的原因，而且通常不是系统 bug，是输入就错了。重点看四件事：一是缺货期失真，商品断货那几天销量为零，系统会把这段当成低需求，于是越算越少、越少越断，必须把缺货日单独标记并从需求样本里剔除或做还原；
二是取消订单和退货有没有从销量里扣减，口径是按发货算还是按净成交算，全公司要统一；三是促销期数据污染，大促那几天的爆发式销量如果直接进预测模型，会把日常需求拉高，建议把促销单单独打标、单独建模；四是多平台订单有没有正确归集到同一个主 SKU，变体、组合装、赠品最容易错。
具体做法是拉最近 90 天的数据，人工标出缺货日、促销日、异常大单，重新算一版净销量，再和系统当前使用的销量做对比，差异超过一定比例就说明口径需要修。判断依据很简单：如果同一个 SKU 在两个平台给出完全相反的建议，先别改参数，先去核对这两个平台的销量和库存是不是来自同一个口径。
改动前建议把原始口径和修正口径都留档，方便上线后做前后对比。
我们同时做亚马逊、独立站和两个海外仓，同一款货在平台上显示有库存，海外仓实际可售又是另一个数，在途还有一批。每次补货会都吵，谁也说不清到底还剩多少。
先别急着上系统，先把库存状态定义清楚，统一成四个状态：可售、在途、锁定或预留、退货处理中。可售只算真正能被下单扣减的数量；在途必须继续细分，至少分成已下单未发货、头程在途、清关中、到仓未上架四段，因为每一段的可控性和时效风险完全不同；锁定包括平台预留、未发货订单占用；
退货处理中要单独列，不能直接加回可售，否则会高估库存。销量口径同样要统一到「主 SKU × 站点 × 仓库」这个粒度，用一张映射表把平台 SKU、变体、组合装对应到主 SKU，映射关系变更要有记录。落地做法是先做一张口径表，逐列写清楚：状态名称、数据来源字段、更新频率、责任人。
这张表比任何系统配置都重要，因为它决定了所有补货参数输入是否可信。判断标准是：任意时刻，随便挑一个 SKU，运营、供应链、财务三个人报出的可售数量应该一致，如果对不上，就先修口径，不要先调参数。
我们准备上线自动补货，但老板肯定会问省了多少钱、有没有变好。我怕拿不出有说服力的数据，也担心用错指标，把改善说成了恶化。
先定口径，再谈改善幅度，否则数字没有意义。建议固定五个指标：缺货率，用缺货 SKU 天数除以总 SKU 天数，不要用缺货订单数，因为爆款断货会掩盖长尾问题；库存周转天数，统一按平均库存成本除以日均出库成本算；
呆滞库存占比，先定义呆滞标准，比如超过 60 或 90 天无销量的库存金额占比，标准一旦定下就不要中途改；订单满足率，按整单满足还是按行满足要提前说明；补货人工工时，统计每周花在算补货、对库存、改采购单上的小时数。
上线前后各取三个月同口径数据做对比，并且要区分季节性，最好用去年同期做参照，或者按同比变化来看，不要只看上线后第一个月。判断依据是：如果缺货率下降但周转天数明显上升，说明你是用更多库存换来的满足率，属于参数偏保守，不是真正的效率提升；反过来周转变快但缺货率上升，说明安全库存被压过头了。
把五个指标做成一张月度看板，比单看任何一个数字都更能说明问题。
读者评论
文中缺货期销量失真的螺旋推演很真实。我做过两个类目，断货后系统日均销量自动下滑，采购就按低需求下单，结果反复断。后来手工回填断货期潜在需求，补货量明显合理了，这一步确实收益最大。
参数长期未复核这条我深有体会。头程从35天涨到50天，安全库存还按老数据算，补货点自然全错。建议把交期均值和方差都维护进系统，只用平均交期规划，一半订单会迟到。
跨部门口径不统一是最难自查的。运营说可售、采购说库存、财务说存货，三个词指的不是一回事。我们后来强制定义缺货口径才解决对账扯皮，否则换几次ERP都没用。
把自动化当开关的误区太常见了。功能打开，系统每天出建议，采购看一眼就改，三个月后大家又回Excel。自动化不等于无人化，人的角色应该转到管参数和审异常上。
季节性品类的结构缺口讲得准。系统按SKU总量看库存健康，可上一季配色尺码根本卖不动。补货只看总量不看款式生命周期，最后总量够、结构全错。