去年年底我陪一个做家居类目的卖家盘库存，他手里有 7 个亚马逊站点店铺、2 个独立站和 1 个沃尔玛店，同一个折叠置物架 SKU 分散在 3 个 FBA 仓、1 个美西海外仓和国内一个直发仓里。运营说这个款还在起量，日均能出 40 单；采购说仓库里还有 1800 件，不用补；老板看财务报表说这个款压了 26 万资金。三个人说的都对，但三个人说的是三件事。最后这个款在 2 月断货 11 天，同时在另一个站点积压到触发长期仓储费。
这不是 ERP 功能不够，是采购补货的决策口径根本没统一。
所以我写这篇东西，不想再重复“ERP 打通全链路”“一键同步库存”那套话。我想把多店经营下采购补货这条链路拆开讲清楚：ERP 到底该管什么、不该管什么、哪些参数必须自己定、哪些坑我亲自踩过。文中涉及的功能演示我以数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）为例，因为它的库存池 + 采购工作流结构比较适合讲清楚这条链路；
涉及平台政策和费率的部分，请以各平台官方最新文档为准，我这里只给判断逻辑。文中标注为“示意数据”的，全部是基于我经手的卖家样本做的推演，不是平台官方统计。
我先给结论，后面再展开论证。如果你只想要一句话：多店采购补货的难点是口径问题，不是工具问题；ERP 解决的是“让同一套口径跑在多个店铺上”的效率问题，它不会替你做判断。
我把过去几年经手的卖家案例归纳成五条判断，按重要性排序。
很多人对 ERP 的期待是“我设个阈值，它自动告诉我补多少”。真实情况是：ERP 能稳定输出的是订单、库存快照、销速、在途状态这些事实数据，而“补多少”是一个包含供应商交期、资金压力、促销计划、清库存意图的综合判断。
把决策权完全交给系统，结果通常是两种：要么阈值设得保守，资金全部压在库存上；要么阈值设得激进，大促前断货。两种我都见过，而且往往同时存在于同一家公司不同店铺里。
店铺越多，SKU 映射越乱。平台 SKU、本地 SKU、组合装、变体、赠品、多站点同款不同编码，这些不统一，后面所有库存和销速计算都是错的。
我见过最夸张的一个卖家，同一个产品在 6 个店铺里有 9 个 SKU 编码，其中 2 个是组合装。他的 ERP 显示这个产品总库存 3200 件，实际可用库存只有 2100 件，剩下的是组合装拆解后的虚拟库存和不可售库存。
一维是履约模式（FBA / 海外仓 / 国内直发 / 本地仓），二维是店铺或站点（流量结构和促销节奏不同），三维是 SKU 生命周期（新品、成熟款、清仓款）。
只按 SKU 设一套参数的，几乎一定会出现“A 店断货、B 店积压”。因为同一个 SKU 在两个店铺的真实销速可能差 3 倍以上。
我的建议是把补货分成两类：常规补货走自动建议 + 抽查复核，异常补货（大促、新品、高客单、长交期）强制人工审批。不做这个区分，要么效率上不去，要么错误没人拦。
不要一上来全店铺全 SKU 切换。先跑通一条完整链路，把销速口径、交期数据、审批流、异常处理都验证一遍，再横向复制。这一步省不掉，省掉的话后面返工成本是试点成本的 5 倍以上。
抽象讲“多店管理复杂”没有意义，我直接给你三个具体场景。这三个场景几乎覆盖了 80% 的多店补货问题。
那个家居卖家的情况是：美国 FBA 仓 620 件可售、加拿大 FBA 仓 180 件、美西海外仓 900 件、国内直发仓 1100 件、还有 400 件在头程海运途中。运营看到的“库存”是 FBA 可售的 620；采购看到的“库存”是所有仓加起来 2800。
问题是：加拿大 FBA 的 180 件在加拿大站点卖不掉，调拨到美国要走移除 + 重新入仓，周期 3-4 周且成本高；海外仓的 900 件可以发美国 FBA，但补货周期是 12 天；国内直发的 1100 件小包时效 9-14 天，客户体验差，只能作为兜底。
所以在“能不能补”这个问题上，这 2800 件里真正能立刻解决美国站点缺货的，只有海外仓那 900 件。库存总量这个数字在多店场景下几乎没有决策价值，有价值的是“分仓、分状态、分可用性的库存结构”。
运营算销速用最近 7 天，因为要看趋势；采购算销速用最近 30 天，因为要平滑波动；财务算销速用最近 90 天，因为要算周转。三个口径都合理，但结论差很远。
举个真实数字：某款小家电在美国站，7 天日均 52 单（因为刚跑完秒杀），30 天日均 31 单，90 天日均 24 单。如果按 7 天口径补货，采购量会比 30 天口径多出 68%。这个差额在淡季就是纯滞销。
我后来的做法是：补货决策统一用 30 天日均作为基准，同时叠加两个修正系数，近 7 天趋势系数和促销计划系数。趋势系数只在偏差超过 ±20% 时才启用，促销系数由运营在补货单上填，系统不猜。
这是最容易出事的环节。采购在系统里下了单，ERP 把数量计入“在途库存”，运营看到在途就觉得货在路上了，于是继续投放广告。
但真实情况是：供应商可能还没发货，可能只发了一半，可能在头程拼柜等仓，可能清关卡了两周，可能到海外仓但还没上架。从“下单”到“可售”，中间有 5-7 个状态，任何一个卡住，在途库存都是假的。
我见过一个卖家在黑五前 3 周下单补货，ERP 显示在途 2400 件，结果船期延后 12 天，黑五当天 FBA 只有 380 件库存。这个损失不是 ERP 的问题，是没有人把“在途细分状态”和“可用日期”做成一个必须填的字段。
这一节我列的是真实发生过的错误，不是理论上的风险。你可以对照自己的流程看看中了几条。
表现是：全公司只有一个人会看补货建议，其他人默认“系统说补就补”。一旦这个人的参数设错，全店铺一起错。
我的判断是：补货建议的采纳率不应该接近 100%。如果一个团队的补货建议采纳率长期在 95% 以上，通常说明两件事之一，参数设得太保守，或者根本没人认真看。
美国站日均 40 单、加拿大站日均 6 单，用同一个安全库存天数，结果必然是美国站频繁断货、加拿大站长期积压。
正确的做法是按“销速 × 交期波动”分别计算。加拿大站交期更长（因为 FBA 入仓排队和调拨），但销速低、波动也低，所以安全库存天数反而可以设得比美国站短。
平台后台的建议补货量只考虑平台仓的销速和入仓限制，它不知道你海外仓还有 900 件，也不知道你供应商下个月要涨价你打算提前囤货。
我的用法是：把平台建议当成一个参考输入，而不是决策输出。它会出现在我的补货单里作为“平台视角建议”，但最终数量由人工确认。
一个组合装 SKU = 2 个单品 A + 1 个单品 B。如果不做 BOM 折算，你会发现单品 A 的库存永远对不上：组合装卖出去 1 个，单品 A 的库存应该减 2，但很多人只减了 1（甚至没减）。
这个错误会在 3-6 个月后集中爆发，表现为“系统显示有货、实际发不出”。修正的办法是在 ERP 里建立组合装的物料清单映射，并让出库动作回写单品库存。
同步成功只说明接口跑通了，不说明数字对。库存不准确的典型来源是：平台侧有预留/冻结订单未回传、退货入库未及时处理、人工调拨没登记、次品没有及时转不可售状态。
我建议每周做一次“三方差异对账”：ERP 库存 vs 平台后台库存 vs 物理盘点抽检。差异率超过 2% 就先停下来查原因，不要继续放大补货。
有些团队希望库存实时同步，于是把同步频率调到分钟级。结果一是容易触发平台限流，二是接口异常时数据反而是错的，三是把 ERP 性能拖垮。
我的建议是：库存同步频率按业务需要设，不按心理需要设。日销千单以内的店铺，15-30 分钟同步一次足够；大促期间临时提高到 5 分钟，但必须同时开启超卖预警和人工兜底。
前面讲的是问题和误区，这一节讲我实际用的方法。我把它总结成“一套库存池、四层决策链、三层参数”。这套框架不依赖具体哪个系统，你在 Excel 里也能跑，只是效率差别很大。
不管用什么工具，库存至少要拆成这五个字段，而且每个字段都要有明确的更新责任人和更新时机。
这五个字段里，最常被忽略的是“待上架”和“在途细分”。这两个字段缺失，补货建议就会系统性偏乐观。
我用的销速公式是：基准销速 = 近 30 天日均销量（剔除缺货天数）× 近 7 天趋势系数 × 促销计划系数。
“剔除缺货天数”这一步非常关键。很多 ERP 默认用自然日计算，导致一个断货 10 天的 SKU 日均销量被严重低估，补货建议偏少，然后继续断货，形成恶性循环。
趋势系数我一般限制在 0.8-1.3 之间，超过这个范围说明数据异常或有大促，应该走人工复核而不是让系统自动放大。
这是最核心的一层。我给一个可以抄的框架，但请注意：这是框架，不是标准答案，所有常数都必须用你自己的历史数据校准。
补货点 = 基准销速 × （供应商交期 + 头程时效 + 入仓上架时效） + 安全库存
安全库存 = 基准销速 × 安全天数 × 波动系数
其中：安全天数 = 按履约模式取值
波动系数 = 近 90 天销速标准差 / 近 90 天平均销速
波动系数 0.6 取 1.5
建议补货量 = MAX(补货点 – 可用库存 – 在途库存, 0)
建议补货量 = ROUNDUP(建议补货量 / 装箱率) × 装箱率
建议补货量 = MAX(建议补货量, MOQ)
最终补货量 = 建议补货量 × 人工调节系数（0.5 – 2.0）
最后那个“人工调节系数”是我坚持要留的。它把系统的自动建议和人的判断分开记账，方便后续复盘是谁的判断更准。
执行层的关键不是“下单”，而是让在途状态自动流转并回写。理想状态下，采购在下单时就把预计发货日、预计到仓日填进去，后面每个状态变更都在系统里留痕，到仓上架后自动把“在途”转成“可售”。
如果这一步靠 Excel 手记，那在途数据大概率是过期的。我见过太多“Excel 上写着在途 2000，实际只到了 800”的情况。
下面这张表是我给卖家做初始配置时常用的取值区间，可以直接作为起点，跑 4 周后再校准。
| 参数 | FBA / 平台仓 | 第三方海外仓 | 国内直发 |
|---|---|---|---|
| 安全库存天数 | 14-21 天 | 21-35 天 | 5-10 天 |
| 补货周期（触发频率） | 7 天 | 14 天 | 3 天 |
| 交期取值口径 | 供应商交期 + 头程 + 入仓排队 | 供应商交期 + 头程 + 上架 | 供应商交期 + 揽收时效 |
| 波动系数上限 | 1.5 | 1.3 | 1.2 |
| 人工审批触发条件 | 单次金额 > 5 万 | 单次金额 > 8 万 | 单次金额 > 2 万 |
讲完方法论，我讲一次完整的落地过程。这个案例的合作方要求我用具体工具演示，我选的是数跨境，因为它的结构里“库存池 + 采购工作流 + 在途跟踪”这条链路比较完整，适合拿来对标我前面讲的四层决策链。链接在开头给过了（https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys），下面只讲我怎么用它，不讲它的功能清单。
卖家情况：亚马逊 5 个站点店铺 + 2 个独立站 + 1 个沃尔玛店，SKU 约 1400 个，履约模式覆盖 FBA、美西海外仓、国内直发三种。日均订单约 900 单。问题是断货率在旺季能到 12%，同时滞销库存占比 21%。
我们定的试点目标是：选 2 个店铺、20 个 SKU，跑 4 周，把断货率压到 6% 以内，把补货人工耗时从每周 9.5 小时降到 5 小时以内。注意是过程目标，不是“全店降本 30%”这种没法验证的目标。
这一步花的时间最多，占整个试点的一半以上。具体做法是：
归并完后发现一个关键问题：原来按 SKU 统计的“总库存 12.4 万件”，按产品主编码归并后实际只有 9.7 万件，另外 2.7 万件是各店铺重复统计的同一批货和组合装虚拟库存。也就是说，他之前的补货决策是建立在一个虚高 27% 的库存基数上的。
我把三个口径摆在一起给团队看，然后统一成“近 30 天日均（剔除缺货日）× 趋势系数 × 促销系数”。这一步的阻力和技术无关，纯粹是部门之间的口径之争。
为了让团队接受，我做了一件事：拿 20 个试点 SKU 的历史数据回测，分别用 7 天、30 天、90 天口径算出补货量，再对比实际发生的结果。30 天口径的预测偏差最小（平均 14%），7 天口径偏差最大（平均 31%）。数据摆出来之后，口径之争就结束了。
在数跨境里把参数按履约模式分了三组配置，然后开启补货建议。第一周生成的 63 条建议里，采购只原样采纳了 27 条，采纳率 43%。
这个数字我一开始以为是配置错了，后来逐条核对发现：有 19 条建议被下调，原因是采购知道供应商下周有涨价通知准备提前囤；有 11 条被上调，原因是运营确认要报一个秒杀活动。这两类信息系统不可能知道，必须由人输入。
所以我们加了一个字段：补货单必须勾选“是否有已知促销/涨价/停产计划”，勾选后自动进入人工审批通道。
这一步是效果差异最大的。原来在途状态只在采购的 Excel 里，现在把在途拆成 5 个状态，每个状态有预计日期，到仓上架后自动把在途数量转为可售。
试点期间抓到一个典型问题：有个 SKU 显示在途 600 件，但状态停在“清关中”已经 19 天，超过预估到仓日 11 天。系统给出了超期预警，运营据此提前把广告预算下调了 30%，避免了断货期的高额浪费。
四周结束时，两个试点店铺的断货率从 11.8% 降到 5.9%，库存准确率从 81% 升到 95%，补货人工耗时从每周 9.5 小时降到 4.6 小时。滞销库存占比从 21% 降到 16%。
但有一个反常识的发现：断货率下降最明显的不是补货建议最准的 SKU，而是交期数据最准的 SKU。我们按“交期数据完整度”把 20 个 SKU 分成两组，交期记录完整的 12 个 SKU，断货率平均下降 7.2 个百分点；交期靠估的 8 个 SKU，只下降 3.1 个百分点。
这个发现改变了我后面的实施顺序：我现在的做法是先补齐供应商交期数据，再调补货参数。因为在交期不准的前提下调安全库存，只是在用更多的钱掩盖数据缺失。
我不建议所有卖家都立刻上系统。店铺数和履约复杂度不到一定阶段，上系统反而是负担。下面按规模分三档给建议。
这个阶段你的瓶颈不是工具，是流程。建议先做三件事：
这个阶段上 ERP 的典型失败模式是：系统买了，参数没人校准，半年后还在用 Excel 下单，系统只用来看看库存。
到这个阶段，共享库存、跨店调拨、多仓在途已经无法靠人工维护。你需要的是能统一库存口径并输出补货建议的工具，具体是哪个不重要，重要的是它能做到三件事：按履约模式分组配置参数、支持 SKU 多平台映射、在途状态可细分并自动回写。
我的建议是先用 2 个店铺 + 20 个 SKU 试点 4 周，验证这三件事再全量铺开。
这个规模下最大的风险不是断货，是错误被放大。一个参数设错，可能同时影响 8 个店铺的采购决策，涉及金额是百万级。
所以必须做到：补货建议和采购下单分离、超额必须审批、审批留痕可追溯、权限按店铺和金额分级。这时候工具选型的重点会从“功能多不多”转向“流程控不控得住”。
多店补货没有完美方案，只有取舍。下面四组取舍是我被问得最多、也是我踩过坑的。
共享库存池的好处是资金效率高、调拨灵活；坏处是超卖风险大。分店独立库存的好处是安全边界清晰；坏处是整体库存水位会显著升高。
我的判断标准是看同步延迟：如果你们的库存同步能做到 15 分钟内、且平台支持库存预留，那可以共享；如果同步经常延迟半小时以上，就老老实实分店独立，最多设置一个“可调拨缓冲池”。
实时同步听起来很美，但代价是接口稳定性风险和平台限流风险。我的经验值是：日销 1000 单以内的店铺，15-30 分钟同步一次完全够用；只有在秒杀、直播、大促这种瞬时高并发场景才需要临时提高频率，而且必须配人工兜底。
全自动审批的效率最高，风险也最大。我推荐的是分级：小额常规补货自动通过，超额、新品、高客单、长交期、大促前这五类强制人工。
判断阈值不要拍脑袋，用历史数据算：把过去 6 个月的补货单按金额分档，看哪个金额以上的人工调整比例明显升高，那个点就是你的审批阈值。
自建的优势是数据完全自有、流程完全可控；劣势是需要专职开发和持续维护，而且平台 API 变化频繁。
我的判断是：除非你的年 GMV 在 5000 万以上且有稳定技术团队，否则不要自建补货系统。自建的成本大头不是开发，是后续 3 年的接口维护和规则迭代。
方法论最后一定要落到动作上，否则就是空谈。下面这套 SOP 我在多个卖家团队里跑过，直接改改就能用。
日检查的时间控制在 30 分钟以内。如果每天花 2 小时处理预警，说明阈值设得太松，预警失去了筛选功能。
周复盘的重点不是“处理完”，而是把人工调整的原因沉淀成参数修正。如果同一类调整连续三周出现，说明参数该改了，而不是人该继续手动改。
下面是我常用的补货参数配置结构，你可以直接照着填，填不出来的字段就是你要补的数据缺口。
sku_code: SKU-10231 # 本地主编码
product_code: P-8821 # 产品主编码（多平台归并后）
fulfillment_mode: FBA_US # 履约模式：FBA / OVERSEA / DIRECT
lifecycle: MATURE # 生命周期：NEW / MATURE / DECLINE / CLEARANCE
lead_time:
supplier_days: 12 # 供应商交期
first_leg_days: 16 # 头程时效
inbound_days: 6 # 入仓上架时效
lead_time_total: 34 # 合计，系统自动汇总
velocity:
base_daily: 31 # 近30天日均（剔除缺货日）
trend_coefficient: 1.15 # 趋势系数，限幅 0.8 – 1.3
promo_coefficient: 1.00 # 促销系数，由运营填写
effective_daily: 35.65 # 有效销速 = base * trend * promo
safety:
safety_days: 21 # 安全天数，按履约模式取值
volatility: 0.42 # 波动系数
safety_stock: 315 # = effective_daily * safety_days * volatility
replenish:
reorder_point: 1527 # 补货点 = effective_daily * lead_time_total + safety_stock
moq: 200
pack_size: 50 # 装箱率
manual_factor: 1.00 # 人工调节系数，限幅 0.5 – 2.0
approval:
auto_approve_limit: 50000 # 单次金额上限（元）
require_review: true # 新品/大促/长交期强制人工
| 序号 | 自检项 | 达标标准 |
|---|---|---|
| 1 | SKU 主编码归并完成 | 多平台 SKU 能映射到唯一产品主编码 |
| 2 | 组合装 BOM 已建立 | 组合装出库能正确扣减单品库存 |
| 3 | 库存拆成五个字段 | 可售 / 锁定 / 在途 / 不可售 / 待上架齐全 |
| 4 | 在途细分 5 个状态 | 每个状态有预计日期和责任人 |
| 5 | 供应商交期有历史数据 | 至少 3 个月的交期记录 |
| 6 | 销速口径已统一 | 全公司用同一个销速算法 |
| 7 | 缺货天数被剔除 | 销速计算排除断货期 |
| 8 | 装箱率与 MOQ 已补齐 | 每个 SKU 都有这两个字段 |
| 9 | 审批阈值有数据依据 | 按历史调整比例分档确定 |
| 10 | 对账机制存在 | 每周至少一次三方差异对账 |
| 11 | 试点范围明确 | 1-2 店铺 + 10-20 SKU + 4 周 |
| 12 | 出口条款已确认 | 数据导出能力和合同退出条款清楚 |
这 12 项里，如果第 1、3、4、6 项没做到，我的建议是先别急着上系统，先花两周把数据补齐。在这些字段缺失的情况下上系统，只是把 Excel 的错误搬到了更贵的软件里。
我最后想强调一个和主流说法不太一样的观点：多店采购补货的核心竞争力，不在 ERP 的功能列表里，而在你自己的参数体系里。
同一套系统，两个团队用出来的效果可能差 3 倍。差别不在谁的功能开得多，而在谁的库存口径更干净、交期数据更准、人工复核记录更完整。我见过用 Excel 把补货做得非常稳的小团队，也见过上了系统还天天断货的大卖家。
所以我的建议是把顺序倒过来：
如果你现在正处在选型阶段，我建议带着三个数字去看产品：你的店铺数、你的 SKU 数、你覆盖的履约模式类型。这三个数字决定了你需要的是库存池、还是审批流、还是两者都要。工具本身没有好坏，只有匹配不匹配。先用 20 个 SKU 把链路跑通，比看一百篇功能对比文章都有用。
补货这件事没有终点，只有校准。参数会随着供应商、平台政策、品类季节性和竞争格局不断变化，真正稳定的是你那套“记录，复盘，修正”的循环。把循环建起来，换什么工具都不会慌。
我手上有三个店铺卖同一款货，国内就一个仓，去年大促的时候 A 店和 B 店同时出单，结果超卖了十几单，赔了钱还被平台扣分。ERP 销售都说自己能实时同步，可我不知道到底该信到什么程度，也不清楚该怎么设缓冲。
先分清一件事：ERP 的库存同步是拉取加回写，不是真实时，平台库存回传给 ERP、ERP 再写回其他店铺中间一定有延迟。可执行的做法分四步。第一，把三个店铺的平台 SKU 映射到同一个本地 SKU，否则库存根本不在一个池子里算。
第二，实测延迟，用一个测试 SKU 在 A 店下 1 单，记录 ERP 库存变化时间和 B 店可售库存变化时间，这个实测秒数就是你所有缓冲设置的依据。第三，按实测延迟乘以峰值销速预留缓冲带，比如延迟 90 秒、大促峰值每分钟出 2 单，那缓冲至少留 3 到 5 件，而不是拍一个百分比。
第四，大促、爆款这类高风险场景不要完全共享库存，改成按店铺配额分配，再设一个预警线，比如某 SKU 可售库存跌到 3 天销速就人工锁单或下架。判断依据很简单：同步延迟没测过，任何缓冲数字都是猜的。
我看了好多教程，公式写得都差不多，可套到我自己的店铺不是旺季断货就是淡季压一堆货，资金全压在海运在途上。我怀疑是不是我用全店平均销速算的原因，但也不知道该怎么改。
公式框架可以用这一个：补货点等于日均销速乘以（供应商交期加头程时效加入仓上架准备天数），再加安全库存；安全库存等于日均销速乘以交期天数再乘以波动系数。真正决定准不准的是三个口径。第一，销速必须分店铺、分 SKU 算，不能用全店平均，因为不同店铺的流量和促销节奏不一样。
第二，销速用近 7 天、14 天、28 天加权，并且剔除促销日和自己测评的订单，否则峰值会把补货点抬高。第三，波动系数来自你自己的实测，把过去 8 到 12 周的周销量标准差除以周均值，得到的就是你的波动系数，不要抄别人的 1.5 或者 2。
举个例子说明逻辑：日销 20 件、供应商交期 15 天、头程 20 天，基准补货点是 700 件，安全库存按波动系数 0.5 乘以 35 天再乘 20 件，大约是 350 件，合计 1050 件。这只是示例，跑满 4 周后要用实际缺货率和滞销金额反过来校准。
新品没有历史数据，就找同类目、同价格带的老品做映射，并且第一轮补货量砍半试销。
我们公司三种模式都在跑，运营说一套参数管所有，采购说完全不行，每次开会都在吵。我自己也糊涂，不知道是应该按 SKU 设参数，还是按仓库设参数。
不能共用阈值，但可以共用流程。这三种模式的约束条件完全不同。平台仓比如 FBA 的核心约束是入仓和补货限制、仓储费以及长期库存附加费，补货点要按可售加在途一起算，同时盯住可用库容，冗余库存宁可走调拨或移除也不要硬压。
海外仓的核心约束是头程时效和入仓上架时间，批次大、频次低，安全库存要给得比直发高，因为它响应慢。国内直发的核心约束是供应商交期，库存风险和资金占用小，但缺货容忍度低，所以适合低安全库存、高频补货。判断依据建议用两个维度打分：资金占用和缺货损失。
资金占用高的模式宁可牺牲一点缺货率，缺货损失高的模式宁可多备一点。落到 ERP 设置上，参数维度应该是店铺加仓库加履约方式，每个组合一套阈值，而不是一个 SKU 只挂一套参数。如果你们的 ERP 只能按 SKU 设一套参数，那至少在采购审批环节做人工分流，按履约方式走不同的复核规则。
我们刚上了一套 ERP，老板要求下个月所有店铺都用采购补货建议下单。我担心数据还没洗干净就全铺，出了问题反而要背锅，也不知道该拿什么指标跟老板汇报。
先试点，跑满 4 周再推广。选 1 到 2 个店铺、10 到 20 个 SKU，最好覆盖至少一种履约模式。第 1 周只做基础工作：清洗 SKU 映射、统一库存口径，明确可售等于实物减锁定减次品减已下单未出库。
第 2 到 3 周照常出补货建议，但必须人工复核，并且把每一次修改都记下来，记录建议值和实际下单值。第 4 周复盘。要看的指标有五个：缺货率、超卖次数、库存周转天数、补货建议采纳率、在途准确率。
判断依据是采纳率，如果人工把系统建议改掉的比例超过 40%，也就是采纳率低于 60%，说明问题出在参数或数据口径上，先修数据再谈推广，不要急着怪系统不好用。有几类场景必须保留人工复核：新品首单、大促、高客单价商品、季节性商品和滞销清理。
选型阶段看的是平台覆盖、接口稳定性、采购审批流是否可配置、数据能不能完整导出以及退出成本，不要只看功能清单有多长。
读者评论
做运营的看完很有共鸣。7天、30天、90天三个销速口径我们公司也吵过，秒杀后按7天补货确实会多压一大批货。文章把统一用30天日均、再用趋势系数和促销系数修正这个做法讲得很实操，比空谈“打通数据”有用多了。
采购岗最怕的就是在途黑洞。系统里下了单就显示在途，运营看到就当货到了继续投广告，结果供应商没发货或者卡在清关，旺季直接断货。我们后来强制要求填供应商发货日和预计可售日，才算把这块补上，建议同行都查一下自己的在途字段拆得够不够细。
作为老板，最认同“先1-2个店铺加10-20个SKU试点4周”这条。我们之前一上来全店铺切换，参数设错导致好几个站点同时积压，返工成本远超试点。另外安全库存一定要按站点销速和交期分开设，共用一套参数基本等于主动制造断货和滞销。