去年 11 月，一个做家居收纳的卖家在旺季前两周找到我，说他把一款月销 8000 单的爆款补错了：系统按"近 30 天日均销量 × 45 天覆盖"算出要补 12000 件，他照单下了，结果货还在海上，亚马逊美国站的 listing 已经因为断货掉出类目前 50，等他 45 天后收货，销量已经回落到日均 900 单，那批货在 FBA 里躺了四个月。同一个团队，另一款滞销品因为安全库存设成"拍脑袋的 60 天"，压了 38 万现金在海外仓。
断货和压货在同一场补货会议里同时发生，这不是运营能力问题，这是采购补货这件事从来没有被"标准化"过。
我做跨境电商供应链和 ERP 方案设计这些年，见过太多团队把希望押在"一键智能补货"按钮上。但真正跑得稳的团队，几乎都不是靠算法最先进，而是靠字段统一、参数可解释、流程可追溯、异常能闭环。这篇内容我想把"采购补货场景的标准化管理怎么做"这件事拆到能直接对照执行的粒度，包括我在真实项目里用过的字段表、参数逻辑、伪代码、指标看板，以及我如何用数跨境（官网：https://shukuajing.jiushuyun.com/?
utm_source=seo&utm;_plan=est&utm;_unit=gys）搭一层补货数据底座。
第一句：采购补货标准化不是买一个 ERP，而是把"我们凭什么这么补"这件事，写成系统能读、人能复盘、新人能接手的一套规则。ERP 只是这套规则的执行容器，容器再好，里面装的是"运营小王觉得该补了"，结果依然是撞运气。
第二句：补货算不准，90% 的问题出在补货公式之前，而不是公式里。同一款产品在亚马逊、TikTok Shop、Temu、独立站四个渠道卖，SKU 编码各不相同，库存分散在本地仓、FBA、第三方海外仓、在途多个状态里，这种数据口径下，任何算法都算不准。先统一口径，再谈算法。
第三句：自动补货的价值不在"自动下单"，而在"自动暴露异常"。一个真正好用的补货方案，是每天早上告诉你"这 37 个 SKU 有断货风险、这 22 个 SKU 有滞销风险、这 9 张采购单供应商已经延期超过 5 天"，而不是替你按下采购按钮。
我复盘过一个家居卖家的三个月数据（示意样本，非行业统计）：在补货失准的案例里，因为"主数据不一致"导致的比例最高，因为"算法不够智能"导致的比例反而最低。原因很朴素，算法只能在它拿到的数据上做推断，如果同一个产品在四个平台是四个 SKU、五个库存状态、三种交期口径，算法连"我现在到底有多少可用库存"都回答不了，谈何补货。
标准化的意义还在于可交接。我见过不少团队，补货逻辑完整地装在采购主管一个人的脑子里，他休假两周，整个团队就退回"凭感觉补货"。标准化之后，规则写在系统里、异常写在日报里、参数写在文档里，人走了，能力留下。
我把采购补货标准化拆成六层，从下往上依次是：主数据标准、参数标准、流程标准、系统配置标准、指标标准、协同标准。上一层依赖下一层，跳层做必然返工。
一个 8 人的跨境团队，每周一上午开补货会。运营打开四个平台后台，分别导出销量 Excel，采购打开自己的库存表，两人对着屏幕对数字，对不上就现场打电话问仓库。两个小时后，采购在表里填上"建议补 3000 件"，理由是"上周卖了 2000 多，感觉这周会涨"。这个"感觉"没有任何书面依据，也无法在下周复盘，因为没人记录当时的假设。
另一个团队的问题更隐蔽。由于海外仓到货周期长达 40 天，采购看到"FBA 可售只剩 5 天"才发起补货，补货单走完审批、供应商排产、头程、清关、上架，实际已经断货 25 天。断货期间销量下滑，系统根据下滑后的销量重新计算，得出"不需要补那么多"的结论，于是下一轮补得更少，形成负向循环。
前面提到的家居卖家，爆款断货 14 天。直接的销量损失可以算，但更贵的是排名权重：断货期间 listing 从类目前 50 掉到 300 名开外，重新爬回去花了将近 6 周广告费。这部分成本在补货决策时几乎没人计入，也是"安全库存到底该高一点还是低一点"这个争论迟迟没有答案的原因，因为缺货成本没有被量化。
把上面这些场景抽象一下，补货失控基本是四条链在传导。
这四条链里，只有第二条和算法沾边，其余三条全是管理标准化问题。这也解释了为什么很多团队换了 ERP 之后，补货准确率并没有明显改善，换的是容器，链条没修。
很多从国内电商转过来的运营会觉得补货是同一件事，其实差异很大，这些差异直接决定了标准怎么定。
| 维度 | 国内电商补货 | 跨境电商补货 | 对标准化的影响 |
|---|---|---|---|
| 提前期 | 3-7 天 | 25-60 天（含头程、清关、上架） | 安全库存必须按完整提前期算，不能只算供应商交期 |
| 库存位置 | 1-2 个仓 | 本地仓 + FBA + 第三方海外仓 + 在途 | 需要定义"可用库存"的计算口径和跨仓调拨规则 |
| 渠道数据 | 平台后台基本统一 | 亚马逊/TikTok/ Temu/ 独立站口径各异 | 必须先做 SKU 映射和销量口径统一 |
| 资金占用 | 相对轻 | 头程 + 关税 + 海外仓储费叠加 | 滞销成本远高于国内，必须纳入补货参数 |
| 补货批次 | 高频小批 | 低频大批，改单成本高 | 补货决策的容错空间小，参数需要更保守 |
这张表我建议所有跨境卖家在动手做补货标准化之前先看一遍，因为它决定了你的参数默认值应该是"国内思维"还是"跨境思维"。用国内电商的 7 天提前期去套跨境，安全库存必然不够。
"智能补货"这个词被用滥了。我见过不少产品页把它当成核心卖点，但真正落地时你会发现，所谓智能只是"用历史销量乘以一个固定天数再减掉可用库存"。这不是方案，这是公式。
真正的方案必须回答：用哪一段历史销量（7 天还是 28 天，含不含促销周）、用什么系数（季节性、趋势、平台权重）、在途算不算、MOQ 和包装倍数怎么处理、超过多少金额要审批。这些问题没有标准答案，但必须有明确答案。一个按钮解决不了七个问题。
这是最贵的误区。团队花两三个月选型、实施、培训，上完之后发现：审批关系没定、异常处理没定、谁负责回写交期没定。系统里的流程是空的，大家继续在微信群里补货，ERP 变成"存档工具"。
我的判断是：流程标准化的草稿纸版本，应该在选型之前就存在。哪怕只是一张画在白板上的流程图，只要写清楚"需求谁生成、谁确认、谁审批、异常找谁"，上系统时就是在做翻译，而不是在做发明。
"安全库存设 30 天吧，大家都这么设。"这句话我在至少六个团队听过。问题是：一个交期 25 天、销量波动系数 0.6 的品类，和交期 50 天、波动系数 0.2 的品类，用同一个安全库存天数，必然一个缺货一个压货。
参数必须能从数据里反推。比如你可以先用历史数据回测：过去 12 个月，在覆盖天数设为 N 天的情况下，缺货率和滞销率分别是多少，然后选一个综合成本最低的点。这个动作一次大概需要 2-3 天，但能避免后面半年的反复调整。
四个平台的销量加起来算总需求，听起来合理，但有三个陷阱。
我的建议是：以"净出库量"作为补货基数，即支付成功、扣除取消和退货后的数量，且以出库时间为准而不是下单时间。这一条改完，很多团队的需求基数立刻准了 5-10 个百分点。
"在途到底算不算可用库存？"这个问题我在会议上被问过不下十次，答案永远是"看情况"，但标准化的要求是，你必须把"情况"定义清楚。
我通常把在途拆成四个状态：已下单未发货、已发货未到仓、已到仓未上架、已上架可售。只有前三者中"预计在安全库存消耗完之前能到仓"的部分，才可以计入补货计算的可用量。否则你就是在用一批还没影的货，去掩盖眼下的缺口。
只考核缺货率的团队，一定会走向过度补货。因为把安全库存调到无限高，缺货率必然下降，但资金占用和滞销会同步飙升。我在一个样本里测算过：缺货率从 8% 降到 3%，代价是滞销 SKU 占比从 15% 涨到 27%，多占用的现金约等于该团队 4 个月的毛利。
所以指标必须是组合的：缺货率 + 库存周转天数 + 滞销 SKU 占比 + 采购准时到货率，四项一起看，并且权重提前定好。
供应商延期到货 20 天，采购在群里催了一遍，货到了，事情结束，但系统里的交期字段还是原来的 30 天。下一轮补货计算用的还是这个错的数据。
异常闭环的最低要求是三步：记录异常 → 更新字段 → 复盘影响。第二步最容易被跳过，也最致命。
下面这六层是我在不同规模团队反复用过的框架。它不是理论模型，而是在项目里被追问"那具体怎么定"时，我给出的答案顺序。你可以把它当成一个自评表：从第一层往下打分，哪一层塌了，就先修哪一层。
主数据是补货计算的分母。我要求所有做补货标准化的团队，先把下面这张字段表填完整，缺一项就说明这层没做完。
| 字段组 | 关键字段 | 责任归属 | 常见坑 |
|---|---|---|---|
| 产品标识 | 主SKU编码、平台SKU、店铺ID、平台、ASIN/商品ID | 运营+IT | 平台SKU未映射，同一产品多编码 |
| 库存状态 | 仓库、可用库存、锁定库存、在途数量、在途状态 | 仓储+采购 | 在途不分状态，全部计入可用 |
| 供应商 | 供应商编码、采购价、MOQ、包装倍数、承诺交期、账期 | 采购 | 交期字段长期不更新 |
| 销售速度 | 7/14/28/90天净出库量、退货率、取消率 | 数据/运营 | 用下单量代替净出库量 |
| 补货约束 | 安全库存、覆盖天数、目标库存、补货周期 | 供应链负责人 | 全品类用同一套参数 |
主数据这层最容易出问题的是"平台 SKU 到主 SKU"的映射。我通常会写一条校验查询，让它每天跑一次，把没映射上的活跃 SKU 直接推给运营处理。
-- 主数据一致性校验：找出活跃的平台SKU未映射到主SKU的记录 SELECT p.platform, p.shop_id, p.platform_sku, p.sku_name, p.last_sale_date FROM ods_platform_sku p LEFT JOIN dim_master_sku m ON p.platform = m.platform AND p.platform_sku = m.platform_sku WHERE m.master_sku_id IS NULL AND p.status = 'active' AND p.last_sale_date >= DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY) ORDER BY p.last_sale_date DESC;
这条查询的意义在于把"数据问题"变成"待办任务"。不然主数据变成"发现了也没人管"的僵尸问题。
我的原则是：谁产生数据，谁负责质量；谁使用数据，谁负责校验。平台 SKU 由运营上新时创建，所以映射关系的第一责任人是运营；采购用这个映射去算补货，所以采购有责任在发现对不上时提报。中间不需要专门的"数据管理员"，但需要一条每天跑的校验规则。
很多团队卡在这一层，想一次做完 100% 映射，结果拖了三个月没上线。我的建议是：先做到"销量占比前 80% 的 SKU 100% 映射"，剩下长尾边跑边补。用帕累托的方式推进，第一周就能看到效果。
参数层是大家最关心、也最容易误解的一层。我先把四个核心参数的定义说清楚，因为很多争论其实是定义之争。
| 参数 | 作用 | 常用计算口径 | 适用条件 |
|---|---|---|---|
| 安全库存 | 吸收交期与需求的波动 | 日均需求 × 提前期 × 波动系数 | 波动系数必须按品类回测，不能统一取值 |
| 再订货点 | 触发补货的库存水位 | 提前期内需求 + 安全库存 | 提前期要含头程、清关、上架 |
| 目标库存 | 补货后希望达到的水位 | 日均需求 × 覆盖天数 + 安全库存 | 覆盖天数受资金和仓储成本约束 |
| 补货量 | 实际下单数量 | 目标库存 – (可用 + 可计入在途) | 需按 MOQ 和包装倍数向上取整 |
把这四个参数写成伪代码，大概是这样。我特意把系数暴露出来，因为系数才是真正需要按品类校准的部分，公式本身没什么秘密。
def suggest_qty(available, in_transit_usable, avg_daily_sales,
lead_time_days, coverage_days, moq, pack_size,
volatility_factor):
安全库存：吸收提前期内的需求波动
safety = avg_daily_sales * lead_time_days * volatility_factor
目标库存：覆盖天数 + 安全库存
target = avg_daily_sales * coverage_days + safety
补货缺口
gap = target – (available + in_transit_usable)
if gap <= 0:
return 0
满足最小起订量，并向上取整到包装倍数
qty = max(gap, moq)
return int(-(-qty // pack_size) * pack_size)
volatility_factor 需要按品类回测：
稳定款 0.15~0.25，季节款 0.3~0.45，新品/爆款 0.5 以上
lead_time_days 必须 = 供应商交期 + 头程 + 清关 + 上架
这段代码里最容易被忽视的是 lead_time_days。我见过太多团队只填供应商交期 30 天，实际从下单到 FBA 可售是 52 天，中间 22 天的头程和上架时间被完全忽略，安全库存自然永远不够。
流程标准化的目标不是让流程变长，而是让每个节点都有明确的输入、输出和责任人。我通常把它拆成七个节点。
这里最关键的是"调整原因"和"异常回写"两个字段。没有调整原因，你永远不知道是参数不准还是运营在凭感觉改；没有异常回写，供应商交期永远是理想值。
前三层做完，第四层其实是"翻译工作"。我通常按四组配置项来检查 ERP 是否配到位。
确认平台 SKU 与主 SKU 的映射表可以在系统内维护并支持批量导入；确认仓库类型（本地仓、FBA、海外仓、在途虚拟仓）已正确建立；确认供应商档案里的交期、MOQ、包装倍数是必填项而不是选填。
我的经验是：把关键字段从"选填"改成"必填"，比培训十次都管用。因为选填的字段，在业务忙的时候一定没人填。
补货规则至少要能配置：触发方式（按天/按周/按水位）、销量统计窗口、安全库存公式的系数、是否计入在途、MOQ 与包装倍数取整、按仓库分别计算还是合并计算。如果系统只能配一个固定的覆盖天数，说明它在这层是缺失的。
审批规则建议按"金额 + 品类 + 补货类型"三维设置。比如常规补货 5 万以下采购主管审批，5-20 万供应链负责人审批，20 万以上加财务；新品首单无论金额都需负责人审批。
预警要区分等级：预计 7 天内断货为红色，8-14 天为橙色，15-21 天为黄色。看板要能按 SKU、品类、仓库、供应商四个维度下钻。这一层的检验标准很简单：采购每天早上打开系统，能不能在 5 分钟内知道今天该做什么。
指标层我坚持四件套，缺一个都会导致决策偏斜。
| 指标 | 定义口径 | 建议目标区间 | 预警信号 |
|---|---|---|---|
| 缺货率 | 有销量SKU中当周可售为0的占比 | 3%-6% | 连续两周上升，且集中在某几个品类 |
| 库存周转天数 | 平均库存 / 日均出库成本 | 60-90天（视品类） | 逐月上升且销量未增长 |
| 滞销SKU占比 | 连续90天无销量且库存超30天销量 | 低于15% | 某次大促后集中出现 |
| 采购准时到货率 | 按承诺到货日 ±3 天内到货的采购单占比 | 85%以上 | 某供应商连续两单延期 |
这四个指标的关系是：缺货率和滞销率是一对反向指标，周转天数是它们的综合结果，准时到货率是前置条件。只看其中一个，都会做出错误决策。我见过只考核缺货率的团队，把安全库存提到 90 天，缺货率降到 1%，但现金全压在了海外仓。
前五层基本都能靠工具和文档解决，第六层必须靠机制。协同标准要解决三个问题。
这一层我最推荐的做法是双周一次的补货复盘会，会议只讨论三件事：上周参数调整的实际效果、本周期的主要异常及归因、下周期的促销和上新计划。30 分钟，但能让协同从"出问题才沟通"变成"按节奏沟通"。
前面六层里，第一层和第五层本质上都是数据问题。在项目里我发现，团队真正的瓶颈往往不是"不知道该怎么算"，而是"算之前得先花两个小时把数据凑齐"。这个动作不解决，后面所有标准都落不了地。
这也是我在几个跨境团队里引入数跨境的原因。它的定位不是替代 ERP，而是把多平台、多店铺的订单、库存、在途、采购数据归集到一层，按主 SKU 维度做成可复用的宽表和分析看板，让补货计算有稳定的数据输入。官网在 https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys ，感兴趣的可以自己去看它的数据接入范围。
我通常按四步走，大概两周能跑通第一版。
把亚马逊、TikTok Shop、Temu、独立站等平台的订单和库存数据接入，然后建立平台 SKU 到主 SKU 的映射表。这一步做完，你会第一次看到"同一个产品在所有渠道的真实总销量"，很多团队在这一步就已经发现了之前的需求估算偏差。
在数据层明确写死三个公式：
可用库存 = 本地仓可用 + FBA可售 + 海外仓可售 – 已分配未发货
可计入在途 = 已发货且预计到仓日 <= 安全库存耗尽日 的在途数量
补货基数 = 近28天净出库量（扣除取消与退货）/ 28
这三个公式一旦固定下来，团队里关于"到底还有多少库存"的争论基本就消失了。这是我认为最有价值的一步。
在宽表基础上做补货测算：每个 SKU 显示当前可用库存、可计入在途、日均净出库、预计可售天数、建议补货量、建议下单日、风险标签。风险标签分三种：断货风险（预计可售天数小于提前期）、正常、滞销风险（可售天数大于 90 天且近 30 天无销量）。
每天早上自动推三条清单：断货风险清单、滞销风险清单、交期异常清单。采购不需要"看报表"，只需要"处理清单"。这个转变对执行效率的影响，比任何算法优化都大。
这是我在一个 12 人跨境团队跟进的观察记录（示意样本，非行业统计）。前 3 周主要在做数据接入和口径统一，缺货率基本没动；第 4 周开始上线补货建议，第 5-6 周出现第一次明显下降；第 7-9 周随着参数校准，两个指标同步改善；第 10-12 周进入稳定期。
这个阶段不建议上重型 ERP。先用 Excel 或轻量工具把两件事做扎实：主 SKU 映射表和一张明确的补货参数表。参数表里每个品类一行，写清提前期、覆盖天数、安全系数、MOQ。这份表的价值远大于任何系统。
这是最需要"数据层 + 轻量 ERP"组合的阶段。用数据工具把多平台数据合流（我在上一节讲的四步法），用 ERP 或采购模块承载流程和审批。这个阶段的关键是不要再靠人工拼表，因为渠道数已经超过了人工能稳定处理的阈值。
这个阶段要做的是三层架构：数据层（合流与宽表）、系统层（ERP 流程与审批）、分析层（补货测算、资金占用、供应商绩效）。同时把协同标准第六层真正建起来，包括供应商交期考核和双周复盘机制。
先修提前期，再修安全库存。九成断货问题的根因是提前期算短了，只算供应商交期，没算头程、清关、上架和质检。把 lead_time_days 补完整，很多问题自动消失。
先做 ABC 分类，再分品类调参数。压货通常集中在 C 类长尾 SKU 上，因为大家给所有 SKU 用了同一套保守参数。把 C 类的覆盖天数砍到 A 类的一半，资金占用能下降很快。
先做交期回写和供应商考核，再谈算法。做法很简单：每张采购单记录承诺交期和实际到货日，每月统计各供应商的准时率，准时率低于 80% 的供应商进入观察名单，连续两月不改善就分流订单。
把促销计划作为参数输入，而不是事后解释。做法是在补货参数表里增加一个"促销系数"字段，大促前 6-8 周把系数调到 1.5-2.5（按历史大促倍数回测），大促结束后自动回落。这样补货计算就带上了前瞻性。
| 阶段 | 核心任务 | 交付物 | 验收标准 |
|---|---|---|---|
| 第 1-30 天 | 现状盘点、主数据清理、参数初稿 | 主SKU映射表、补货参数表v1、流程图 | 销量前80%的SKU映射完整率≥95% |
| 第 31-60 天 | 小范围试运行、异常记录、参数校准 | 试运行周报、异常清单、参数表v2 | 试运行品类缺货率下降≥3个百分点 |
| 第 61-90 天 | 指标复盘、审批固化、看板上线 | 四指标看板、审批规则文档、复盘机制 | 四指标可自动出具，周度复盘常态化 |
我希望强调一点：不要追求一次做全品类。挑一个品类先跑通 90 天，比全品类同时上线但哪一层都没做透，成功率高得多。
标准化越深，规则的例外情况越多，维护成本越高。我的判断是：把 80% 的常规补货流程标准化，给 20% 的例外场景留手动通道。新品、大促、清仓这三种场景本来就不适合用常规规则，硬塞进去只会让规则越来越复杂。
完全自动下单在跨境场景里风险很高，因为提前期长、改单成本高。我建议至少保留"人工确认"这一环，但要求填写调整原因。原因数据攒够 3 个月后，你会发现很多调整其实是参数问题，而不是运营的判断更准。
统一参数管理简单，但会掩盖平台差异。分平台参数更准，但维护成本成倍增加。我的折中方案是：按品类统一参数，只对提前期和退货率按平台做区分。因为这两个是平台间差异最大的变量，其他参数差异相对小。
这是一个纯财务问题，答案取决于两个数：毛利率和缺货的真实成本。我通常这样算：如果某品类毛利率 35%，断货两周导致的排名下滑需要额外 20% 的广告费才能补回，那么缺货成本其实非常高，宁可多备一些。反之，低毛利长尾品就应该严格控制安全库存。
自建和开源的优势是可控、可定制，代价是需要持续的开发维护人力。我见过一个团队用开源方案搭补货系统，开发用了 4 个月，之后每季度还要投入 1 个人月维护。如果团队没有稳定的数据开发能力，SaaS 的综合成本一定更低。判断标准很简单：你有没有一个能持续投入的数据开发岗。
我强烈建议先做深度。用 ABC 分类，先覆盖贡献 80% 销量的 A 类 SKU，把参数和流程打磨到位，再向 B、C 类扩展。全 SKU 同时上线的结果通常是：A 类没做细，C 类浪费了大量精力。
如果让我给一个没有特殊情况的跨境团队一套默认取舍，我会这样定：常规补货标准化 + 新品大促手动通道；保留人工确认但强制填写调整原因；按品类统一参数、按平台区分提前期；服务水平目标设在 90%-93%；优先采购成熟 SaaS 而非自建；先做 A 类 SKU 再做全品类。
这套默认值不是最优解，但它是风险最低、见效最快、最容易在团队里达成共识的起点。标准化本身就是一个迭代过程，先跑起来比先想清楚更重要。
不需要全做，但至少要做两件：主 SKU 映射表和补货参数表。这两件事加起来大概两天的投入，却能让你们的补货逻辑从"在脑子里"变成"在文档里"。人少的时候最大的风险不是算不准，而是所有经验都锁在一个人身上。
按我见过的案例排序，问题大概率出在三个地方：供应商交期字段长期不更新、在途库存全部计入可用、多平台销量口径不统一。这三项都不属于 ERP 的能力问题，属于数据治理问题。先把这三个字段的准确性修好，再评估要不要换系统。
没有统一答案，但有一个可操作的方法：用过去 12 个月的数据回测，把覆盖天数依次设为 15/25/35/45/60 天，分别计算缺货损失和资金占用成本，选综合成本最低的那个点。我在样本里看到的最优点通常在 25-35 天之间，但取决于品类毛利率和缺货成本。
不建议。至少要处理三件事：去除取消和退货（用净出库量）、避免同一订单重复统计、考虑平台间的流量替代。如果这三个都没处理，直接相加通常会高估需求 5%-15%，导致系统性超补。
要允许，但必须留痕。我的做法是：人工可以改，但要选调整原因（促销备货、供应商涨价、清仓、参数问题、其他）。攒三个月的原因数据，你会发现相当比例的调整其实指向同一个参数问题，那时候就该改参数，而不是每周改一次数量。
两条腿走。短期把安全库存按"历史最长交期"而非"平均交期"来算，先保不断货；长期建立供应商准时率考核，连续两月低于 80% 就分流订单。不要试图用一个算法去消化供应商的不稳定，那是管理问题。
按我的样本估算，6-20 人团队首年投入大概在 6 万元级别（含数据工具与轻量 ERP），年化收益在 18 万元左右。见效节奏通常是这样：前 3-4 周主数据一致率提升，第 5-6 周缺货率开始下降，第 9-12 周滞销率改善。如果三个月内三项指标都没动，先检查是不是只做了工具没做流程。
不冲突，是互补。ERP 负责流程、单据、审批，数据工具负责把多平台数据合流、做宽表和测算看板。我在项目里的组合方式是：数据层先做出补货建议和风险清单，ERP 承接请购、审批、下单和到货回写。两者之间用主 SKU 和采购单号对齐即可。
我做了这么多项目，最深的一个体会是：一个团队补货水平的高低，不看它有没有断货，而看它能不能解释每一次断货和每一次压货。能解释，说明背后有规则、有数据、有归因路径，下次就能改；不能解释，就只能归咎于"运气不好""平台流量波动""供应商不靠谱"。
所以我不太推荐大家一上来就追求"零缺货"。更现实的路径是：建立一套能自我解释的补货体系，每一笔补货量都能追溯到参数，每一次参数调整都能追溯到回测数据，每一次异常都能追溯到具体节点和责任人。做到这一点，缺货率和滞销率的改善只是时间问题。
如果你的团队现在正准备做这件事，我建议下一步先做三件最小动作：第一，导出近 90 天的平台 SKU 清单，检查有多少没有映射到主 SKU；第二，把供应商档案里的交期、MOQ、包装倍数补全，并核对是否包含头程和清关；第三，挑一个占比最大的品类，用历史数据回测一次覆盖天数，看综合成本最低点在哪里。这三件事加起来不超过一周，但足以让你判断自己的补货到底缺的是工具，还是标准。
等这三件事做完，再考虑要不要引入数据工具做合流。顺序反了，工具只会把混乱放大得更快。
我们公司做亚马逊加独立站，两个运营各管一摊，采购天天追着问要不要补货，老板就让我找一套ERP把补货管起来。我试了两家系统，发现光是把SKU导进去就卡住了，同一个产品在平台上被拆成好几个链接。所以我现在也搞不清到底该先动系统还是先动流程。
先理口径，再配系统，顺序反了就是白花钱。具体做法是四步：第一，拉出近90天全部订单和库存流水，按SKU×平台×仓库做一张对照表；第二，统计没有完成映射的SKU占比，如果超过5%，说明主数据本身就是乱的，先做映射再谈补货；
第三，明确每个字段的责任人，谁维护SKU、谁维护供应商、谁维护MOQ和交期，必须落到人名而不是部门；第四，才把这些字段配进ERP。判断依据很简单：如果同一个物理SKU在两个平台被当成两个单品，任何补货公式算出来的结果都是错的，库存会一边压一边缺。
可以给自己定一个验收标准，随机抽20个SKU，从任意一个平台订单出发，能在3分钟内查到它的总可用库存、在途数量、供应商交期和MOQ，这套基础数据才算合格，之后配自动补货规则才有意义。
我一直是用Excel记销量，凭感觉给每个SKU留一点库存，结果去年旺季断了好几个爆款，淡季又压了一堆货。听说现在的ERP都有智能补货，我开过一次，系统给出的建议量比我平时下的单多了一倍，吓得我又关掉了，实在不敢照着下单。
别一上来就放开自动补货，先算清楚参数再跑影子模式。安全库存先用简化公式起步：安全库存 = 日均销量 × 安全天数，安全天数看交期波动，比如采购交期14天、实际到货经常上下浮动5天，就先给5到7天的缓冲；再订货点 = 日均销量 ×（采购交期 + 清关入仓天数）+ 安全库存。
然后关键一步是跑影子模式，让系统每天出建议量，人工照常下单，把两边的差异逐条记下来，是为促销备货、季节性、还是系统把历史大促的峰值当成常态销量。跑满一个采购周期，一般4到8周，差异收敛到可解释的范围，再逐步放开自动触发。
参数不是一次性定死的，建议每季度复盘一次，旺季前单独调一次促销系数，新品和清仓品单独走人工审批，不套统一公式。
我们有速卖通、Shopee、Lazada三个平台，外加一个海外仓和一个FBA仓，运营各自看自己的后台，采购拿到的是一张手工汇总表。经常出现的情况是A平台说快断货了，B平台却还躺着一堆货，到底该不该补，谁也说不清。
合并的关键是按去重后的物理SKU归集，而不是按平台链接，销量按发货口径而不是下单口径统计。第一，建平台SKU到内部SKU的映射表，一个内部SKU对应多个平台链接；第二，销量用发货口径，下单口径会把未付款、取消单、超卖退款都算进去，虚高幅度通常在5%到15%，用来算补货会系统性放大；
第三，在途必须按节点拆分归属，头程在途、海外仓在途、FBA在途的可售时间完全不同，要分开列，并明确每一项归属到哪个仓库；第四，补货触发的比较口径统一成 可用库存（本地可发 + 平台可售）+ 可预期在途，去对比目标库存，有缺口才补。
这样处理之后，B平台的滞销库存可以优先调拨而不是继续采购，缺货和压货才有可能同时下降。
我们上了系统、也定了流程，可老板每次问效果，我只能说比之前好一点，拿不出数据。采购说现在规范多了，运营还是抱怨该断的照样断。我自己也怕这波投入最后变成买了个系统摆着，所以特别想知道有没有一套能验证的说法。
用四个指标和三个月的节奏来验证。指标一，缺货率，统计有流量却没库存可卖的SKU天数占比；指标二，库存周转天数，按月滚动看；指标三，采购准时到货率，按承诺交期前后3天内到货为达标；指标四，滞销率，统计90天无销量的库存金额占比。
节奏上，第一个月清理字段和SKU映射，第二个月挑20到30个高销量、供应商稳定的SKU试运行，第三个月固化审批流和看板上线，再逐步扩品。判断标准是有方向的：连续两个采购周期，缺货率下降的同时库存周转天数没有上升，才算真正落地；
如果缺货率降了但周转天数明显涨了，说明参数给得太松，本质是把风险变成库存资金，这时候该回去收紧安全天数和目标库存覆盖天数，而不是继续加采购量。
读者评论
做跨境采购的，看到“先统一口径再谈算法”很有共鸣。我们四平台SKU映射没做全，销量和库存表每周都对不上，补货基数本身就有问题。安全库存按完整提前期算也是真痛点，用国内7天思维套跨境必然缺货。
从ERP实施角度看，六层结构有参考价值，尤其“流程草稿应在选型前存在”。很多项目失败不是系统不行，而是审批、异常回写、供应商交期没人定。不过参数回测和MOQ处理仍要按品类细化，不能照搬。
运营角度，爆款断货掉排名权重的隐性成本常被忽略。补货会靠感觉、系统只当存档工具，确实常见。文中说自动补货重点在暴露异常而非自动下单，这点很务实，但小团队做每日异常日报可能仍缺人力。