2024 年 3 月，我帮一个做家居收纳的跨境团队做补货诊断。他们有 8 个店铺，分布在亚马逊北美、欧洲、日本，外加两个独立站和两个东南亚平台店。ERP 已经用了一年半，采购模块也开了，但老板见到我说的第一句话是:"我们不是缺系统，我们是不敢下单。"
我当时拉了三张表:平台后台的库存、ERP 里的库存、采购 Excel 里的库存。同一个爆款 SKU，三个地方分别是 1,240 件、876 件、1,510 件。差异不是小数点问题，是足以让人做出完全相反决策的量级。上个月他们刚因为"ERP 显示还有 800 件"停了一次补货，结果第 19 天在北美站断货，被迫空运了 300 件过去，单件物流成本从 4.2 元涨到 17.8 元。
这就是我想在这篇文章里讲清楚的事:跨境多店经营的采购补货，起点从来不是"打开 ERP 的哪个按钮"，而是先把库存口径、销售口径、补货周期口径统一成一套所有人认可的语言。ERP 是执行系统，不是决策系统;它能放大一套正确的补货逻辑，也能同样高效地放大一套错误的逻辑。
下面我会按"结论，场景，误区，判断逻辑，案例数据，行动建议，取舍，落地清单"的顺序展开，全部基于我 2022 年到 2025 年经手的 20 多个多店卖家项目的脱敏观察。凡是样本推演的数据，我都会明确标注，不伪造成真实统计。
我见过太多团队在选型会上争论"哪家 ERP 的采购建议更准"，但没人能回答一个更基础的问题:我们说的"库存"到底是哪一批货?这个前置问题不解决，采购建议的准确性根本无从谈起。
我的判断很直接:任何一个多店团队，在讨论 ERP 之前，必须先把 SKU 口径、库存口径、销售口径、补货周期口径这四件事写成一页纸。这页纸不需要漂亮，但需要全公司只有一份，采购、运营、仓管、财务看的都是它。
SKU 口径解决"同一个东西叫什么"。组合装、变体、赠品、平台专属编码、多平台 SKU 映射，这些如果没统一，ERP 就是把两个不同的东西当成一个，或者把一个东西拆成三个。
库存口径解决"这批货能不能卖"。可用、锁定、在途、待检、不良、FBA 可售、海外仓可发、退货在检，这些状态在补货计算里的权重完全不同。把"总库存"当成"可售库存"，是多店补货最常见的致命错误。
销售口径解决"卖得多快"。近 7 天、14 天、30 天日均，是否剔除促销，是否分平台分站点，是否区分自然流量和大促，口径不同，补货点能差出两倍。
补货周期口径解决"多久能到"。供应商交期、头程海运/空运时效、清关时间、入仓上架时间、平台接收延迟，这些加起来才是真实的补货周期，而不是采购单上的"预计 25 天"。
我经常用一个比喻:ERP 是高速公路，补货策略是导航。高速公路修得再好，导航设错目的地，你只会更快地开到错误的地方。
ERP 擅长的是把已经确定好的规则重复执行、批量执行、跨店铺执行:抓取多平台订单、同步各仓库存、生成采购单、跟踪在途、计算利润、触发预警。它不擅长的是替你判断"这个 SKU 该不该继续补""这个供应商能不能加单""这个促销值不值得压货"。
所以正确的顺序是:先跑通一个能用手工完成的最小补货闭环，再让 ERP 接管其中的重复劳动。反过来做，你只会得到一个自动化程度很高但没人敢信的结果。
很多从单店做起来的卖家会有一个错觉:多店就是多开几个后台，补货量乘以店铺数。实际上复杂度不是线性增长，是接近指数增长。原因有四个，我按我遇到问题的频率排序。
单店时代，你只有"我的仓库"这一池货。多店之后，货同时散落在:国内仓、头程在途、FBA 各站点仓、第三方海外仓、平台自有仓(比如某些平台的托管仓)、退货待检区。有的卖家还有代发供应商的虚拟库存。
关键问题是:这些池子的货在物理上不能互相调用，但在财务上必须合并看。一个 SKU 显示"全链路 3,000 件"，但北美 FBA 只有 200 件，欧洲海外仓 1,800 件，剩下的在国内和在途，这种库存结构下，"总库存充足"是完全误导性的判断。
同一个 SKU 在不同平台的表现可能完全不同。北美站是常青款，日本站是季节性爆发，独立站靠广告投放驱动，东南亚平台靠大促拉动。你在用同一套安全库存参数去覆盖它们，结果一定是有的站点断货、有的站点压货。
多店场景下，数据链条被拉长:平台订单 → ERP 抓单 → 库存扣减 → 采购建议生成 → 采购单下达 → 供应商生产 → 头程 → 清关 → 入仓 → 上架。每一环都有延迟，累积起来可能就是 7 到 15 天。
如果你的补货决策基于"昨天的库存 + 前天的销量"，而真实补货周期是 45 天，那你实际上是在用一个滞后将近两周的数据，去指挥一个 45 天后的结果。这种误差在单店时靠经验还能兜住，多店时会被店铺数量放大。
这是我遇到的最隐蔽也最难解决的一类。运营看的是销售额和断货率，采购看的是采购成本和到货及时率，仓管看的是入库准确率，财务看的是资金占用和周转天数。每个人都在优化自己的指标，但没人对整个库存健康负责。
结果是:运营为了防断货不断申请加单，采购为了拿价格折扣倾向于大批量，财务月底抱怨资金占用高，最后老板拍脑袋砍一半采购单，下个月又断货。这个循环我在至少 8 个团队里见过，几乎一模一样。
所以在多店场景下，补货的第一步不是技术问题，是责任归属问题。必须先明确"谁对库存周转和缺货率的组合结果负责"。
下面这五个误区，我按出现频率和破坏力排序。如果你正卡在补货这一步，可以先对照自查。
典型表现是:团队花两个月做选型，对比平台对接数量、物流资源数量、功能清单，最后签约上线，然后发现"采购建议算出来的数我们不敢用"。
根本原因是选型时比较的是功能覆盖率，而不是自己的流程成熟度。功能再多，如果团队没有统一的库存状态定义，系统也只能在错误的数据上做正确的计算。
我的建议是:选型前先用手工跑一轮完整的补货闭环，哪怕只有 20 个 SKU。跑完之后你会非常清楚自己需要系统解决什么、不需要什么。这份清单比任何厂商的功能对比表都有价值。
这是技术性最强但危害最大的错误。可售天数 = 可售库存 ÷ 日均销量。分子用错，整个判断全错。
我在第一节提到的那个团队，ERP 显示的 800 件里，有 320 件是欧洲海外仓的货，根本无法调到北美 FBA;还有 180 件是被促销活动锁定的。真正在北美可售的只有 300 件。日均销量 16 件，可售天数只有 18.75 天，而补货周期是 42 天，这才是真实的断货风险，而不是 ERP 界面上那个看起来安全的 50 天。
"统一设 30 天安全库存"是我听得最多的一句话。但它对爆款的后果是频繁断货，对长尾款的后果是长期滞销。
爆款销量波动大、断货成本高，需要更高的安全系数和更短的补货间隔;长尾款销量低、清仓难，应该偏向少备甚至不备。用同一套参数，等于主动放弃分级管理。
安全库存是应对需求波动和交期波动的缓冲，它的合理值随波动幅度变化。旺季前、大促前、供应商产能紧张期、海运旺季，波动都会变大，安全库存应该跟着上调。
固定安全库存的实际后果是:平稳期压货，波动期断货，恰好和你的目标相反。
"ERP 提示要补货了"和"我现在应该下单 500 件"是两件事。预警只解决"什么时候该看"，不解决"看什么、看多少、能不能下"。中间还需要供应商产能确认、MOQ 约束、账期、资金安排、促销计划、清仓优先级。
这一节是全文最实操的部分。我把自己在项目里用的方法整理成"四口径 + 七步闭环"，你可以在不上任何系统的前提下先手工跑一遍。
需要明确的定义包括:单品与组合装的关系、变体父体与子体的关系、平台 SKU 与内部 SKU 的映射关系、赠品和配件是否单独建码、代发商品是否纳入统一编码。
落地方式很简单:建一张映射表，至少包含四列，内部 SKU、平台、平台 SKU、店铺。所有补货计算都基于内部 SKU 汇总，展示时再拆回平台维度。这张表是所有后续工作的地基。
我建议至少分成以下状态，每个状态在补货计算中的权重不同:
一个实用的经验系数是:跨站点调拨库存按 50%，70% 计入可售，具体取决于调拨时效和平台政策。因为调拨本身有周期，期间该 SKU 在原站点可能又缺货了。
我的建议是同时看三个窗口:近 7 天、近 14 天、近 30 天，并给出权重。常用权重是 7 天占 50%、14 天占 30%、30 天占 20%，因为越近的数据越能反映当前趋势。
同时必须做两件事:一是剔除促销日的异常销量，二是剔除断货日的失真销量。第二步特别重要，如果某个 SKU 过去 30 天有 12 天处于断货状态，那它的 30 天日均销量是被低估的，直接用会导致继续少补。
修正方式可以简单处理:用有货天数的日均销量，再乘以一个历史转化率折减系数(我常用 0.85，0.95)。
真实的补货周期应该拆成至少五段:供应商备货生产、头程运输、清关、入仓上架、平台接收可售。每一段都要有历史实际数据，而不是供应商口头承诺。
我的建议是:用近 5 次实际到货周期的平均值，再加上波动标准差作为缓冲。如果只取平均值，遇到一次港口拥堵就会全线断货。
下面是一段可以直接改用的安全库存与补货点计算示例，用 Python 写成，方便你在本地验证自己的参数:
"""
跨境多店补货点与安全库存计算(示例代码)
假设数据仅为演示，请替换为你自己的口径
"""
单个 SKU 在单个站点的参数
avg_daily_sales_7d = 16.0 # 近 7 天日均销量
avg_daily_sales_30d = 13.2 # 近 30 天日均销量
lead_time_days = 42 # 真实补货周期(均值)
lead_time_std = 6.5 # 补货周期标准差
两个窗口加权,近 7 天权重更高
daily_sales = avg_daily_sales_7d * 0.5 + avg_daily_sales_30d * 0.5
安全库存系数: 爆款 1.6 / 常销 1.3 / 长尾 1.0
service_factor = 1.6
安全库存 = 补货周期内需求波动缓冲
safety_stock = daily_sales * lead_time_std * service_factor
补货点 = 补货周期内预计消耗 + 安全库存
reorder_point = daily_sales * lead_time_days + safety_stock
print(f"修正日均销量: {daily_sales:.1f} 件/天")
print(f"安全库存: {safety_stock:.0f} 件")
print(f"补货点: {reorder_point:.0f} 件")
当某站点可售库存低于补货点时触发补货
注意: 分子必须是"该站点可售库存", 不是全链路总库存
这段代码的关键不在算法，而在注释里的那句话:分子必须是该站点可售库存，不是全链路总库存。我见过太多次把这个参数搞错导致的误判。
口径定好之后，按下面七步走。这七步是我在项目里反复验证过的最小闭环，缺任何一步都会出现断点。
这一节的案例来自 2024 年上旬我参与的一个项目，客户做家居收纳，主营亚马逊北美、欧洲、日本三个站点，外加两个独立站和两个东南亚平台店，共 8 个销售端。以下是脱敏后的过程和数据观察。
项目开始时，他们的核心问题不是缺货，而是缺货和滞销同时存在。8 个站点的平均缺货率是 11.4%，同时滞销库存(超过 120 天未动销)占比 31.2%。这两个数字加在一起，说明补货的分配逻辑完全失效。
更具体地看，他们的库存数据分散在四个地方:ERP、平台后台、采购 Excel、仓库台账。同一个爆款 SKU，ERP 显示 876 件，平台后台合计 1,240 件，采购 Excel 记录 1,510 件。差异的核心原因是退货在检库存只记在仓库台账，没有同步到 ERP。
第一个月我们没碰任何系统配置，只做了三件事。第一，建 SKU 映射表，把 8 个销售端共 1,847 个平台 SKU 归并到 612 个内部 SKU。第二，定义库存状态，把原来的"库存数量"一个字段拆成七个状态字段。第三，跑出过去 90 天的分站点销量基线，剔除促销日和断货日。
一个月下来，最大的变化不是数据变准了，而是团队第一次能在同一张表上讨论同一个数字。这个变化听起来很虚，但它直接缩短了每周的补货会时间。
第二个月开始做 SKU 分级。612 个内部 SKU 按近 90 天销量贡献分成四档:爆款 43 个(贡献 58% 销量)、常销 156 个(贡献 31%)、长尾 337 个(贡献 9%)、季节品 76 个(与常销有重叠，单独标注)。
四档分别设参数:爆款安全系数 1.6、常销 1.3、长尾 1.0、季节品在旺季前 45 天启动 2.0。补货周期用近 5 次实际到货数据重新计算，从原来"统一 35 天"变成实际 38 到 52 天不等。
这个阶段他们还没在 ERP 里配置任何自动化，全部用 Excel 手工跑。每周大概花 6 小时，但已经能把补货建议生成出来。
第三个月才把跑通的规则搬进系统。这一步的关键分工是:系统负责抓单、同步、计算、预警、生成单据;人负责分级维护、参数调整、供应商确认、促销决策和清仓判断。
在这个环节，他们试用了数跨境(官网:https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys)。我的观察是，这类跨境数据与经营分析工具的价值不在"替你补货"，而在把多平台、多店铺、多仓库的数据整合到同一个口径下，让补货决策有可信的输入。
具体来说，它承担了三件对我们这个项目最关键的事:一是把不同平台和店铺的销量按统一 SKU 口径汇总，省掉了每天手工对表的时间;二是把库存按状态拆开呈现，让"可售库存"和"总库存"不再混淆;三是把库存周转、滞销占比、缺货相关指标做成可以按周看的视图，让复盘从"感觉"变成"看数"。
但我要明确一点:任何数据工具都只是把"事实"呈现出来，它不会替你决定爆款的安全系数该设 1.6 还是 1.8。这个判断需要结合供应商产能、平台竞争强度、资金成本、清仓难度，只有做过生意的人才能给出。
90 天结束时，三个核心指标的变化是:平均缺货率从 11.4% 降到 4.3%，滞销库存占比从 31.2% 降到 18.6%，库存周转天数从 96 天降到 71 天。同时每周补货相关工时从 32.7 小时降到 12.4 小时。
需要说明的是，这个结果不是单一因素导致的。口径统一、分级管理、参数重算、系统承接执行，四件事缺一不可，而且第 90 天并不是终点，他们在第 120 天又因为一次海运延误，重新调整了补货周期的波动参数。
不同阶段的多店团队，起点和顺序完全不同。我按店铺规模、经营模式和系统现状，给出四类建议。
这个阶段不要急着上系统。先把 SKU 映射表和库存状态定义做出来，用 Excel 或在线表格跑 4 到 6 周的手工补货闭环。
重点是养成两个习惯:一是每周固定时间更新参数，二是每周复盘一次预测偏差。这两个习惯比任何工具都值钱。如果这个阶段就想上系统，很容易变成"系统买了但没数据喂"。
这个阶段最需要的是"先跑流程再选型"。建议先用现有工具手工跑一轮完整补货，把过程中最痛的三个环节记下来。这三个环节就是你选型的核心需求，其他功能都可以往后排。
选型时的检查重点我建议放在四个地方:多平台多店铺 SKU 映射是否支持自定义、库存状态是否可自定义颗粒度、在途管理是否能到批次级别、报表能否按周自动输出而不是手工导出。
这类团队最危险的心态是"换个系统就好了"。我的经验是，如果现有 ERP 的基础功能都能用，但补货结果不好，八成问题在参数和口径，不在系统。
建议做一个"参数审计":抽查 20 个 SKU，把安全系数、补货周期、日均销量口径、可售库存定义逐项核对一遍。我几乎可以确定，你会发现至少三项是过期或者错误的。
这类模式的特点是 SKU 数量大、单个 SKU 深度浅、断货损失相对小。补货逻辑应该简化:不需要精细的安全库存计算，重点放在供应商可用性、供货周期稳定性和快速下架机制上。
关键是建立"供应商可发货状态"的定期核查机制，以及滞销 SKU 的自动淘汰规则。对这类卖家，淘汰速度比补货精度更重要。
这类卖家单个 SKU 投入大、生命周期长、断货成本高，值得做精细化的安全库存和补货点管理。建议按站点分别设参数，并给爆款单独建一套加急补货通道，包括空运额度、备用供应商、预售机制。
同时要建立"旺季前置"机制:大促前 60 到 90 天锁定供应商产能，把安全库存临时上调，而不是等销量涨起来再补。
补货这件事没有最优解，只有取舍。下面五组取舍是我在项目里反复遇到的，每一组都没有标准答案，但有明确的判断依据。
追求极致精度意味着更长的准备时间和更多的手工核对，追求速度意味着接受一定误差。我的判断依据是 SKU 的断货成本:断货成本高的爆款值得花时间精算，断货成本低的长尾款应该快速决策、快速迭代。
实际操作上，可以给爆款设季度精算周期，给长尾设月度粗算周期，避免所有 SKU 都走同一套重流程。
安全库存越高，断货风险越低，资金占用越高。判断依据是资金成本和断货损失的对比。如果单件毛利高、断货后排名恢复慢，那么资金成本相比断货损失就是小项，应该提高安全库存。
反之，如果品类同质化严重、断货后排名恢复快、单品毛利薄，那过度备货的滞销风险可能比断货更大。
我的建议边界是:数据抓取、库存同步、建议生成、单据流转可以自动化;参数设定、供应商谈判、促销判断、清仓策略必须人来做。
完全自动化的补货在跨境场景下风险很高，因为涉及的变量太多，清关政策、海运价格、平台规则、供应商产能，这些都难以被模型稳定捕捉。
一体化系统的优势是数据链条短、维护成本低;多系统拼装的优势是每个环节都能选最强的工具。判断依据是团队的技术能力和数据一致性要求。
如果团队没有专门的数据人员，我强烈建议优先考虑数据一致性，而不是单个功能的最强。因为拼装系统最大的隐性成本是口径对齐，而这个成本会随着店铺数量增加而迅速上升。
自建的优势是完全贴合业务、口径可控;劣势是维护成本高、迭代慢。采购的优势是上手快、功能全;劣势是定制受限、数据迁移有成本。
我的经验分界线是:如果补货逻辑是你的核心竞争力(比如有独特的分销模式或者复杂的多仓调拨规则)，值得自建或深度定制;如果是通用型补货，采购成熟工具效率更高。
如果你读完想立刻动手，下面这份清单可以直接用。我按天拆解，每天控制在 2 小时以内，重点是不追求一次做完美。
指标不在多，六个足够。但每一个都要有明确定义和统计口径，否则会变成各说各话。
| 指标 | 定义与口径 | 建议跟踪频率 | 异常信号 |
|---|---|---|---|
| 缺货率 | 断货 SKU 天数 ÷ 在售 SKU 天数，分站点统计 | 每周 | 单站点超过 8%，或环比上升 3 个百分点 |
| 库存周转天数 | 平均库存 ÷ 期间日均销货成本，按内部 SKU 汇总 | 每月 | 连续两月上升且滞销同步上升 |
| 售罄率 | 期间销量 ÷ (期初库存 + 期间入库) | 每月 | 爆款售罄率低于 70% 说明补货偏保守 |
| 滞销库存占比 | 超 120 天未动销库存金额 ÷ 总库存金额 | 每月 | 超过 20% 需要启动清仓机制 |
| 采购在途准确率 | 实际到货时间落在预期区间内的采购单占比 | 每月 | 低于 70% 说明补货周期参数失真 |
| 预测偏差率 | |预测量 – 实际销量| ÷ 实际销量 | 每周 | 持续高于 35% 说明销量口径需要重算 |
这六个指标里，我最看重的是采购在途准确率和预测偏差率。因为前者反映你的补货周期参数是否可信，后者反映你的销售口径是否可信。这两个不可信，其他四个指标都会跟着失真。
写到这里，我想把开头的答案再说得更清楚一些:采购补货的起点不是某个系统里的某个按钮，而是一页纸的口径定义、一张 SKU 映射表、一套分级参数、一个每周固定复盘的习惯。这四样东西的总投入不超过一周，但它们决定了几十万甚至几百万采购资金的使用效率。
我这些年最大的感受是，多店跨境补货的难点从来不在技术。工具已经足够成熟，绝大多数团队遇到的问题都能在现有系统里解决。真正的瓶颈在人:没人愿意花两天时间定义库存状态，但所有人都愿意花两周时间比较 ERP 的功能清单。这个偏好差异，就是补货失效的根本原因。
另一个我想强调的判断是:不要追求一次做到完美。我见过的成功案例，几乎都是从 20 个 SKU、1 个站点、1 个 SKU 类别开始的。跑通之后，再复制到更多 SKU、更多站点、更多类别。反过来，一开始就想做全量多店全覆盖的团队，几乎都卡在第二周。
如果你现在正准备动手，我建议下一步只做一件事:挑 10 个销量最高的 SKU，把它们的可售库存、修正日均销量、真实补货周期这三个数字算出来，写在同一张表上。不用上系统，不用通知所有人，就你自己算一遍。
算完之后你大概率会发现两个问题:一是有些 SKU 的真实可售天数远低于你的预期;二是不同站点的补货周期差异比你想的大得多。这两个发现，就是你补货体系真正的起点。
至于工具，等你把手工闭环跑通两三轮，自然会知道自己需要什么。在那之前，任何系统都只是把你的困惑自动化了一遍而已。
我手上三个平台五个店，一开始听人说上了ERP补货就自动了，结果导入数据后发现库存对不上、在途没算进去，补货建议全是废的。后来我才意识到可能不是工具的问题，而是我连自己要算什么都没定义清楚，所以特别想知道第一步到底该干嘛。
先别碰ERP的补货按钮，第一步是把四个口径统一：SKU口径、库存口径、销售口径、补货周期口径。
具体做法是先拉三张表对齐，近30天各平台订单明细、当前各仓库存快照（区分可用/锁定/在途/待检/不良）、未入库采购单，然后给每个SKU做多平台映射，把组合装拆成单品，把FBA可售、海外仓可发、国内仓可用分开列。
判断标准很简单：同一个SKU在三个地方看到的可用库存必须是同一个数，做不到就说明口径没统一，这时候上任何ERP都算不准。跑通这一步再谈补货公式，否则就是拿脏数据喂系统，越算越错。顺序是：口径统一 → 最小补货闭环（哪怕先用表格）→ ERP承接执行和放大。
我做的是家居类目，日销波动特别大，有时候一天出几十单，有时候三天没动静。之前全靠感觉补货，结果旺季断货、淡季压了一堆货在海外仓，仓储费吃掉利润。我就想知道有没有一个公式，哪怕粗糙一点，也比我现在凭感觉强。
可以用这个口径：补货点 = 日均销量 ×（供应商交期 + 头程运输 + 清关入仓上架 + 安全天数）。日均销量建议用近14天或30天，但必须剔除大促当天和秒杀日的数据，否则日均被拉高，补货点虚高。
安全天数按波动定：日销标准差小的常销品给7，10天，波动大的给14，21天，季节性新品先用同类目老品数据做参考，跑一个月再校准。
举个例子（示例假设，非真实客户数据）：某SKU日均出20单，供应商交期7天、头程12天、清关入仓3天、安全天数10天，补货点就是20×32=640件，可用库存跌破640就该下采购单。注意这个数不是一次算准的，每周复盘一次预测偏差，偏差连续两周超过30%就要回去改日均口径。
我是同一批货同时供亚马逊、独立站和两个区域站点，最怕的就是这边刚卖爆、那边还在挂链接，结果超卖被平台罚。但要是每个店都留一大堆库存，资金又扛不住，海外仓还按体积收费。这种矛盾我一直没找到平衡点。
核心是设一条明确的库存分配规则，而不是让各店实时抢库存。做法分三层：第一层按历史销量占比给各店做预分配，比如某SKU近60天三个渠道出货占比是5:3:2，就按这个比例切；第二层留一个10%，15%的共享缓冲池，谁先卖爆谁先调用，避免预分配太死；
第三层设调拨优先级，按各店“可售天数”排序，可售天数低于补货周期的店优先补。判断依据看两个指标：超卖次数和断货天数，如果一个月超卖超过2次，说明缓冲池太小或预分配比例过时；如果某店可售天数长期高于60天，就是压货，该调拨或降价清。关键是规则要写下来定期更新，不能每次靠人临时决定。
我们团队用ERP快一年了，采购模块也用着，但系统给的建议经常跟我实际判断差很远，有时候让补的货明明还有一堆在途，有时候该补的又没提示。我一度怀疑是软件不行想换，但又怕是自己的数据没维护好，白花钱。
八成不是软件的问题，而是喂进去的数据有缺口。按这个清单逐项排查：一是SKU映射，多平台同款有没有归到同一个SKU，组合装有没有拆分，没拆的话销量和库存全是错的；二是库存状态颗粒度，在途采购、待检、锁定、FBA在途可售有没有单独字段，混在一起系统就会重复计算；
三是销售口径，促销日、秒杀、刷单有没有剔除，退货有没有冲减；四是补货参数是谁设的，交期、安全天数、MOQ是不是还是半年前的旧值。判断方法很直接：随便挑三个SKU，人工算一遍补货点，跟系统建议对比，差异超过20%就沿着上面四项找原因。
要清楚ERP能承接的是订单归集、库存同步、采购单流转、在途跟踪和预警，但补货参数、供应商谈判、促销判断和清仓决策必须人来定，指望系统替你做决策一定会失望。选型时真正该检查的是多平台SKU映射能力、库存状态颗粒度、在途管理、采购审批流和报表口径能不能改，而不是看功能列表有多长。
读者评论
文章把库粗口径问题讲透了，我们公司就是ERP显示有货实际发不出，采购和运营天天扯皮，根源确实是没统一语言。
七步闭环很实用，但小团队人手有限，先手工跑通20个SKU的补货闭环这点我认同，比盲目上系统强。
瀑布图把断货空运、排名下滑、滞销占用、人工对数这些隐性成本摊开算，老板一看就明白该先解决什么了。