作品声明：个人观点、仅供参考
做过非标设备的人，大概都经历过这种崩溃。
产品BOM一层套一层，成品下面有部装，部装下面还有半成品，里面又混着共用件、替代料和工程变更。
PMC兴冲冲跑一次MRP，结果采购数量对不上，库存也对不上，最后只能抱着Excel重新算。
有人吐槽：多层BOM有这么难攻克吗？
3层以上BOM，到底难在哪？从算法角度看，多层BOM递归展开确实没有神秘色彩。
成品A需要B，B需要C，C需要D，程序沿着父子关系不断往下找，直到最底层物料。
递归不好用，可以用栈；数据量大，可以做物化路径、缓存、预计算。
所以，单纯讨论“能不能把BOM拆开”，答案很明确：能。
真正棘手的地方，在于拆开以后怎么算。
假设一台设备有8层BOM，某个半成品已经生产了60件，仓库还有20件，工程部昨天又把其中一个零件从X改成Y。
这时候系统要处理的可就不只是树形结构了。
它得知道哪些库存属于哪个层级，哪些半成品已经投产，哪些订单使用旧版本，哪些物料属于共用件，还得防止同一物料被重复计算。
所以，多层BOM的门槛从“递归算法”开始，最后落到了整个制造业务模型。
为什么台资、SAP在这块更稳？第一，产品基因不同。
台湾很多工业ERP长期服务电子、机械、装配、非标制造，多层BOM、MRP、工单、库存之间的关系，本身就是产品核心能力。
SAP等大型ERP长期围绕复杂制造建立完整的计划体系，BOM展开只是其中一个环节，还要和库存、订单、工艺、采购、生产计划持续联动。
如果一个系统最初解决的是财务核算，生产模块后来逐步补进去，面对复杂制造场景时，设计思路自然会出现差异。
第二，工业逻辑的积累很重要。
低阶码只是其中一个典型机制。
它可以帮助系统明确物料在BOM中的层级关系，让MRP按照合理顺序展开。再配合版本管理、虚件、替代料、共用件、在制品等规则，系统才能把一次简单的“树形遍历”，变成一次完整的制造需求计算。
所以有人说“多层级BOM，递归不行就用栈，再不行就物化路径”，技术上完全说得通。
问题在于，企业真正需要解决的，从来只有一个递归吗？
第三，数据质量和实施能力同样决定结果。
30年前的台资工厂，用COBOL写MRP，也照样会出现算不准的情况。
原因很现实：半成品库存不准、在制品没及时入账、工程变更没有同步、BOM维护错误，算法再漂亮也救不了脏数据。
这也解释了一个容易被忽略的现象：有些企业换了ERP，BOM问题依旧存在。
系统只是计算器，企业自己的业务规则、基础数据和管理流程，才是决定计算结果的重要变量。
BOM复杂，能不能让业务人员自己改？其实国内早已通过另一个方向实现了，把表格作为业务系统的操作入口，让熟悉业务的人参与系统搭建。
对于PMC、生产文员等人员来说，他们每天面对的就是物料、订单、库存、排产这些表格。
通过云表eversheet的无代码、画表格开发特性，业务人员可以根据企业自己的BOM结构搭建多层级业务表单和排产流程，不需要先学一套复杂编程语言。
BOM层级、明细结构、计算规则、流程变化，也可以跟着业务调整。
所以，云表Eversheet支持不限层级BOM，并不需要把它包装成什么神秘算法。
递归本身确实没有那么神奇。
真正有价值的，是把复杂的数据结构、业务公式、权限和流程，放进一个普通业务人员也能理解的表格开发环境里。
如果只看算法，多层BOM确实没有传说中那么高深。
真正拉开产品差距的，是一套系统能不能长期处理复杂制造现场。
这也是为什么有的企业面对5层、8层BOM依旧能运行，有的企业碰到复杂结构就开始反复导Excel。
技术难度是一层，工业业务积累又是一层，最后还有企业自己能不能驾驭系统这一层。
把这三层都做好，复杂BOM才能从“IT部门的难题”，变成生产现场每天都能正常使用的工具。
对此，你有什么不同的观点？
文 | eamon
