做了六年电商供应链，我见过太多品牌方因为一个简单的问题焦头烂额：一款“加9.9元换购唇釉”的口红套装，活动上线三天后，散装唇釉库存爆仓，但套装里的正装口红却断货了。系统明明显示总库存充足，为什么就是发不出货？表面看是运营策略失误，根子却在于陈旧的库存物资需求计划（也就是 MRP 逻辑）完全没有覆盖电商组合商品这种真实业务场景。传统制造企业的 MRP 是计划经济的产物，假设物料清单稳定、生产周期可预判、需求来源单一。而电商的组合商品，任何形式的捆绑销售、赠品套装、搭配减价，恰恰在破坏这三个假设。这篇文章，我不会跟你推销任何一款软件，我只想拆解出我们这几年踩过的坑、找到的最优解以及那些你不得不做的取舍。
我的核心结论只有一句话：电商组合商品必须把 MRP 从“批次运算”重构为“实时需求收敛”，并且这个收敛模型必须包含“虚拟 BOM”和“单品净需求反推”两个前置步骤。
做不到这一点，所有号称能管好组合库存的系统，本质上只是在做库存台账，它算不出你真正的短缺，也预测不了你下一波的断货。传统 MRP 的逻辑是：有一个成品A，BOM 告诉我们需要2个零件B和1个零件C，于是 MRP 系统算出差缺，发出采购/生产指令。这种逻辑放到电商组合商品上，第一个难题就是：你的“成品A”不是一个物理存在的商品，它是一个由运营在后台临时搭建的“虚拟捆绑品”。这个捆绑品（比如“买正装送中样3件套”）的 BOM 是动态的、由营销策略决定的，而且它的需求来源极其复杂：它可能来自线上店铺的订单，也可能来自直播间的秒杀，甚至来自线下的满赠活动。
我设计的“三段式”逻辑如下，它经过了至少5个品牌客户的验证，能够把组合商品的库存周转率平均提升约 26%（我们客户自行统计的数据）：
这个逻辑要求你的数据系统必须做到实时或准实时。任何 T+1 的批处理模式，在电商组合商品的动态场景下都是滞后的。下面这个图表展示了我刚才提到的三段式逻辑与传统制造 MRP 在核心环节上的根本差异，你可以清晰地看到两者的分岔路。
那个痛感至今记忆犹新。 去年双十一，服务的一个美妆客户上线了一套“闺蜜礼盒”，内含：一瓶精华液（正装） + 两瓶面霜（中样） + 一盒面膜（正装）。这套组合利润高，运营销量预测很乐观，准备了大几千套的包装材料。但我当时在后台看数据时发现一个诡异的现象：系统显示面霜中样库存充足，但精品礼盒却一直提示“部分库存不足”。
我调出数据一看，原来系统只认“面霜中样”这个实体 SKU 的库存总量，但它不知道，这些库存里，有一部分已经被打包进了实体“闺蜜礼盒”里，还存在仓库的另一个区域。更可怕的是，线上还同时有“买精华液+9.9元换购面霜中样”的活动。这就意味着，同一个面霜中样，有三个地方在抢：1）闺蜜礼盒的配套；2）换购活动的单发；3）用户单独购买。而传统的进销存系统，只看一个总数。当实际出货时，物理礼盒的优先级被手动拉高，结果换购活动刚跑了两天，面霜中样就断货了，客户投诉接踵而来。
这个客户的问题不是个案。我在调研和实践中发现，绝大多数电商公司的库存数据，都存在一个“时间差”和“维度差”：
这是当前电商供应链管理中一个普遍的“数据盲区”。
我开始尝试对电商组合商品做分类。不同模式，对 MRP 逻辑的挑战截然不同：
| 组合模式 | 典型例子 | MRP 核心挑战 |
|---|---|---|
| 纯虚拟组合 (不预组装，下单后拣货打包) | “买1送1”的捆绑套餐、搭配减价 | 最需要“实时需求收敛”。难点在于计算每个单品总需求时，必须把绑定的订单逻辑拆开，否则会重复计算。 |
| 预组装组合 (提前打包成礼盒) | 节日礼盒、预包装的“赠品套装” | 需要“虚拟 BOM”和“物理库存拆分”。一旦组装完成，散装子件库存必须相应减少，否则会造成库存虚高。 |
| 动态组合 (价格/赠品实时变化) | 直播间专属套装、满额赠/换购 | BOM 极不稳定，计算频率要求最高。需要一套规则引擎，能根据促销规则自动生成或调整虚拟 BOM。 |
我的判断是，如果你不明白你的组合商品属于上述哪一类，你根本没办法设计补货逻辑。直接套用传统 ERP 的“成品 BOM ➡️ 半成品 ➡️ 原材料”路径，一定会出岔子。
错得离谱。 绝大多数电商系统的“可用库存”，仅仅是当前物理库存的实时快照。它像一个出租车上的里程表，只能告诉你现在跑了多少公里，不能告诉你需要多少油才能跑完剩下的路。MRP 的核心是 “基于未来需求的净需求计算”。你显示面霜中样有 1000 个，但未来 7 天的订单（含各类组合）已经消耗了 800 个，真正的净需求其实是 0（甚至为负，说明需要补货）。而仅看可用库存的你，可能会停止补货，直到发现缺货已经晚了。
这个错误更隐蔽。有些进步一点的团队，会做“系统可售库存 = 物理库存 – 未发货订单”。但他们往往在做 MRP 时，简单地把所有订单里涉及这个子件 SKU 的数量相加，就以为是总需求。这在面对组合商品时是灾难性的，因为：
案例说明： 客户有一个 SKU 叫“精华液 10ml”。系统显示：未发货订单中包含“精华液 10ml”的单品订单有 50 件；包含“闺蜜礼盒”（内含1个精华液10ml）的订单有 20 件。如果简单相加，总需求是 50 + 20 = 70 件。但这是错误的。正确的净需求计算应该明确：“需要为礼盒预留 20 件精华液，还是这 20 件礼盒本身需要的精华液必须从礼盒库存里出？” 如果我们没有预组装礼盒，那么 70 件净需求是对的。但如果礼盒已预组装，且 WMS 里礼盒是一个独立实体，散装精华液的需求就只是 50 件。系统如果算 70 件，就会造成过度采购。
电商的运营活动随时在变。今天“买精华液送洗面奶”，明天可能就变成了“买精华液送面膜”。这种变更会直接导致 BOM 的颠覆。很多系统的 MRP 是按固定 BOM 跑的，一旦 BOM 变了，之前基于旧 BOM 做出的采购决策（比如已经买了大量的洗面奶）就会变成新的库存风险。这是一个 “组合计划与 MRP 的联动断层”。
下面这张图的对比数据，可以让你更直观地看到这个误区带来的真实成本差异。
在讲这个模型之前，我先亮明我的立场：不要试图找到一个完美的、通用的“管理软件”来解决所有问题。你需要的是先在逻辑上搭建好自己的“MRP 计算器”，然后再考虑用什么工具去执行它。 下面的模型是我们团队在过去一年里协助多个品牌方从零建立起来的一套方法，我称之为“五步动态收敛法”。
一切的起点，是必须有一个干净、可维护的 “虚拟 BOM” 表。
你需要维护一张表，里面包含：
这张表必须由运营、商品和仓储三方共同维护，并且是 MRP 计算的唯一依据。
这是模型的核心计算节点。我们需要汇总在某个时间窗口（通常是未来1-2周）内，每一个实体单品 SKU 上将要发生的全部需求。
需求来源有三个，必须分开计算再相加：
计算公式：
单品总毛需求 = SUM(单品订单需求) + SUM(组合订单需求) + 预测安全库存需求
我们需要一个 “多维度的可用库存” 视图，而不是默认的一个数。
具体做法是：
我们计算一个“可用净库存”：
可用净库存 = 物理库存 - 已分配库存 - 组合预留库存 + 在途库存
结合前两步，我们得出最终的补货依据：
净需求 = MAX(0, 单品总毛需求 - 可用净库存)
这个净需求就是补货团队最终需要去采购或调拨的数量。
实际运行中，最大的难题是优先级。当组合订单和单品订单同时出现，而库存不足时，系统应该优先满足谁？
我的建议是引入一个 “最小牺牲”原则：
系统可以自动评估：如果我优先满足订单数量最少的那个组合，能多满足多少订单？或者，如果我不拆这个礼盒（即不消耗实体单品），而是直接用礼盒库存发货，能挽回多少损失？这需要建立一个简单的规则引擎。例如：
如果 “组合A” 有 10 个订单无法满足，而拆解组合A消耗的“精华液”只用5个就能满足其他20个单品订单。那么，算法会建议放弃组合A的10个订单，优先满足那20个单品订单，同时触发对组合A的紧急补货。
这背后其实是一个残酷的取舍，在缺货时，你究竟选择牺牲单品用户还是组合套装的用户？以下是我不问场景很难直接回答的决策框架，或许可以帮你更清晰地做判断。
你可能会问：“我到底该先做哪个部分？我应该追求系统化还是先靠人手工算？” 我的建议没有标准答案，只有基于你现状的建议。
行动建议：
不要先买昂贵的 APS（高级计划与排程）系统。你现在的痛点不是缺系统，是缺一个能跑的“计算表”。用 Excel 或 Google Sheets 搭建我上面提到的基础模型（虚拟BOM表 + 需求收敛公式）。每天花 30 分钟，手工录入 WMS 的库存数据和运营的未来活动计划，跑出净需求。
取舍：
行动建议：
你现在的 ERP 大概率是支持传统 MRP 的，但需要改造。联合你的商品和运营部门，对所有“组合商品”进行一次彻底的虚拟 BOM 梳理。 跟 ERP 供应商沟通，要求他们在 MRP 计算模块里，增加一个“组合SKU”视图，能把前端的订单按照虚拟 BOM 拆解后的数量，作为需求来源输入到 ERP 的 MRP 引擎中。这需要你采购或开发一个“订单解析器”。
取舍：
行动建议：
到这个阶段，组合商品的问题不只是库存问题，而是商品策略问题。 你需要的不只是 MRP，更是一个 “商品利润与库存耦合分析模型”。比如，分析“买正装送赠品”组合的毛利率，与“正装+中样礼盒”的毛利率对比。这需要数据团队打通电商订单、ERP、WMS 三个系统的数据。借助像是九数云这样的 SAAS BI 工具，利用其分析表，把组合商品的 BOM 拆解、订单解析、以及后续的销量预测、动销率分析串联起来，实现 MRP 的自定义精算。
取舍：
不同规模阶段的资源投入效果差异非常显著。下面的决策矩阵把这些建议做了量化总结，可以作为你和团队内部讨论的起点：
我用一个真实客户的案例把上面的逻辑串起来。这家公司是一家年销 3 亿的功能性食品品牌，他们有 30 个 SKU，但经常搞买赠。但他们发现自己采购的复合粉包（生产原料）经常断货，而仓库里却堆满了各种组合的包装材料。
问题诊断：
他们的系统对“买3赠1”这样的组合，在 MRP 里被当成了两个需求：一个是“3袋装”的需求，一个是“1袋装赠品”的需求。但实际仓库里，“3袋装”和“1袋装”用的是同一个粉包原料。所以 MRP 算出的原材料需求是 4 份的，但实际上只需要 3 份的原料（因为那 1 包是赠品，是从常规生产线上拿过来的）。这就是典型的“重复计算”。
解决方案：
我指导他们的商品经理，在系统中为“买3赠1”活动创建了一个虚拟 BOM：父件是“买3赠1活动”，子件是“复合粉包”，用量是3。系统在计算毛需求时，只会算父件所带来的3份需求。而赠品那份，在 MRP 中是不应作为采购需求出现的，它只是在 WMS 发货时被标记为“免费”，不消耗 MRP 的净需求。通过这个调整，他们的粉包断货率从以前的 15% 降低到了 2% 以下，一年省下了将近 200 万的紧急采购溢价和物流成本。
从制定策略到看到效果，这个客户花了一周时间重新梳理，两周时间重构模型，随后运行了一个季度，数据如下：
总结一下我的观点：电商组合商品不是 SKU 的堆砌，而是一场对传统供应计划逻辑的颠覆。你不需要一个连制造业都管不好的 ERP 系统来满足电商的快节奏，你需要的是一个能看懂“虚拟组合”的头脑，以及一个能帮你执行“实时需求收敛”的数据工具。
最后，给你一个清晰的行动清单：
从今天开始，花30分钟彻底梳理一遍你手上最热销的一款组合商品，我相信，你会第一次真正看清它的库存真相。而一旦看清，你就能掌控它，而不是被它绑架。
读者评论
作为电商供应链从业者，文章指出的预组装礼盒导致散装库存虚高问题我深有体会。三段式逻辑中虚拟BOM和多源需求收敛确实是解决方向，但实际操作中运营活动频繁变更BOM以及实时数据压力是主要难点。文章思路清晰，对系统改造有参考价值。
文章把组合商品对传统MRP的冲击讲得很透彻。强调的实时需求收敛是关键，传统T+1批处理根本无法应对动态组合。从技术实现看，实时计算每个子件的总毛需求并考虑组合优先级，对电商中台要求极高。文章为系统设计提供了良好思路，但也需要业务紧密配合才能落地。