如果你同时打开运营后台、采购的Excel和仓库系统，看到同一个SKU有三个不同的可售数字，先别急着骂ERP不好用。我做过十几家跨境电商卖家的库存诊断，几乎每一次"库存对不上"的现场，问题都不在系统同步速度上，而在一个更前置的地方：这家公司从来没有定义过"库存"到底指什么状态。运营说的库存是"平台还能卖多少"，采购说的是"我还能发多少"，仓库说的是"我货架上还有多少"，三个数字都没错，只是它们回答的是三个不同的问题。
这篇文章不讲ERP功能清单，也不讲"多平台多店铺自动同步"这种听起来正确但落不了地的话。我想讲的是：跨境场景下，库存管理真正对应的是供应链协同机制的设计，状态口径怎么统一、节点责任怎么划分、异常由谁按什么规则处理、用什么指标验证机制有没有生效。看完之后，你应该能判断自己公司当前卡在哪一层，以及下一步该先动哪个地方。
先把结论摆出来，后面所有内容都是围绕这三句话展开的。
第一，库存不是一个数，是一组状态。在跨境链路里，同一个SKU至少同时存在可售、已锁定、在途、待检、不良、平台预留、FBA在库、FBA在途、海外仓可用等十几种状态。所谓"库存不准"，九成情况不是数字错了，而是你把两种不同状态的数字放在一起比了。
第二，协同不是同步，是规则。同步只解决"数据能不能传过来"，协同解决的是"当数据出现冲突时，谁按什么优先级做决策"。多平台超卖之所以反复发生，不是因为没有同步，而是因为没有定义清楚各平台库存的分配优先级和锁定规则。
第三，ERP不是万能药，是规则承载系统。ERP能承载你已经想清楚的规则，但它不会替你想规则。我见过太多卖家把ERP当成"装上就能协同"的魔法盒，结果上线三个月后，所有决策还是回到微信群里靠人喊。
去年Q2我参与过一次库存对账复盘。一个做家居收纳品类的卖家，主推SKU在亚马逊、TikTok Shop和独立站三个渠道同时销售，国内仓备货、一部分走FBA、一部分走第三方海外仓。复盘当天，三个部门给出的可售库存分别是：运营口径820件、采购口径1150件、仓库口径1340件。
差异从哪来？运营的820件已经扣掉了三个平台未发货订单的锁定库存；采购的1150件包含了正在头程运输、预计12天后到仓的那批货；仓库的1340件是货架实数，但里面混着120件外箱破损待质检的货。三个数字各自内部逻辑自洽，问题在于公司没有一份统一的"库存状态字典"来说明这些差异是设计出来的，还是错误造成的。
这种场景在跨境卖家里太普遍了。国内电商相对好管，因为链路短、状态少。跨境链路一拉长，状态就指数级增加，而大部分团队的管理颗粒度还停留在国内电商时代。
很多人第一反应是："那就把同步频率提高到实时不就行了？"这个思路在单平台单仓场景下勉强成立，在跨境多平台场景下会直接失效。
原因很简单：跨境的库存延迟不只是技术延迟，还有物理延迟。一批货从国内仓发出到海外仓上架，中间的物理时间可能是15到45天，这段时间里它既不是"国内可用"，也不是"海外可用"，它处于一个独立状态。你把平台API同步做到秒级，也改变不了这批货在物理上还没有到达可售位置的事实。
更麻烦的是平台侧的规则差异。不同平台对库存扣减的时机、预留的释放条件、超卖后的惩罚机制都不一样。有的平台下单即锁定，有的支付成功才锁定，有的还有"预留窗口期"。如果你只做单向同步而不做状态映射，系统里的数字反而会变得更混乱。
我通常用一个类比跟客户解释ERP的定位：ERP像是交通规则手册加上路口的信号灯，但它不是司机。它能把"哪些货优先给哪个平台""超卖时先砍哪张单""安全库存按什么维度算"这些规则固化下来，让所有人按同一套逻辑走。但规则本身得由业务方定，系统只负责执行和不走样。
这个定位想清楚之后，选型逻辑就变了。你不再问"这个ERP有多少个功能模块"，而是问"它能不能表达我的库存状态、能不能承载我的分配规则、能不能留下可追溯的处理记录"。前一个问题比拼功能数量，后一个问题比拼数据模型和权限设计，后者才是真正拉开差距的地方。
要设计协同机制，先得把链路看清楚。我把跨境电商的库存链路拆成七个节点，每个节点的库存状态、责任归属和常见异常都不一样。很多团队出问题，是把这七个节点混成一句话叫"库存"，然后指望一个数字管住全部。
这个节点对应的是"已下单未交货"。状态包括已下采购单、供应商备货中、供应商已发货、到国内仓待入库。这里的库存是"未来可用"的货，它的准确性取决于供应商交期和采购跟单质量。
我见过的最典型问题是采购把"供应商口头承诺的产能"当成在途库存录入系统。结果补货计划基于一个虚数做决策，等发现供应商实际交期延后20天时，海外仓已经断货了。我的判断是：供应商未发货的货，最多只能标记为"预计可用"，绝不能计入任何自动补货的可售池。
国内仓的核心矛盾是"到货数量"和"可用数量"之间的差。到货1000件，质检后可用可能是960件，剩下的40件是破损、色差、标签错误等待处理品。如果系统里只有一个总数，这40件就会一直躺在可售池里，直到发到海外仓才发现发不出去。
这个节点的协同责任在仓库和质检，关键动作是入库即分离状态：质检完成后立刻把货拆成可用、待处理、退货三部分，而不是等到月底盘点才分。
头程是跨境库存里最容易被低估的一段。货已经离开国内仓，还没到海外仓，这段时间里它既不在国内可用，也不在海外可用。海派、空派、铁路、快船的时效差异可以从7天拉到45天，而这段时效直接决定了你的补货提前期。
我建议在这个节点上至少细分四个状态：已交仓、已开船/已起飞、清关中、已到目的港待提。海运最容易踩的坑是清关延误，很多卖家在系统里把"已到港"和"已可提"当成同一件事，结果海外仓计划排了七天的入库量，货实际卡在海关两周。
这是离消费者最近的一层，也是状态最复杂的一层。海外仓有可用、锁定、待上架、破损；FBA有可售、待入库、预留、不可售、在途。这些状态在平台后台各有各的叫法，如果你不在ERP里做统一的映射层，运营就得同时看三四个后台才能判断能卖多少。
这个节点的协同难点在于：同一批货在海外仓和FBA之间是可以调拨的。当一个SKU在FBA快断货、海外仓还有余量时，要不要发补货？补货周期是3天还是7天？这个决策需要同时看到两个仓的库存状态和时效参数。
平台侧的状态是最动态的。消费者下单即产生锁定，支付失败锁定会释放，取消订单也要释放。如果你的ERP只从平台拉"可售数"而不拉"锁定数"，那你在做多平台分配时就会反复踩坑。
我的经验是：多平台库存分配必须基于"物理可售总量 − 全平台已锁定总量"这个净值来做，而不是简单地把同一个数字同步给所有平台。否则两个平台同时卖最后10件，超卖几乎是必然的。
订单生成到实际发货之间有窗口期。这段时间里库存已经被锁定，但还没有物理出库。如果发货延迟超过平台时限，可能触发取消，库存需要回滚。这个回滚动作如果不自动化，就会出现"货没发出去、库存也没还回来"的黑洞。
退货是跨境库存里最容易被忽略的节点，也是最容易产生账实不符的地方。退回的货可能回到FBA、回到海外仓、也可能直接弃置。判定为可再售的货要重新入可用池，判定为不可售的要转不良品，这个过程如果没有系统记录，退货就会变成库存差异的主要来源之一。
我做过一次退货专项盘点，某卖家一个月退回的货里，有超过三成在系统里状态不明，既没被计入可售，也没被计入不良，就那样悬着。这部分"幽灵库存"会让补货计划持续偏保守，间接推高缺货率。
下面这五个误区，是我在做库存诊断时出现频率最高的。它们有个共同特征：听起来都对，但落地方式错了。
很多ERP项目立项时的目标写的是"实现多平台库存实时同步"。这个目标最大的问题在于，它可交付但不可验证效果。同步上线了，超卖还是会发生，因为超卖的根源是分配规则，不是同步速度。
我的建议是把目标改写成业务语言，比如"把多平台超卖率从X%降到Y%以内""把库存准确率做到Z%以上"。这样项目结束时有明确的验收标准，也不会出现"系统上线了但没人觉得有用"的尴尬。
安全库存的本质是对不确定性的缓冲。不同SKU的销量波动、交期波动、平台规则都不一样，用同一个安全库存天数去覆盖全店，等于用同一把尺子量所有东西。
我见过一个卖家把安全库存统一设成30天，结果爆款该备货的时候不够，滞销款该清的时候堆了一堆。真正合理的做法是按销量分层、按交期分层、按生命周期分层，这三层至少要分开。
系统上线只是把规则的执行搬到了线上，规则本身不会因为上线而自动变好。我在多个项目里观察到同一个现象：ERP上线前存在的口径分歧，上线后会变成系统里的"数据质量问题"，而且更难被察觉，因为大家会默认系统是对的。
所以上线前后必须配套做两件事：一是把库存状态字典写下来，所有部门对照统一定义；二是明确每个节点的责任人，系统报警时由谁处理、在多长时间内处理完。
"我们现在有多少库存？"这个问题在跨境场景下几乎无法直接回答。正确的问法是"国内仓可用多少、头程在途多少、海外仓可用多少、FBA可售多少、当前被锁定了多少"。把总数当成决策依据，是超卖和断货的共同源头。
靠人盯异常的团队，规模小的时候还能撑住，一旦SKU数量和平台数量上去，就会失效。因为人的注意力是有限的，而库存异常是每天都会产生的。
我的判断是：凡是每天都会发生、且处理逻辑相对固定的异常，都应该变成系统里的规则，比如缺货预警阈值、超卖拦截规则、在途超期提醒。人只处理规则覆盖不到的长尾情况。
讲完问题，讲方法。我把库存协同拆成四层：口径层、责任层、异常层、指标层。这四层是有顺序的，跳过前一层直接做后一层，基本都会返工。
口径层的产出物是一份库存状态字典。它要定义清楚：每种状态叫什么、由谁产生、在什么条件下进入和退出、是否计入可售。
我通常建议客户至少定义这十一种状态：国内仓可用、国内仓待检、国内仓不良、采购在途、头程在途、清关中、海外仓可用、海外仓待上架、FBA在途、FBA可售、平台锁定。每种状态都要写明"是否计入补货可用量"。
这一层做不扎实，后面三层全是空转。我见过太多团队在会议上争论库存数字，其实争论的是口径，但谁都没意识到。
责任层的核心原则是：每个库存状态必须有唯一责任人，且这个责任人要在规定时限内对它负责。
举个具体例子：头程在途这个状态的责任人是物流专员，他需要在货物到港后24小时内更新状态为"已到港待提"，如果超过预计到港时间48小时仍未更新，系统应该自动提醒他。这样库存状态就不是"系统里的一个数字"，而是一个有人在盯的动态对象。
异常层的产出物是一份异常处理清单。清单要包含四个要素：触发条件、责任角色、处理动作、处理时限。这四个要素缺任何一个，异常处理就会变成扯皮。
我建议先覆盖六类高频异常：多平台超卖、爆款断货、在途超期、库存账实不符、退货积压、滞销库存超标。这六类处理顺了，日常运营的80%库存问题就有了标准答案。
指标层最容易犯的错误是盯单点数据。今天库存周转率是4.2还是4.5，本身说明不了什么。真正有判断价值的是趋势和口径一致的对比：这个月比上月是变好了还是变差了，同类SKU之间差距在哪。
我通常建议客户盯五个指标：库存周转天数、缺货率、多平台超卖率、库存准确率、滞销库存占比。前三个反映运营效率，后两个反映管理质量。
讲完框架，讲一次具体的落地过程。这一段我以数跨境（https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）为例说明，原因是它在我接触过的跨境ERP里，对"库存状态"和"多平台分配规则"的表达相对贴近上面这套框架，配置过程能对应上具体的业务判断，而不是只能看到一堆功能菜单。
我选观察样本的标准有三条：一是能不能表达多平台、多仓、多状态的库存模型；二是订单和采购能不能在同一套主数据下对齐；三是配置过程是否可解释，也就是我能不能跟客户讲清楚"为什么要这么配"。
数跨境在这三条上表现比较均衡。它覆盖Amazon、Shopee、TikTok Shop、Temu、SHEIN、速卖通、eBay等主流平台，也支持独立站和自建站对接，这意味多平台库存池的配置场景是真实存在的，不是演示环境里的假设。
第一步是建主数据。SKU要和平台SKU对上映射关系，包括组合SKU的拆分逻辑。这一步最容易出问题的是组合装：一个组合SKU卖出去，实际要扣两个或多个单品库存。如果映射没做对，单品库存会被反复高估。
第二步是把仓库和库存状态配齐。国内仓、海外仓、FBA仓要分别建，每个仓下面设置可用的状态维度。这一步的产出物，实际就是我前面说的"库存状态字典"在系统里的落地版本。
第三步是配多平台库存分配规则。这里要做几个关键判断：各平台之间是共享库存池还是分配独立配额、同步频率是多少、超卖时优先保护哪个平台。
我的专业判断是：新品期建议共享库存池，成熟期建议关键平台独立配额。新品期销量不稳定，独立配额容易造成这个平台缺货、那个平台积压；成熟期爆款需求可预测，独立配额反而能防止一个平台的促销把另一个平台的常规订单挤爆。
补货这块，我一般不建议直接用"智能补货一键生成"作为最终决策，而是把它当成一个初稿生成器。系统算出来的建议量，要经过采购评审会的人为调整，原因是系统很难完整捕捉促销计划、供应商临时产能变化、平台政策调整这些非线性因素。
参数上我会按这个顺序配：先配销量参数（近7天、近30天加权）、再配交期参数（按物流方式分别设）、再配安全库存（按SKU分层）、最后配MOQ和装箱率约束。顺序错了会导致补货量算法在最后被装箱率大幅修正，失去参考意义。
下面是一段库存状态映射的字段结构示意，用来展示"状态口径"在系统里具体长什么样。这是我根据实际配置经验整理的示例结构，不是某家系统的原始接口文档。
{
"sku_code": "HM-CHR-001",
"warehouse_states": [
{
"warehouse_type": "domestic",
"state": "available",
"qty": 620,
"counted_in_replenishment": true,
"owner_role": "warehouse_keeper"
},
{
"warehouse_type": "domestic",
"state": "pending_qc",
"qty": 120,
"counted_in_replenishment": false,
"owner_role": "qc_inspector"
},
{
"warehouse_type": "first_leg",
"state": "in_transit",
"qty": 330,
"eta_days": 12,
"counted_in_replenishment": false,
"owner_role": "logistics_specialist"
},
{
"warehouse_type": "overseas",
"state": "available",
"qty": 96,
"counted_in_replenishment": true,
"owner_role": "overseas_ops"
},
{
"warehouse_type": "fba",
"state": "reserved",
"qty": 42,
"counted_in_replenishment": false,
"owner_role": "platform_ops"
}
],
"platform_locks": [
{ "platform": "amazon", "locked_qty": 18 },
{ "platform": "tiktok_shop", "locked_qty": 9 },
{ "platform": "shopify", "locked_qty": 4 }
],"sellable_net": 705
}
这个结构里最关键的两个字段是 counted_in_replenishment 和 owner_role。前者决定了这个状态参与不参与补货计算，后者决定了出问题时该找谁。很多ERP只暴露数量，不暴露这两个语义字段，结果就是运营拿到数据也不知道该怎么用。
下面这组数据来自我参与的一次脱敏复盘，样本是一家做家居品类的卖家，五个平台、三个仓、约400个活跃SKU，上线周期三个月。数据是我在复盘会上按公司内部统计口径整理的，属于情景观察数据，不代表行业平均水平。
库存准确率从上线前的78%提升到93%。这个提升主要来自状态拆分，而不是盘点频率增加。多平台超卖率从每月平均2.1%降到0.4%，关键动作是把共享库存池改成"物理可售总量减去全平台锁定"的净额分配。
缺货率（爆款断货天数占比）从11%降到5.5%，主要来自补货提前期参数的重新校准，把海运清关延误从平均5天修正到12天后，补货触发点提前了。
最意外的改善是人工对账耗时，从每月约36人时降到9人时。原因是状态责任人明确之后，异常在对账之前就被处理掉了，月底不再需要集中排查。
框架讲完了，但不同规模的团队该从哪里开始，答案是不一样的。下面按四个典型阶段分别给建议。
这个阶段不建议上复杂ERP。你最大的风险不是超卖，而是把时间花在系统配置上而忽略了选品和listing优化。
建议动作只有三个：一是用表格维护一份SKU级库存台账，包含可用、在途、锁定三列；二是每周固定一次核对平台后台和台账的差异；三是把安全库存设成一个明确天数，先简单粗暴，但要写下来。
这个阶段的核心目标是建立记录的肌肉记忆，而不是追求系统化。
这是最容易出问题的阶段。平台数量上来了，靠表格已经管不住，但团队规模还没到能养专职供应链的程度。
建议动作：一是先把库存状态字典写出来，哪怕只有六种状态，也要全员统一；二是上ERP，重点配置多平台库存分配规则和SKU映射；三是建立每日异常巡检，固定15分钟，只看超卖、缺货、在途超期三类。
这个阶段我最想强调的一点是：不要试图一次性把所有平台都接进来。先接贡献80%销售额的两个平台，跑通流程后再扩，失败成本会低很多。
这个阶段库存协同已经变成一个独立职能，需要专人负责。链路长、状态多，任何手工环节都会成为瓶颈。
建议动作：一是设库存主管岗，对库存准确率和周转指标直接负责；二是把补货评审变成固定节奏的会议机制，每周一次，有数据、有决策记录；三是把FBA和海外仓之间的调拨规则写清楚，包括触发条件和时效预估。
这个阶段还应该开始做生命周期分层管理：把SKU分成新品、成长期、成熟期、衰退期，不同阶段的补货策略和清仓阈值都不一样。
这个阶段的团队往往已经有自研系统或深度定制的ERP。此时最大的风险不是功能不够，而是多套系统之间的口径分裂。自研系统、采购的ERP、平台后台、财务系统各有一套库存数字，时间越久越难对齐。
我的建议是不要追求把系统合并，而是建立一层统一的主数据与口径层：定义谁是库存数量的唯一事实来源，其他系统都从它取数。这层做起来不显眼，但它是后续所有数据分析的基础。
做库存协同，几乎每一个决定都是取舍，没有全都想要的选项。下面四组取舍是我在项目里被问得最多的。
想把库存准确率做到99%，通常意味着更严格的流程和更多的人工复核，代价是响应变慢。想做到秒级响应，就得接受一定比例的状态延迟。
我的判断标准是看品类：高客单价、低销量的品类应该优先准确性；低客单价、高销量的品类应该优先响应速度。前者错一次损失大，后者错一次影响小但频率高，容忍度更高。
统一口径便于管理，但平台之间确实存在规则差异，强行统一会损失一些平台特有的优化空间。
我的做法是分层：底层状态强制统一，上层策略允许差异化。比如"平台锁定"这个状态在所有平台都统一叫这个名字，但各个平台的锁定释放时长可以单独配。
全自动化效率高但风险集中，出一次错可能是批量的。全人工复核安全但规模上不去。
我建议按金额分层：低于某个金额阈值的动作自动执行，高于阈值的必须人工确认。比如常规补货自动生成采购建议，但单笔超过一定数量的采购单需要主管审批。
自研的优点是贴合业务，缺点是成本高、迭代慢、人才依赖强。采购现成系统的优点是上线快、有行业最佳实践沉淀，缺点是个性化需求响应慢。
我的一般建议是：除非你的业务模式确实独特到市面系统都覆盖不了，否则优先采购现成系统，把自研资源放在数据分析和运营决策上。库存管理是相对标准的领域，自研很难做出真正的差异化优势。
最后给一个可以立即启动的30天计划。这个计划是我在多个项目里验证过的版本，适合从阶段二往阶段三过渡的团队。
召集运营、采购、仓库、财务四个角色，用一次两小时的会议把库存状态定义清楚。产出物是一页纸的状态字典，包含状态名称、定义、责任人、是否计入补货可用量。
这一周不需要动系统。目标只有一个：让所有人用同一套语言讨论库存。
从日常最常出问题的场景里挑六个，逐个写处理流程。每个流程四个要素：触发条件、责任人、处理动作、处理时限。
这一周可以同步开始ERP的SKU映射和仓库配置，但不要急着开自动补货。
把多平台库存分配规则配好，确定是共享池还是独立配额。同时把五个核心指标做进看板：库存周转天数、缺货率、超卖率、库存准确率、滞销占比。
看板第一版不需要好看，能每天看到数字变化就够了。
用前三周的数据跑一次复盘，重点看两个东西：一是异常处理有没有按SOP走，二是补货参数是否需要校准。
这一步的价值在于把纸面规则变成团队的实际动作习惯。很多项目失败就失败在规则写了但没人用。
之后的第2个月开始进入迭代期，每月复盘一次，重点优化补货参数和异常阈值。
回到文章开头那个场景。三个部门报出三个库存数字，这件事本身不是错误，错误在于公司没有一套机制来解释这些差异。
我的核心观点是：跨境电商的库存管理，本质上是一次组织共识的建立过程，ERP只是把这个共识固化下来的载体。状态口径是共识的语言，节点责任是共识的分工，异常SOP是共识的执行方式，指标看板是共识的验证工具。这四样东西不具备，再贵的ERP也只是把混乱搬到了线上。
还有一个我想强调的判断：库存协同的收益曲线不是线性的，而是先慢后快。前两周统一口径和梳理SOP的时候，你不会看到任何指标改善，甚至会因为增加了流程而感到变麻烦。但第三周开始配置规则、第四周跑完第一次复盘之后，改善会集中释放，库存准确率、超卖率、人工对账耗时这几项通常会在一个月内出现明显变化。
至于下一步，我建议你现在就做三件事。
第一，把这篇里提到的十一种库存状态列出来，对照你公司当前的实际情况，看哪些状态你现在完全没有区分。缺得越多，说明库存协同的空间越大。
第二，找一次两小时的跨部门会议，只讨论一个问题：每个库存状态的责任人是谁。这个会议大概率会吵起来，而争吵本身就是价值，它说明过去这些责任从来没有被明确过。
第三，如果你已经在选型阶段，把评估重点从"功能有多少"转到"能不能表达我的库存状态、能不能承载我的分配规则、能不能留下可追溯的处理记录"。像数跨境这类支持多平台多仓状态配置、且能在同一套主数据下对齐订单与采购的系统，会更适合已经进入多平台阶段的团队；具体是否匹配，还是建议你带着自己真实的两三个SKU场景去做一次配置验证，比看功能清单有效得多。
库存协同这件事没有终点，它是一个持续校准的过程。但只要口径、责任、规则、指标这四层搭起来，你的库存数字就会从"每天争论的对象"变成"可以信赖的决策依据"。这个转变，比多接两个平台、多上两个功能模块，有价值得多。
我们做亚马逊加独立站，运营说可售还有100多，仓库实物盘出来只有87，ERP上又显示112，采购说还有200在途。每次开会光对数字就要吵半小时，后面补货、定价全都没法谈。我一度怀疑是ERP不准，甚至想退回用Excel手工维护。
先接受一个前提：库存不是一个数字，而是一组状态。必须先把字段拆开，至少区分实物库存、可用库存、锁定预占、在途、待检不良、平台预留（例如FBA的reserve）、不可售。统一口径走三步：第一，做字段字典，写明每个字段的数据来源（平台API拉取、物流回传还是人工录入）和更新频率；
第二，把计算式写死并落到文档，例如可用库存=实物−锁定−不良−平台预留，避免各角色自己心算；第三，指定唯一主数据源，一般以ERP为唯一账，平台后台只做校验。差异要有触发阈值，比如实物差异率超过2%或绝对值超过5件就开盘点，而不是每次靠感觉判断。
另外要注意平台扣减本身存在延迟，拉单间隔（常见5到15分钟）内的订单量必须计入预占，否则你看到的可售数天然偏高。
我把同一个爆款同时挂在亚马逊、TikTok Shop和独立站上，大促那晚两边同时出单，结果超卖被平台处罚、链接降权，销量掉了一大截。后来只能半夜起来手动改库存，改到凌晨三点，第二天还是出错。我就想知道有没有一套能长期用的分配规则。
不要用总量同步来防超卖，要用分配池加缓冲加拦截三层结构。第一层，按平台和店铺做库存分配池，用固定量或百分比切分，而不是把一个总数同步到所有渠道。第二层，每个池留安全缓冲，滞销SKU可以留5%到10%，爆款按近7天日均销量乘以1天的量预留，大促前单独上调。
第三层，在ERP侧加超卖拦截：下单先预占、付款成功再真正扣减，并对同一SKU的短时并发下单设阈值告警。判断标准要成对看，超卖率等于超卖订单数除以总订单数，缺货率等于缺货SKU天数除以总SKU天数，只降超卖必然推高缺货，两个指标一起评估才算有效。
最后把平台拉单延迟纳入模型，延迟窗口内的订单量算进预占，不要等拉回来才反应。
我们以前图省事，全店统一设30天安全库存，结果美国仓爆仓、东南亚仓天天断货，钱全压在卖不动的SKU上。后来想按仓拆开算，又不知道日均销量、交期这些参数到底该取哪一段数据。
不能全店一套参数，至少要按仓库、平台、SKU生命周期三个维度分层。补货点的思路是：日均销量乘以（采购交期+头程运输+清关+上架）的天数，再乘波动系数，加上安全库存；安全库存=日均销量×交期标准差×服务水平系数，服务水平按SKU分级，主推爆款给高系数，长尾款给低系数，不要一律拉满。
参数来源必须可追溯：日均销量用近7、14、30天加权，剔除大促异常日；交期用最近3到5批的实际到仓时间，而不是供应商承诺时间，两者差距往往很大；MOQ和时效按头程方式（空运、海运、海外仓调拨）分别维护。新品没有历史销量时，先用同类目均值或预售数据占位，跑满两个补货周期后再切换成真实参数。
关键是参数由谁维护、多久更新一次，建议月度复盘一次，大促前单独评审。
我们ERP上线快一年了，报表能拉出来几十张，可出了超卖或者断货还是互相甩锅：运营说采购没补，采购说运营没给预测，仓库说没人通知调拨。我想要一份能直接贴到墙上、谁在什么时间做什么的清单。
把协同拆成三个节奏加一张异常清单。日层面：库存专员核对当日差异，包括订单未扣减、超卖、缺货预警，产出一份差异日志，当天闭环。周层面：由供应链主管主持补货评审会，采购、运营、物流一起过补货点触发清单、调拨需求和滞销处理，产出补货单和调拨单，明确到SKU和到仓时间。
月层面：业务负责人复盘周转天数、滞销金额、缺货率、超卖率、履约时效，看趋势不看单点。异常清单要写清四件事：触发条件、责任人、处理时限、记录位置。比如超卖2小时内决定下架还是调拨、在途延迟超过3天自动升级、退货入库超过48小时未质检就告警。
判断依据很简单：每个指标必须有唯一责任人，没有责任人的指标等于没有指标。另外注意口径先于数字，同一个月度指标如果各角色算法不同，复盘会一定开成扯皮会，先把定义写进制度再开始考核。
读者评论
文章把库存差异拆成口径、在途、质检三类，这点说到根子上了。我们公司三个部门数字对不上，复盘后发现就是没定义状态字典，跟ERP同步速度没关系。
库存状态字典和分配优先级确实比同步频率重要，但落地难点在于让采购和仓库愿意按同一口径录数据，制度不改，换什么系统都白搭。
七节点漏斗那个图挺直观，全链路损耗接近10%，我们清关环节卡得最久，以前把这些都算成库存，补货计划一直偏乐观。
退货逆向那段很真实，退回的货状态悬着不算可售也不算不良，补货就会偏保守，我们缺货率高就是因为这部分幽灵库存没清干净。