去年 11 月，我因为一次补货判断失误，把一批原本可以走海运的货改成了空运，单票多付了 4.2 万元人民币运费。更讽刺的是，那批货到仓之后，动销比我预估的慢了整整六周，等于我既付了最贵的运费，又承担了最长的滞销周期。这件事之后，我把过去 12 个月的补货记录、采购单、头程账单、仓储费和平台销量导出来，做了一次彻底的复盘。这篇内容就是那次复盘的完整结果，也是我在上线 ERP 采购补货模块之后，用三个月时间验证"成本控制效果"的真实记录。
先交代一下复盘范围，方便你判断参考价值。我经营的店铺集中在 Amazon 美国站和欧洲站，另有少量 TikTok Shop 美区业务，SKU 常年在 180 个左右，客单价区间 18，65 美元，属于典型的精品 + 精铺混合模式。使用的 ERP 包含采购管理、库存管理、销售订单和补货建议四个模块，数据处理层用的是数跨境做多平台数据整合与看板（官网：https://shukuajing.jiushuyun.com/?
utm_source=seo&utm;_plan=est&utm;_unit=gys），两者一个负责执行、一个负责核对。本文所有数据要么来自我自己的后台导出，要么来自同期对比的兄弟卖家样本，涉及估算的地方我会明确标注。
我不是 ERP 服务商，也不靠卖软件赚钱，所以这篇复盘里会有失败、有归因边界、有"上了系统也没用"的部分。如果你正在犹豫要不要用 ERP 管补货，或者已经上了但不知道效果怎么验证，下面的内容应该能帮你少走一段弯路。
在正式展开之前，我先把三个月复盘得出的结论摆出来。这些结论有的和主流说法一致，有的可能和你听过的宣传不太一样。我把它们分成"成立的"和"被夸大的"两类，避免你在读后面案例时被单点数据带偏。
跨境电商的成本结构看起来很复杂，但真正能被一个动作同时影响的，其实只有补货。补货决策一旦下发，采购价、头程运费、仓储费、缺货损失、滞销减值这五项会同时被推动，而且方向往往相反，补多了仓储费和滞销减值上升，补少了缺货损失和紧急物流费上升。这是补货值得单独拿出来复盘的根本原因。
我做了一张成本牵动图，把补货决策发出之后 30 天内会被影响的成本项列了出来。你会发现，采购单价只是其中一项，而且往往不是占比最大的那项。
第一，ERP 让补货依据可追溯，这一项的价值远大于自动计算。上线前我和采购争论某个 SKU 该补多少，双方都拿不出依据，最后靠"我觉得"。上线后至少能调出当时的日均销量、在途数量、安全库存设置和历史建议，争论变成了对参数本身的讨论。
第二，缺货率的改善比周转天数的改善更容易归因到 ERP。周转天数受产品结构、售价调整、季节性影响太大，而缺货次数是一个相对干净的事件计数，只要排除大促月份，归因可信度明显更高。
第三，补货效果的验证必须成对看指标。单看周转加快可能是牺牲动销换来的，单看缺货减少可能是靠堆库存换来的。我用的配对是"缺货率 + 库存周转天数"，以及"紧急空运次数 + 滞销库存金额"。
我在调研阶段看过不少说法，大意是"上线 ERP 后综合成本下降 20%，30%"。我自己的三个月数据不支持这么高的数字。我能确认的、可以归因到补货模块的成本下降，大约在 6%，9% 之间，主要集中在紧急空运次数减少和滞销库存金额下降这两块。剩下的改善来自采购谈判、物流商切换和产品结构调整，和 ERP 关系不大。
这个差距不是 ERP 没用，而是宣传口径往往把"所有成本改善"都算到系统头上。把这层水分挤掉之后，你才能真正判断这笔软件投入值不值。
最后一句话总结：没有基线的 ERP 上线，等于没有对照组的实验。你会在半年后听到同事说"感觉比以前好了"，但你拿不出任何一个可以复算的数字。这是我这次复盘最想强调的一点。
结论说完，我回到事情本身。很多人问我为什么是从补货开始做 ERP 复盘的，而不是从订单、财务或者广告。答案很直接：我确实因为补货失误付过一笔很痛的钱，那笔钱逼着我去找依据。
2023 年 10 月中旬，我的一款主力产品在美国站突然起量，日均销量从 22 单涨到 63 单，涨了接近三倍。运营在群里说"赶紧补货"，我当时人在工厂，凭印象判断这是短期波动，只补了 800 件。结果那波需求持续了整整七周，货在 11 月初断掉，我不得不空运 600 件救急。
空运单票 4.2 万元，加上断货 9 天损失的销售额约 12.4 万元，加上断货期间排名下滑导致的后续流量衰减，那一次失误的直接和间接成本接近 20 万元。而我如果当时补 1500 件走海运，额外成本不到 1 万元。
问题的核心不在于"我判断错了"，判断错误是常态。问题在于我没有任何一个可以即时调用的数据面板，能在三分钟内告诉我这个 SKU 的真实日均销量、在途数量、上架时间和历史波动区间。我当时用的是三张 Excel，而且它们的数据口径不一致。
我把我当时的补货依据还原了一下，是这样三张表：
这三张表放在一起，现实结果是：我每次补货都要花 40，60 分钟手动对齐数据，而且经常对齐失败。更麻烦的是，运营和采购对同一个 SKU 的判断经常相反，因为两个人看的是不同的表。
决定上线 ERP 之后，我做的第一件事不是选型，而是花了两周时间把上线前 90 天的数据梳理成四个基线指标。这四个指标后来成了我判断成本控制效果的唯一依据。
| 基线指标 | 定义口径 | 数据来源 | 记录频率 |
|---|---|---|---|
| 缺货率 | 当月发生断货的 SKU 数 ÷ 在售 SKU 总数 | 平台后台缺货记录 | 每月 |
| 库存周转天数 | 平均库存金额 ÷ 当月销售成本 × 30 | ERP 库存 + 财务数据 | 每月 |
| 紧急空运次数 | 当月因缺货发起的空运/快递补货票数 | 货代账单 | 每票 |
| 滞销库存金额 | 库龄超过 90 天且月动销低于 5 件的库存成本 | 平台库龄报告 | 每月 |
记录频率和口径必须在上线前定死，这一点非常关键。我见过不少卖家上线后再回头找基线，结果发现平台后台的历史库龄报告只保留 90 天，数据已经拿不到了。基线数据具有时效性，错过就真的错过了。
有人会问，ERP 模块那么多，为什么单挑采购补货来验证成本控制。我的理由是三条：一是补货的结果在 30，90 天内就能体现在账单上，验证周期短；二是补货的输入参数可量化，不像广告投放那样受算法波动影响；三是补货同时影响成本和收入两头，验证的含金量更高。
相比之下，财务模块的效果验证周期太长，订单模块的改善主要体现在人力上，都不适合作为第一轮验证对象。所以我的建议是：如果你要给 ERP 做一次成本效果的验证，从采购补货开始，是投入产出比最高的选择。
接下来我要讲的是误区。这部分内容我写得比较狠，因为其中大部分坑都是我亲身踩过的，而且踩的时候我还以为自己是对的。如果你正在做类似的补货改革，建议对照检查一遍。
我上线第一个月的心理预期是"系统会告诉我补多少"。现实是系统告诉我"按当前参数，建议补 1200 件"，但这个 1200 完全取决于我设置的参数。参数是我拍的，建议自然也是我拍的，只不过多了个计算过程。
ERP 的角色是"把补货依据留痕"，不是"替你做补货决策"。它保证同样的输入会得到同样的输出，保证三个月后你能回溯当时为什么这么判断，但它不会替你判断某个产品是不是进入衰退期，也不会知道工厂下个月要涨价。
我后来把补货建议分成三种状态来用：可直接执行、需人工复核、需人工否决。系统给出建议，人负责判断它落在哪一档。这个机制建立之后，我的补货决策质量才真正稳定下来。
这是最常见也最贵的误区。我早期评估补货方案时，唯一的比较维度就是采购单价，谁报价低用谁。直到有一次我算了一笔账才发现，单价便宜 3% 的供应商，交期比另一家多 12 天，导致我必须提前备货，多出来的资金占用和仓储成本远超那 3%。
补货的总拥有成本至少包含六项：采购货款、头程运费、关税与合规费用、仓储费、资金占用成本、滞销减值风险。其中资金占用成本最容易被忽略，按年化 6% 的资金成本算，多备 30 天货等于多付 0.5% 的货值。
我见过一个卖家的做法，他把周转天数从 92 天压到 51 天，数据非常漂亮，但同期缺货率从 8% 涨到 19%。他对外只讲周转改善，因为那个数字好看。
这两个指标本质上是一对矛盾体，必须成对观察。周转加快通常意味着备货更保守，缺货风险上升；缺货减少通常意味着备货更充足，周转变慢。单独看任何一个，都可能得出错误结论。
我自己的做法是画一张象限图：横轴是周转天数变化，纵轴是缺货率变化，每个 SKU 是一个点。所有落在"周转变快且缺货减少"象限的 SKU，才算真正改善。落在另外三个象限的，逐个分析原因。
我同时在 Amazon 美国站、欧洲站和 TikTok Shop 美区卖货，同一个 SKU 在三个地方的库存和销量是分开算还是合并算，这个问题我纠结了很久，而且一开始选错了。
我的第一批参数选择是"全部合并"，理由是合并之后销量更大，补货批量更经济。结果出问题了：美国站卖得好、欧洲站卖得差，合并之后系统按总销量给了一个偏高的补货建议，实际到货后欧洲站严重积压。而且两个站点的库存并不能互相调拨，合并口径在履约层面是无效的。
后来的修正方案是按履约能力分组：能共享库存的站点合并计算，不能共享的严格分开。这个规则听起来简单，但需要在 ERP 里逐个 SKU 配置，工作量不小，却是必须做的一步。
我上线 ERP 的第二个月正好是 Prime Day，缺货率从 11.7% 降到 6.2%，看起来改善巨大。但实际上大促期间平台流量集中，我的备货也提前做了，这个数据不能拿来归因到 ERP。
正确的做法是排除大促月份，用同期对比或分品类对比。我后来把 7 月、11 月、12 月三个月剔除，只对比 3，6 月和 8，10 月两组数据，得出改善幅度比原始数据低了约 4 个百分点，但那才是真实效果。
讲完误区，我要讲方法了。这部分是我三个月里反复调整出来的判断逻辑，也是我认为最有复用价值的部分。核心思路是：参数设置的目标不是"算得准"，而是"算得可解释"。一个可解释的粗略参数，比一个无法解释的精确参数有用得多。
ERP 补货模块通常围绕四个参数工作：安全库存、补货点、采购周期、在途时间。我用的是下面这套逻辑，和教科书版本基本一致，但在实际取值上做了跨境电商的调整。
用代码表达出来是这样，我把它做成了一个 Excel 脚本，每周跑一次：
# 安全库存计算（跨境电商补货简化模型）
avg_daily_sales = 30天销量 / 30 # 剔除单日异常值后
volatility = 1.2 # 稳定品类，季节品类取 1.8
lead_time_days = 22 # 工厂交期 + 质检 + 装柜
transit_days = 33 # 海运头程 + 入仓上架
replenish_cycle = lead_time_days + transit_days # 总补货周期 = 55 天
safety_stock = avg_daily_sales * volatility * (replenish_cycle ** 0.5)
reorder_point = avg_daily_sales * replenish_cycle + safety_stock
suggest_qty = reorder_point – current_available – in_transit
这套公式的价值不在于多精确，而在于每一个变量的来源都清楚。当补货建议看起来不合理时，我能立刻定位是哪个参数出了问题，而不是笼统地说"系统算错了"。
我踩过的一个坑是追求数据完整，结果数据延迟。早期我要求所有平台数据统一到 T+1 更新，看起来规范，但补货决策时拿到的是昨天的数据，遇到爆单场景完全来不及。
后来我调整了优先级：关键指标（可售库存、在途数量、近 7 天销量）做到准实时或者 T+0，非关键指标（库龄分布、退货率、广告花费）保持 T+1 或 T+7。这个分层策略让补货决策的响应速度提升了大概 40%，而数据治理的成本反而下降了。
这里我用数跨境做数据层，主要是因为它能把 Amazon、TikTok Shop 等平台的数据拉到统一看板里，库存和在途能在一张表里看到。ERP 负责执行补货单，数跨境负责核对两边数据是否对得上，这个双轨机制救过我几次。
前面提到我把补货建议分三档，这里展开说判断标准：
| 状态 | 判断条件 | 处理方式 | 占比（我的实际数据） |
|---|---|---|---|
| 可直接执行 | 近 30 天销量波动小于 30%，无近期待上架新品，无促销计划 | 采购直接下单 | 约 64% |
| 需人工复核 | 销量波动 30%，80%，或有在途大货，或处于季节切换期 | 运营 + 采购双签 | 约 28% |
| 需人工否决 | 产品处于生命周期末端，或平台政策变动，或供应商交期异常 | 由我本人决策 | 约 8% |
这个分档机制的关键在于把人的注意力集中在真正需要判断的 36% 上，而不是平均分配到所有 SKU。上线前我每个 SKU 都凭感觉判断，上线后我只深度介入约三分之一，效率和质量同时提升。
成本控制效果的验证，难点在归因。我用的方法是三种对比交叉验证：
三种方法都指向同一结论时，我才认为改善可以归因到 ERP。如果三种方法结论不一致，我倾向于认为改善来自外部变量，不写进复盘结论。这是我坚持的一条纪律。
方法讲完，进入最核心的部分，三个月实际发生了什么。为了让你看清过程而不是只看结论，我按月份拆开写，包括我做错的地方。所有数据来自我自己的后台和账单，涉及估算的部分会标注。
我原本计划三天完成数据接入，实际花了 19 天。原因有三个：一是平台数据字段口径不一致，Amazon 的"可售库存"和 TikTok Shop 的"可用库存"含义不同；二是历史在途数据缺失，2023 年部分货代的在途记录只有邮件，没有结构化数据；三是退货数据没有按 SKU 归集，导致日均销量偏高。
这 19 天里，我在数跨境上重建了统一的数据口径，把四个平台、七个店铺的库存、销量、在途、退货汇总到同一张看板。这一步没有产生任何"成本改善"，但它是后面所有改善的前提。
如果你准备做类似复盘，我的建议是给数据清洗留出至少三周，不要压缩。压缩的代价是在错误的基线上做对比，后面所有结论都不可信。
第二个月开始用 ERP 的补货建议，结果我和采购吵了两次。最典型的是一个家居收纳类 SKU，系统建议补 420 件，采购坚持补 800 件，理由是"这个产品去年这个时候爆过"。
当时的处理是折中补了 600 件。事后数据：这个 SKU 接下来 60 天实际卖出 380 件，库存剩余 220 件，形成轻度滞销。系统建议的 420 件更接近真实需求。
这次冲突让我意识到一件事：人工判断的问题不是能力不够，而是经验没有边界。采购记得的是"去年爆过"，但不记得去年爆的时候售价是多少、广告投入是多少、同期竞争品有多少。系统的建议虽然粗糙，但它的输入是可核查的。
从那个月开始，我定了一条规则：如果人工要否决系统建议，必须在 ERP 里填写理由，理由必须包含可验证的数据。这条规则执行之后，无理由的"我觉得"式判断下降了大约 70%。
第三个月我做了一次大规模参数调整，主要是三个动作：把波动系数按品类重新分了四档；把安全库存的计算周期从固定 30 天改成按补货周期动态调整；把三个不能共享库存的站点拆开单独计算。
调整之后的三个月完整数据对比如下。注意这里的"上线后"取的是调整参数之后的三个月均值，而不是刚上线时的数据。
| 指标 | 上线前（90 天月均） | 上线后（调参后 90 天月均） | 变化 | 主要干扰因素 |
|---|---|---|---|---|
| 缺货率 | 11.7% | 6.4% | -5.3 个百分点 | 8 月有一次供应商交期延误，剔除后约 5.8% |
| 库存周转天数 | 78 天 | 61 天 | -17 天 | 同期清掉了一批老库存，改善被高估 |
| 紧急空运票数 | 2.7 票/月 | 0.7 票/月 | -2 票/月 | 物流商切换，部分归因于议价而非系统 |
| 滞销库存金额 | 46 万元 | 32 万元 | -14 万元 | 同期主动砍掉了 11 个 SKU，约影响 5 万元 |
把干扰因素剔除之后，我保守估计可以归因到补货模块的改善是：缺货率下降约 4.5 个百分点，紧急空运减少约 1.4 票/月，滞销库存减少约 8 万元。按空运单票溢价 3.5 万元、滞销折价 30% 计算，月度成本改善约在 6%，9% 区间。
我把所有改善拆成"可归因 ERP"和"不可归因"两部分，做成堆叠图。这张图是我对这次复盘最诚实的表达。
上面讲的是我的情况，但每个卖家的规模、平台结构、品类特征都不同。这一节我按几种典型场景给出具体建议，你可以直接对号入座。所有建议都基于我自己的经验加上对身边卖家的观察，涉及数据的部分是样本推演，不是行业统计。
如果你的在售 SKU 不超过 50 个，我建议先不要上完整的 ERP 补货模块。这个规模下，用一套结构化的在线表格加上定时数据拉取，就能解决 80% 的问题。数跨境这类工具的看板功能对你来说其实已经够用：把各平台的库存、销量、在途拉到一张表里，设置好安全库存公式，每周更新一次。
这个阶段真正需要建立的是习惯，每周固定时间核对数据，每次补货记录依据。习惯建立起来之后，上系统才不会变成形式主义。
我就在这个区间。这个规模的特点是：SKU 足够多，靠人脑记不住；又还没多到需要复杂的分仓、分供应商逻辑。上线 ERP 补货模块的边际收益在这个区间是最高的。
具体建议是分三步走：第一步用两个月建立基线数据和统一口径；第二步用一个月小范围试跑补货建议，只覆盖稳定品类；第三步再全量铺开，并建立人工否决必须填理由的规则。
SKU 超过 300 个之后，问题的性质会变。此时最大的瓶颈不再是补货计算，而是数据的一致性和时效性。我见过 SKU 800 多个的卖家上 ERP 之后效果很差，原因就是数据源太多、口径太乱，系统算出来的建议没人敢用。
这个阶段我会建议先做数据中台的建设，把多个平台、多个仓库、多个货代的数据拉到统一层做清洗，再让 ERP 去消费这些数据。数跨境在这个环节能承担数据聚合和校验的角色，我自己在做多平台核对时也是用它来做交叉验证的。
多平台经营的卖家，在配置补货参数之前必须回答一个问题：哪些仓库之间可以调拨，哪些不能。这个规则决定了库存是合并计算还是分开计算，而口径错误会直接导致区域性积压。
我的做法是画一张库存流转图：横轴是平台，纵轴是仓库，交叉格子里标记是否可调拨、调拨周期多长、成本多少。这张图定下来之后，ERP 里的库存分组才有依据。这个动作看起来简单，但它决定了后面所有补货建议的正确性。
如果你有海外仓，在途时间的计算要拆成三段：国内到港口、海上运输、海外仓到平台仓。这三段的波动性完全不同，国内段波动小，海运段最容易延误，末端上架时间最不可控。
我的实际数据是：国内段标准差约 1.5 天，海运段标准差约 6 天，末端段标准差约 4 天。如果只按一个平均值算在途时间，遇到海运延误就会系统性缺货。建议在 ERP 里把三段分开配置，并对海运段设置额外的缓冲天数。
补货本质上是一连串取舍，没有哪个方案是全面最优的。这一节我列四组最常见的取舍，每组给出我的判断标准和实际选择。
这是补货最核心的取舍。缺货的代价是销售额损失加上排名下滑，滞销的代价是资金占用加上清货折价。两者都不可能归零，只能选一个你更能承受的偏差点。
我的判断标准是看产品的排名敏感度。排名敏感度高的产品，比如靠关键词排名吃饭的标品，缺货代价远大于滞销，宁可多备 20%。排名敏感度低的产品，比如靠老客户复购或者靠站外流量的，滞销代价更大，宁可少备 15%。
在我的 180 个 SKU 里，大约 40% 属于前者，35% 属于后者，剩下 25% 我用标准参数。这个分类每年 review 一次。
我第一年的做法是"能海运就海运"，那次空运之后我把策略改成了"该空运就空运，但要控制次数"。判断标准是：如果空运成本低于断货 7 天的预期损失，就果断空运。
具体算法是：空运溢价 ÷ 日均销售额 = 盈亏平衡天数。如果这个天数小于预计断货天数，空运是理性的。以我一个日均销售额 1.4 万元的 SKU 为例，空运溢价 3.5 万元，盈亏平衡点是 2.5 天，只要预计断货超过 3 天，空运就划算。
关键不是拒绝空运，而是把空运从"救火"变成"计算后的选择"。上线 ERP 之后，我在空运决策前的计算时间从半天缩短到 10 分钟，因为数据都在看板上。
提高补货精度需要投入人力维护参数、清洗数据、复核建议。投入多少人力，取决于你的毛利率能承受多少补货误差。
毛利率 45% 以上的产品，可以容忍 25% 的补货偏差；毛利率 20% 以下的产品，偏差超过 10% 就会吃掉大部分利润。所以我的做法是分层投入：高毛利产品用粗参数，低毛利产品用精参数，把有限的人力放在最需要精确的地方。
实时数据往往不准，准确数据往往延迟，这是数据处理的基本矛盾。我的取舍是按决策紧急度分层：影响当天补货决策的数据要实时，允许有 5% 误差；影响月度复盘的数据要准确，允许 T+3 延迟。
这个分层策略避免了两个极端：为了实时牺牲准确，或者为了准确错过决策窗口。执行下来，我的补货决策响应时间从平均 2 天缩短到 4 小时以内。
写到这里，我回到开头那次 4.2 万元的紧急空运。如果同样的场景今天再发生一次，我的处理方式会完全不同：我会先打开看板，看到这个 SKU 的真实日均销量、在途数量、安全库存水位，然后算一次空运的盈亏平衡天数，再决定是不是空运。整个过程十分钟，而不是像当时那样凭印象拍板。
但我想强调的是，这个改变不是 ERP 上线那一刻发生的。它发生在第一个月的数据清洗里，发生在第二个月和采购吵架的那个 SKU 上，发生在第三个月把参数重设一遍的那个下午。成本控制效果不是软件功能带来的，而是"持续验证"这个动作带来的。
三个月复盘下来，我最想分享的独特判断是这一条：ERP 在补货场景里的价值，不是让你补得更准，而是让你能说清楚"为什么不补那么多"，并且三个月后还能复现当时的判断依据。前者是算法能力，后者是组织能力，而真正决定成本控制的往往是后者。
如果你现在正准备做类似的事情，我的下一步建议是这三件事，按顺序做：
最后说一句实在话。补货是跨境电商里最不性感的工作，它没有广告投放那样的即时反馈，也没有新品开发那样的想象空间。但它对利润的影响是持续的、复利的。你在这个环节每减少一次错误决策，都会在未来 6，12 个月的财报里体现出来。这也是我愿意花三个月做这次复盘的原因。
我准备上线系统的前一个月，服务商一直说先上，效果上线后自然看得见。可我回头一想，如果连现在缺货率多少、周转多少天都说不清，那上线之后任何数字都能被解释成变好了。所以我想搞清楚，切换之前到底该老老实实记哪几个数、怎么记才算数。
至少记五个，而且要连续记满一个完整自然月，尽量避开大促月。一是缺货率，按缺货SKU天数除以在售SKU天数算，别用订单口径，否则热销款断货会被平均掉。二是库存周转天数，用平均库存成本除以日均出库成本，成本里含不含头程要事先写死。三是紧急物流次数，把空运、快递这类补货单数单独拉出来记。
四是滞销库存金额，给一个定义，比如90天无动销的库存成本。五是采购在途准确率，记实际到仓日和下单时承诺到仓日的偏差天数。比数字更重要的是口径：库存算不算在途、算不算头程、按数量还是按成本，全部写在表头里。
我自己的做法是把上线前三个月的数补录回去，销量能从平台后台导，但在途和到仓日期只能从货代对账单和邮件里翻，大概花了两个晚上。如果连一个月基线都不愿意记，后面所有省了多少钱的结论都不成立。
上个月有个SKU，系统按日均销量算出要补800件，但这个款已经连续两周销量往下走，平台仓还有入库限制，我直觉是别补。当时运营和采购为这事争了半天，一个说断货谁负责，一个说压货谁负责。我想知道这种冲突有没有一套能反复用的判断流程，而不是每次靠吵。
先分清是参数错了还是判断不同，三步走。第一步查分母，把日均销量换成近7天和近28天两个口径对比，如果28天日均明显高于7天，说明销量在掉，系统用的是滞后窗口，这时候该改的是销量统计窗口，不是硬扛。
第二步看约束条件有没有落进参数里，在途、平台仓入库上限、供应商MOQ、账期、头程时效，很多所谓系统算多了，实际是没扣在途或没设入库上限。第三步只对争议SKU做人工干预，并且留痕：谁改的、改成多少、两周后回看结果。
经验上，全部人工覆盖等于系统白上，全部照单执行在旺季前一定压货，比较稳的是把人工干预控制在补货单量的两成以内，每月复盘这些干预是帮了忙还是帮了倒。记住系统给的是建议量，不是指令。
我们上线三个月，缺货率从9%左右降到5%出头，周转天数从70多天压到60天上下，老板问这套系统是不是值这个钱。可同期我们换了头程货代，采购也重新谈了价，我自己心里没底，不敢把话说满。所以想知道这种情况到底该怎么归因，才能说得清楚又不心虚。
用一个拆分法：分品类、分平台、分月份看，再看外部变量落在哪一层。如果改善集中在参数设置比较准的那几个品类，而同期换货代的几个品类改善幅度反而更小，系统的作用就比较可信。具体做三件事。第一，上线前三个月和上线后三个月做同期对比，尽量排除大促月，实在排不掉就把大促月单列。
第二，把外部变量逐条标注并量化，头程单价降了多少、采购单价降了多少、有没有调价或改产品结构。第三，算一个反事实值，把物流和采购单价按原价代回去，看周转和缺货还剩多少改善。我的结论是，系统带来的往往不是直接省钱，而是减少错误决策的次数，比如紧急空运从一季度十几次降到五六次，这一项归因比较干净；
而周转天数的改善，通常一半来自系统把参数立住了，一半来自外部条件变好。把这两半分开写，复盘才立得住。
身边有卖家SKU不到30个就上了系统，结果每天光维护参数就累得够呛，最后还是一张表管全部；也有做两三百个SKU、多平台多店铺的，还在用手工表硬撑，经常同一个款重复补货。我不想花冤枉钱，也不想错过该上的时间点，所以想知道有没有比较清楚的判断线。
我给三条判断线，满足两条以上再认真考虑。第一，SKU和渠道，常备在售SKU超过100个，或者同一个款在三个以上平台或站点同时卖，人工在表里合并库存和销量已经开始出错。第二，跨境环节复杂度，有海外仓或平台仓，存在在途、头程时效、入库限制这些光靠Excel很难同时盯住的约束。
第三，人和流程，采购和运营的分工已经明确，并且愿意每月花半天做参数复盘，如果连谁负责补货都没定清楚，上了系统只是把混乱搬进系统。反过来说，SKU几十个、单一平台、补货靠老板一个人拍板还跑得动的时候，先把表格里的字段和口径理清楚，比早上系统划算。
另外不管什么时候上，上线前一个月就得开始记缺货率、周转天数、紧急物流次数、滞销金额这几项基线，否则上了也没法验证效果。
读者评论
文里强调上线前先定死基线指标，这一点比选哪家 ERP 更关键。不过三个月验证期偏短，最好覆盖一个完整旺季和淡季，否则缺货率和周转改善可能混入季节性因素。6%，9%的可归因成本下降反而比20%，30%的宣传更可信。
采购单价低但交期长，最后可能被资金占用和仓储费吃掉，这个账很多卖家没算。总拥有成本至少要包含头程、关税、仓储、资金占用和滞销风险，只看报价容易选错供应商。
多平台库存合并计算导致欧洲站积压，这个坑很典型。美国站和欧洲站动销差异大时，安全库存和补货建议应该分站点独立设置，否则总销量会掩盖单站点滞销风险。
ERP补货模块不是自动决策引擎，建议值仍然取决于人工参数。把建议分成可直接执行、需人工复核、需人工否决三档比较实用，系统真正价值在留痕和可追溯，而不是替代判断。