
🎯 2026 · 供应链产品经理训练营 · 库存同步专题
本文结论来自备课过程中的逻辑推演,不代表权威判断,欢迎有实战经验的朋友指正交流。
最近在整理训练营的课件,有一节叫「ERP 的三层库存体系与库存同步方案拆解」。内容我早就想好了,框架也画了,但在讲到「共享和独占」的时候卡住了。
不是不懂。是越讲越觉得哪里不对。
翻了好几本书,看了几篇行业文章,都有提到共享和独占,有的还配了图配了例子。但读完之后我还是说不清楚一件事:独占,到底是怎么独占的?它凭什么说「其他平台卖多卖少都不影响我」?
带着这个疑问去跟 AI 捋了一遍。聊完之后发现:这个不对劲不是我没理解对,而是这个概念本身,在大多数资料和 ERP 的实现里就没被说清楚过——有些产品所谓的「独占」,本质上根本不是独占。
这篇文章就是那次推演的过程和结论。
在讲独占和共享之前,先把场景搭起来,不然后面讲机制会没有感觉。
做多平台电商的商家,货在仓库里(自建仓或第三方仓),但消费者是在天猫、京东、抖音这些平台上下单的。这里有一个根本性问题:平台怎么知道这个商品还有多少可以卖?
如果平台不知道,就只能展示一个固定数字,或者干脆不控制库存。后果是什么?消费者看到有货下单了,仓库里没货,只能退款——超卖。偶尔一次还好,超卖多了就是差评、罚款、店铺降权。
所以商家需要把仓库的库存数量实时或接近实时地同步给各平台,让平台展示准确的可售数量。听起来很简单,但一旦涉及多个仓库、多个平台、多个 SKU,这就成了一个复杂工程问题。
共享和独占回答的就是:有一批货要分给多个平台卖,分配规则是什么?
库存在整个链路里不是只有一个数字,而是分三层管的。
第一层是仓库里的实物库存,WMS 管。这是最真实的数字——货架上有多少件 WMS 就记多少,入库加、出库减、盘点校正。
第二层是 ERP 的可分配库存。它不等于实物库存,因为实物库存里有一部分不能推给平台。这些不可分配的部分有几种常见的类型:
安全库存(Safety Stock):人为设置的保留量。不是真的缺货,是主动留出来的缓冲,防止库存同步延迟时来不及补充。这个术语在供应链领域有标准定义,各大教材和系统都普遍存在。
预占库存(也叫占用库存):订单已创建但还没出库,这部分被「预先占住」,不能再卖给别人。ERP 在算可分配量时要把它扣掉。不同系统叫法不同(预占/占用/软锁定),含义基本一致。
锁定库存:这个词在不同系统里差异最大——有的指活动专用库存(秒杀提前切出来的),有的指质检隔离货,有的和预占混用。本文做了合并处理,实际使用时得对照具体系统的定义。
把这些不可分配的部分扣掉,剩下的才是「可以分配给各个平台去卖」的库存。
第三层是推送给各电商平台的可售库存。天猫显示的库存数字、京东显示的库存数字都从这来——不是实物库存,是 ERP 按规则算好再推过去的数字。
共享和独占,处理的就是第二层到第三层的分配逻辑:ERP 手里有一批可分配库存,要推给多个平台,怎么推、推多少、推出去之后怎么更新。
在正式讨论之前,先看看市面上 ERP 产品和行业资料是怎么介绍的。
一个典型的配置界面(我参考的某款新零售 ERP)是这样描述的:
某 ERP 产品的库存分配配置说明(整理自产品截图)
总库存 = 独占库存 + 共享库存;分配优先级:独占库存 > 共享库存
- 独占:店铺独占一定比例的库存。重算逻辑:店铺的库存售完后,售卖库存按比例重新计算。
- 共享:多个店铺共享库存,售完后库存过低时会重算。重算逻辑:任意店铺的库存低于分配库存的 20% 时,触发重算。
- 独占比例之和不超过 100%,共享比例之和不超过 100%。
按这套规则,用一个具体数字走一遍。假设某 SKU 总库存 1000 件,三个店铺,配置如下:
第一步:初始分配。 独占优先级高,先从总库存切出来;剩余的进共享池,再按比例分给共享店铺。
| 分配层 | 计算逻辑 | 结果 |
|---|---|---|
| 独占(优先级1) | 1000 × 20% | ✅ 店铺A:200件 |
| 共享池 | 1000 − 200 = 800件 | 共享池:800件 |
| 店铺B(共享60%) | 800 × 60% | ✅ 店铺B:480件 |
| 店铺C(共享40%) | 800 × 40% | ✅ 店铺C:320件 |
到目前为止逻辑很清晰。独占的优先级高,先切完才轮到共享。
第二步:店铺 A(独占)卖了 200 件,售完,触发重算。 按产品说明,「店铺的库存售完,按比例重新计算」。此时总库存剩余 800 件:
| 分配层 | 计算逻辑 | 结果 | 变化 |
|---|---|---|---|
| 独占(优先级1) | 800 × 20% | ✅ 店铺A:160件 | 重新获得额度 |
| 共享池 | 800 − 160 = 640件 | 共享池:640件 | 池子缩小 |
| 店铺B(共享60%) | 640 × 60% | ⚠️ 店铺B:384件 | ↓ 从480降到384 |
| 店铺C(共享40%) | 640 × 40% | ⚠️ 店铺C:256件 | ↓ 从320降到256 |
问题来了:店铺 B 和 C 什么都没卖,但因为店铺 A 售完触发了重算,它们的可售数字跟着缩了。这是共享的特征——共享池内只要重算,所有共享店铺都会受影响。
再看店铺 A 的独占部分:第一轮 200,卖完重算拿到 160,再卖完重算又拿到更小的……
🤔 等一下——这个「独占」,真的在保护店铺 A 吗?
带着这个疑问,换一个更典型的三渠道场景,把问题推清楚。
假设某 SKU 可分配库存 1000 件,三个渠道:天猫、京东、抖音,配置「天猫独占 50%,京东独占 30%,抖音独占 20%」。
大多数 ERP 的实际执行逻辑不是把 500 件「切」给天猫锁死,而是:每次库存有变动,就用当时的实时总库存乘以比例,重新算出各渠道的推送数字。
把这个过程一轮轮拆开看。
第一轮:初始分配,没有任何销售发生。
| 渠道 | 配置比例 | 计算方式 | 推送数字 |
|---|---|---|---|
| 天猫 | 50% | 1000 × 50% | ✅ 500 件 |
| 京东 | 30% | 1000 × 30% | ✅ 300 件 |
| 抖音 | 20% | 1000 × 20% | ✅ 200 件 |
没问题。天猫看到 500 件,感觉很安心。
第二轮:天猫卖了 100 件。 订单回传 ERP,总库存从 1000 变成 900,触发重算:
| 渠道 | 配置比例 | 计算方式 | 推送数字 | 变化 |
|---|---|---|---|---|
| 天猫 | 50% | 900 × 50% | ⚠️ 450 件 | ↓ 少了50件 |
| 京东 | 30% | 900 × 30% | ⚠️ 270 件 | ↓ 少了30件(天猫卖的) |
| 抖音 | 20% | 900 × 20% | ⚠️ 180 件 | ↓ 少了20件(天猫卖的) |
京东和抖音什么都没卖,但可售数字跟着缩了。这是「独占」该有的表现?
第三轮:这次天猫什么都没卖,京东卖了 200 件。
| 渠道 | 配置比例 | 计算方式 | 推送数字 | 变化 |
|---|---|---|---|---|
| 天猫 | 50% | 800 × 50% | ⚠️ 400 件 | ↓ 少了100件(京东卖的) |
| 京东 | 30% | 800 × 30% | ⚠️ 240 件 | ↓ 少了60件 |
| 抖音 | 20% | 800 × 20% | ⚠️ 160 件 | ↓ 少了40件(京东卖的) |
天猫一件都没卖,可售数字从 500 降到了 400。 原因只是京东卖了货,总库存减少,重算之后天猫跟着缩。这和「独占——其他平台的销售不影响我」完全相反。
⚠️ 伪独占的本质: 「独占的比例」是固定的,但「独占的数量」随总库存变动一直在缩。不管自己卖还是别人卖,只要总库存减少,重算之后所有渠道的数字同步下降。这不是独占,这是比例固定的共享,只是换了个名字。
这张时序图里最关键的一步是 ERP 触发了全渠道重算——不管是哪个平台的订单导致出库,三个平台的推送数字都会跟着变。这是「共享」的特征,不是「独占」的特征。
理解了伪独占之后,真独占的条件就很清楚了,核心只有一条:
✅ 独占的额度,必须脱离实时重算。
ERP 一旦把 500 件的额度切给天猫,这 500 件就归天猫了。之后不管总库存怎么变、不管京东和抖音卖多少,都不影响天猫手里的这 500 件。天猫只消耗自己的额度,消耗多少就少多少,不会因为外部原因凭空缩水。
用对比表格最能看清楚两者的差异,同样是「京东卖了 200 件」之后:
❌ 伪独占(实时重算)
初始推送:500件
京东卖了 200 件后重算:
800 × 50% = 400件天猫什么都没卖,额度从 500 缩到了 400。系统没有在追踪「天猫还剩多少额度」,只是在用实时总库存重新乘以比例。
✅ 真独占(额度台账)
初始分配额度:500件(锁定)
京东卖了 200 件之后:
天猫台账:500件(不变)
ERP 维护一张「天猫额度台账」,记录分配了多少、消耗了多少、剩余多少。京东的销售不会写入这张台账,天猫的数字只因自己的销售而减少。
真独占需要系统额外维护一张渠道配额台账:记录每个渠道分配了多少额度,每次该渠道出库就在台账里扣减,不走全量重算。台账里的数字只有这几种情况会变动:
其他渠道的任何销售行为,都不会影响这张台账。
知道了真独占要什么,反过来就能理解为什么市面上大多数通用电商 SaaS ERP 没有实现它。
第一,实现复杂度不低。 比例重算只需要一个公式。真独占需要额外维护渠道配额台账,还要处理退货怎么回池、配额过期怎么回收、调整配额怎么平滑过渡——每个环节都要额外的设计和开发。
第二,库存利用率会变差。 独占额度一旦切出去锁死,如果天猫那 500 件卖不完,京东这边缺货了也补不了——这 500 件就是沉默库存,资金压在那里,周转不起来。对大多数商家来说,库存利用率是真实的经营压力,宁可接受一点超卖风险,也不能让库存大量闲置。
第三,SaaS 产品的服务边界决定了它会选简单方案。 通用 SaaS ERP 要服务几千几万个商家,产品设计要覆盖最广泛的场景。「比例共享 + 安全库存兜底」对大多数中小商家已经够用,做真独占的研发投入划不来。
所以市面上主流的电商 SaaS ERP 实际选择的是比例共享 + 安全库存控制超卖风险:给各渠道设固定比例,推出去的数字本身就打了折扣,再设一个库存下限,低于这个数就自动清零下架。这套组合不能真正解决超卖,但能把超卖概率压到业务可接受的范围内。
说明:以下场景判断来自逻辑推演,核心依据是「哪些场景对渠道隔离的需求强到值得承担真独占的实现成本和利用率损失」。不是引用自具体产品文档或行业报告,有实战经验的朋友如有出入欢迎讨论。
既然大多数场景用比例共享就够了,那真独占的价值在哪?推演下来,有几类场景是比例共享解决不了的:
⚡ 大促活动(秒杀、限时特卖)——活动开始前需要切出一批固定库存专门用于活动,不能被日常销售消耗。活动结束后没卖完的额度归还普通池。这里的「独占」是时间维度上的隔离——这批货,在这段时间内,只给这个活动用。这是真独占最经典、也最有可能在实际系统里被实现的场景。
📊 渠道有 KPI 保量承诺——某个旗舰店跟平台签了合同,要保证每天的可售量不低于某个数字。用比例共享,该渠道的数字会随总库存减少一直缩水,承诺兑现不了。这种情况必须给它一个不受其他渠道影响的固定额度。
💎 稀缺品或高单价商品——库存量本身就少,每一件都很贵重。这种场景下精细控制比库存利用率更重要,宁可某个渠道有一点沉默库存,也不能让多渠道同时超卖带来退款和信任损失。
🏆 有明确的渠道优先级——核心自营渠道或战略渠道优先保货,其他渠道用剩余共享池消化。「独占保底 + 共享消化余量」的混合结构,是品牌商做多渠道库存策略时比较常见的选择。
这几个场景有一个共同点:对「这批货只给这个渠道/活动用」有明确的业务需求,并且强到愿意承担真独占带来的系统复杂度和利用率损失。这是判断要不要上真独占的核心前提。
如果业务上没有强保量需求,放弃独占、做好比例共享,反而是更务实的选择。那比例共享怎么设计才相对合理?
核心公式只有一条:
各渠道推送量 =(实物库存 − 安全库存 − 预占库存)× 渠道比例 × 推送系数
推送量 = 可分配库存 × 渠道比例 × 推送系数推送系数是一个小于 1 的值,用来进一步压低推出去的数字,给并发窗口留余量。设 0.75 的话,就是可分配库存的 75% 才推出去,剩下 25% 作为缓冲。
在这个公式基础上,还需要几个配套机制来控制风险:
第一,阈值清零。 当某个渠道的推送数字低于设定阈值(比如 20 件),自动把该渠道的库存清零下架,防止临界状态下的并发超卖。这比「一直显示 3 件、2 件、1 件」要安全得多,最后几件的窗口期最容易出问题。
第二,控制重算频率。 不是每笔订单都立即重算全渠道,设置合理的触发间隔。一方面降低对平台接口的推送压力,另一方面减少数字频繁抖动对运营和消费者的干扰。
第三,大促期间单独处理。 日常的比例共享 + 安全水位已经够用,但大促期间并发量级完全不同。大促专场库存应该单独切出来管,走真独占逻辑,而不是依赖日常的共享方案。
用一个具体的数字走一遍:
| 参数 | 配置值 | 说明 |
|---|---|---|
| 实物库存 | 1000 件 | WMS 当前记录 |
| 安全库存 | 100 件 | 不推出去,留底 |
| 预占库存 | 100 件 | 已下单未出库 |
| 可分配库存 | 800 件 | 1000 − 100 − 100 |
| 推送系数 | 0.75 | 压 25% 缓冲并发 |
| 实际可推送 | 600 件 | 800 × 0.75,整除 |
| 天猫(50%) | 300 件 | 600 × 50% |
| 京东(30%) | 180 件 | 600 × 30% |
| 抖音(20%) | 120 件 | 600 × 20% |
| 合计验算 | 300 + 180 + 120 = 600 ✅ | 与可推送数吻合 |
| 清零阈值 | 各渠道低于 20 件时清零下架 | 防临界超卖 |
这套方案接受的是「只要总库存减少,各渠道数字都会跟着缩」的共享本质,做不到渠道完全隔离。但在大多数正常销售节奏下,它足够稳定,实现和维护成本也更低。选择这套方案,就是接受「利用率和简洁性」优先于「渠道完全隔离」的取舍。
这篇文章的核心结论只有一条:
你说的「独占」,是真的把库存切出去锁死了,还是只是比例固定的共享?
如果是后者,它保护不了你。它只是让你在超卖的时候,各个渠道按比例一起亏。
在给别人讲这块内容或者设计这块功能之前,先把这个问题想清楚:你的重算逻辑是什么?哪些事件会触发重算?独占渠道的额度是真的脱离重算链路了,还是只是比例配置的一个参数?
把这件事想清楚,才能在选 ERP、做系统设计、跟研发对需求的时候,真正知道自己在选什么、要什么。
本文结论来自备课过程中与 AI 的对话推演,我对电商 ERP 这块的研究不算深,整理出来主要是分享一个思考角度。如果有实战经验的朋友发现哪里不对,欢迎评论区来拍砖,我在这里等着。