鬼斧神工119计划部主管在会上把一叠缺料报表拍在桌上，声音明显压着火："研发这周出了三个版本的变更，BOM 还没冻结，系统跑出来的需求单我根本不敢发给采购。再这么下去，这套系统就只能当摆设了。"这句话我在不同制造业企业里听过太多次，每次听到都觉得可惜——系统本身没有大毛病，卡点往往出在一个默认前提上：BOM 必须稳定。
BOM 是物料清单，是制造系统里最核心的数据文件。从研发设计、物料采购到生产领料，几乎所有业务都要围绕它转。传统的计划系统，无论叫 MRP、ERP 还是高级排产，绝大多数都假设 BOM 是稳定、准确、唯一的。一旦这个前提不成立，系统就会产生大量不可信的输出，于是业务人员只能回归 Excel 和个人经验。
问题的真正解法，不是用更强的手段把 BOM"摁住"让它不变，而是接受一个事实：产品快速迭代和供应链波动的年代，BOM 不可能长期不变。我们要设计一套不需要 BOM 绝对稳定、也能持续产出可靠指令的计划机制。这篇文章就从原理讲到落地，把我实践过的思路完整展开，也把过程中的坑一并交代清楚。
1. 为什么大多数计划系统都栽在"BOM 必须稳定"这个默认设定上
1.1 计划系统自带一套"确定性假设"，只是平时没人说破
主流计划系统的计算逻辑基本一致：拿到销售预测或订单，根据产品的 BOM 逐层向下展开，算每种原材料和零部件的毛需求，再扣掉库存和在途，形成净需求和采购建议。这个过程依赖三个公式化的前提条件：
- 一颗物料只有一个编码，且编码是唯一确定的；
- 物料清单中每个父子件关系、用量、损耗率，都是准确且当前有效的；
- 产品要生产什么，系统里对应的 BOM 就是什么，不存在"可能变"的状态。
这三个条件在物料标准化程度高、设计变更少的成熟行业里完全成立。比如生产一颗规格非常固定的螺丝，BOM 可以三年不改，系统跑出来的采购计划也就非常精确。但放到消费电子、汽车零部件、定制设备这类快速变化的行业里，三条前提几乎同时被打破。最要命的是，业务人员并不一定知道这套假设的存在，他们只直观地体会到：系统今天算出来的需求，明天就会被一张新 BOM 推翻，自然没人敢按系统执行。
1.2 现实世界的 BOM 变更，比多数人想象的更频繁
我在制造企业里观察到的 BOM 变化，主要来自四个方向。第一个是需求端，客户对功能和配置的要求不断调整，今天要加一个通信接口，明天要换一个外观颜色；第二个是研发端，为了降本、提性能，工程师一直在做物料选型优化，每一次选型变化都意味着 BOM 要更新；第三个是供应端，一颗电容、一款芯片说停产就停产，或者原材料交期突然从 4 周变成 20 周，物料替代被迫发生；第四个是工艺端，试产时发现原设计装配干涉，现场必须通过工程变更才能继续生产。
这四类变化叠加下来，处于导入期或快速迭代期的产品，BOM 每周甚至每天都会变。不少企业只用 Excel 管 BOM，各版本散布在工程师电脑里，计划部门甚至没有一个版本能确认"到底以哪个为准"。在这样一片混乱背后，传统计划系统却依然用确定性模型去处理，最终产出的报表只能被搁置。
1.3 稳定假设越严格，系统越容易成为业务瓶颈
也许有人觉得，这个问题可以通过换一套更强、更贵的软件来解决。但实际项目中，我常看到企业投入大量资源整理 BOM 数据、规范版本流程，导入新系统后效果依然不理想。原因在于，系统被设计成"必须等到完美输入才能运行"：研发没定稿，计划就停摆。BOM 反而成了整个流程中最脆弱的瓶颈点，而软件本身没有提供任何吸收不确定性的缓冲机制。
计划系统的职责从来不只是计算，更是在不确定条件下持续给出"足够好"的行动建议。如果不能接受这一点，再精细的算法也只会放大错误。反过来，如果从设计上