这不是某一家企业的故事。
而是很多研发制造企业，在过去十多年里，真实走过的一条路。
系统一套一套地上，
平台一轮一轮地换，
投入一次比一次大，
周期一次比一次长。
从最早的信息化立项开始，
到标准 ERP、PLM、自研 MES、再到顶级 ERP 与顶级 PLM 全部跑完，
前后横跨了十多年。
期间的直接与间接投入，
早已超过多数企业对"信息化成本"的想象。
但问题，却始终没有消失，
只是一次次换了表现形式。
阶段一
第一次信息化会议，开在会议室里。
那一年，企业正处在高速扩张阶段。
订单增长很快，
产品复杂度迅速上升，
靠人工和 Excel 已经明显支撑不住。
会议主题很明确：
把企业的经营数据管清楚。
目标被反复强调了几次：
库存要清楚，
成本要算得出来，
利润要看得见。
ERP 很快被确定下来。
方案是一套成熟的标准方案，
覆盖采购、库存、生产、成本，一步到位。
会上，顾问在白板上画了一条清晰的逻辑链：
研发 BOM → 产品 BOM → 成本 → 利润。
逻辑很直观，也足够"标准"。
但企业当时的真实状态是：
产品由几万个零件组成，
一套 BOM 通常在 8 层以上，
设计和变更几乎贯穿整个项目周期。
很多项目，
并不是"设计完再生产"，
而是在边设计、边生产、边调整。
系统上线后，流程跑得很顺。
BOM 能导入，单据能生成，
表面上看，一切都在按计划推进。
直到第一次正式跑 MRP。
计划任务在晚上启动，
第二天上午还没结束。
MRP 一次运算，跑了十几个小时。
结果出来后，没人敢直接用。
采购清单需要反复人工调整，
生产计划频繁被推翻，
设计一旦变更，整套数据就要重新计算。
项目推进一段时间后，
生产、计划、成本模块逐步被"绕开"。
ERP 还在用，
但只剩下最基础、最安全的功能。
最终，这套 ERP 的落脚点，
变成了进销存 + 财务记账。
上线没有官宣失败。
但所有人都心里清楚：
最初想要的那套
"算利润、控项目"的目标，
并没有真正实现。
阶段二
ERP 项目受挫之后，
管理层开始把注意力拉回源头。
几次复盘下来，结论越来越一致：
BOM 是核心。
既然 BOM 来自研发，
那就先把研发管住。
PLM 被引入，目标也很明确：
图纸集中，
版本受控，
BOM 准确。
项目初期，看起来一切都在向好的方向走。
文件开始统一进系统，
版本号被要求规范填写，
研发过程第一次被系统化记录。
但真正的问题，很快暴露出来。
文件并不唯一。
历史资料长期积累下来，
同一个零件、同一个图号，
在不同项目、不同文件夹中反复出现。
名字是一样的，
内容却完全不同。
现场开始频繁出现这样的情况：
同时存在多个"20 版本"，内容各不相同；
早期版本仍在老项目中持续使用；
更新版本已经在新项目里并行推进。
这些文件都是真的，
也都曾在各自的业务场景中
被"合理地使用过"。
PLM 可以强制一个文件夹里的文件唯一，
却无法否定历史项目中已经存在的现实。
为了不影响进度，
复制、另存、并行修改，
仍然在发生。
BOM 开始变得微妙起来。
结构看起来是完整的，
但每一层引用的到底是哪一个版本，
已经很难说清。
生产和计划逐渐形成共识：
PLM 里的 BOM，
依然不能直接用。
项目推进到后期，
PLM 的使用范围开始明显收缩。
复杂 BOM 的维护被绕开，
系统中被严格执行、真正稳定下来的，
只剩下一件事：
文档集中管理，文件名唯一。
最终，这套 PLM 并没有成为"BOM 的核心系统"，
而是退化成了一个
文档归档与唯一性控制工具。
阶段三
PLM 没能真正解决 BOM 问题之后，
方向再次发生变化。
这一次，结论很直接：
标准产品已经覆盖不了我们的复杂度。
既然买来的系统解决不了，
那就自己做。
一个自研 MES 项目被立项。
最初的目标很大，也很明确：
不只是补生产执行，
而是一步到位，
替代 ERP 和 PLM 在制造端的核心能力。
项目启动后，投入迅速加码。
开发团队规模很快扩大到百人级别，
既有业务骨干，
也有专职研发人员。
系统模块一个个被做出来：
车间管理，
工序管理，
委外加工，
质量检验。
从功能清单上看，
已经具备制造系统的完整轮廓。
在局部场景里，自研 MES 确实解决了一些问题。
车间能用，
委外能管，
质量数据也能录。
但问题始终存在，而且越来越明显。
系统之间依然是割裂的。
PLM 的数据进不来，
ERP 的计划接不上，
MES 里的执行结果，也回不到源头。
为了保证生产不断，
大量历史做法被原样保留下来。
原来用 Excel 的地方，
只是换成了一个界面。
老旧的 Excel 表，
被一张一张搬进了自研 MES。
字段没变，
逻辑没变，
流程没变。
只是多了一个"系统入口"。
到后来，现场最熟悉的操作依然是：
填表、导出、再填表。
项目持续推进，
人员持续投入，
系统功能持续增加。
但最终的实际效果却越来越清晰：
这套自研 MES，
并没有打通 ERP、PLM 和现场，
而是变成了一个
车间层面的记账工具。
百人级的产品开发，
最终交付的，
只是------
"有界面的 Excel 表"。
阶段四
自研 MES 推进到瓶颈之后，
企业内部再次做出调整。
CIO 更换了。
新 CIO 上任后，
很快给出了判断：
问题不在执行层，
也不在研发能力，
而在 ERP 产品本身。
原来的 ERP，
被定义为"能力不够"。
要解决复杂研发制造的问题，
必须切换到真正的顶级 ERP 平台。
决定很快被拍板。
企业投入了远高于以往的预算，
切换到国际一线 ERP 平台。
实施路径依然是标准的：
ERP 作为核心，
PLM 提供研发数据，
项目模块管理项目，
MES 负责车间执行。
从架构图上看，
这是教科书级的信息化蓝图。
项目初期，一切显得非常"正确"。
流程被重新梳理，
主数据被重新建模，
会议密度明显提高。
项目模块被寄予厚望。
项目被拆解，
成本被归集，
研发过程被期望通过项目结构来承载。
但真正跑起来之后，
问题再次出现。
研发 BOM 依然是动态的。
结构在变，
版本在变，
同一个项目在不同阶段，
呈现出完全不同的形态。
项目模块可以管理项目，
却无法替代一个稳定的产品结构。
当 BOM 本身无法冻结时，
计划、成本和执行，
就无法真正闭环。
一段时间后，
系统开始出现熟悉的迹象。
核心模块被绕开，
复杂流程被简化，
数据逐步回退到"能用就行"。
最终，这套顶级 ERP 的实际使用形态，
回到了一个似曾相识的状态：
ERP 只承担进销存与财务记账，
MES 继续作为车间层面的记账工具存在。
阶段五
在顶级 ERP 上线一段时间之后，
问题并没有消失。
系统稳定了，
流程规范了，
但核心业务依然跑不起来。
企业内部再次调整。
CIO 再次更换。
新 CIO 上任后，并没有急着动系统。
他花了一段时间，
把 ERP、MES、PLM、3D 设计工具，
一项一项拆开来看。
结论比之前更"高级"，
也更接近真相：
问题不在 ERP。
顶级 ERP 跑不起来，
是被前端的 PLM 限制住了。
在他的判断里，逻辑是完整且自洽的：
ERP 已经是行业顶级；
ERP 的能力发挥，依赖稳定的产品结构；
稳定的产品结构，只能来自顶级 PLM；
顶级 PLM，必须深度绑定顶级 3D 设计软件。
只有这样，
研发 BOM 才能从模型、参数和规则中自然生成，
并最终被 ERP 接住。
方向被重新定义。
这一次，不再是"补系统"，
而是"补前端能力"。
新的 PLM 被重新评估，
更高阶的 3D 设计工具被纳入规划。
从架构图上看，
这是一套真正意义上的"终局方案"。
但现实很快给出了答案。
企业的设计与交付周期极短。
项目节奏快，
交付压力大。
设计人员最关心的，
依然是：
能不能按时出图，
能不能按时交付。
顶级 3D 软件的复杂能力，
需要长期投入、方法论沉淀和组织配合。
在现实节奏下，
这件事根本推进不下去。
结果是：
3D 软件并没有真正用起来，
PLM 的高级能力也失去了依托。
没有稳定的模型，
没有可复用的结构，
PLM 只能继续停留在
文档和简单结构管理层面。
最终，这一轮尝试也没有走通。
系统的实际运行状态，
再次回到了熟悉的起点：
顶级 ERP 只承担进销存与财务记账，
项目模块存在，但越来越鸡肋，
MES 继续作为车间层面的记账工具，
PLM 退化为 PDM 文档管理系统。
总结
回头看这十多年的信息化历程，很容易产生一种错觉：
好像每一步判断都没有错。
ERP 是行业主流，
PLM 是研发必需，
自研 MES 是复杂制造的现实选择，
顶级 ERP 与顶级 PLM 在方法论上也无可挑剔。
系统一套比一套高级，
平台一次比一次"正确"，
投入、决心、组织力度都从未缺席。
但真正的问题在于：
每一次调整，解决的都是"当前最显眼的痛点"，
却始终回避了同一个底层前提。
当研发过程本身是动态的，
当 BOM 在项目周期内持续变化，
当多个"合法版本"同时服务不同业务场景时，
系统真正需要承接的，
并不是一个静态、唯一、冻结的结果。
而是一个长期变化中的工程事实。
只要这个前提没有被正面面对，
ERP 就只能被迫退回进销存，
项目模块就只能停留在形式上，
MES 就只能承担现场记账，
PLM 也只能退化为文档管理。
系统不是没用，
投入也不是白花。
它们只是被用在了一个
并不匹配其假设前提的业务现实中。
所以，这并不是某一家企业的教训，
也不是某个系统或某个 CIO 的失误。
而是一类研发制造企业，
在快速交付与持续变更的现实压力下，
反复经历的一次次信息化"轮回"。
在真正想清楚之前，
数据应该以什么形态存在，
系统才能真正接住它，
这条路，
大概率还会被继续重复走下去。