90% PLM项目为什么普遍达不到预期？

       一个PLM从业20年工作者的行业观察

       从事PLM相关技术工作二十多年，我见证了国内制造业PLM从概念导入、大规模招标到普及落地的完整历程。见过数千万投入、周期数年的大型PLM工程，也见过预算有限、小团队推进的敏捷数字化尝试。

       行业里流传“90%PLM项目失败”的说法，严格来讲，90%并不是经过严谨统计的精确数字，更多是一线从业者的体感归纳：真正能够实现产品数据唯一可信源、深度支撑研发业务的项目占比并不高；大量项目可以完成合同验收，但业务价值并未真正释放。

       大量项目，要么上线之后业务不深度使用，退化为高级文档库；要么流程跑通，但BOM、变更、基线等核心产品数据仍然割裂；系统验收文档很漂亮，一线研发、工艺、制造并不信赖系统内数据。

       很多人归因：甲方执行力不足、乙方实施能力欠缺、PLM软件功能不够强大。但二十多年过去，软件能力、实施团队水平、企业数字化意识都在持续提升，PLM项目业务不达预期的现象并没有明显改观。究其根源，或许我们长期找错了解决问题的方向。
一、一个高度典型的PLM项目启动场景

       还原绝大多数主机厂、装备企业的项目启动会现场：

       甲方CIO在会上宣讲：“通过PLM平台建设，实现产品数据统一管理、业务流程标准化流转，支撑企业数字化转型战略。”

       乙方实施方同步展示实施方案：项目覆盖文档管理、BOM管理、变更管理、流程审批、权限管理等12大模块，分三期建设，整体实施周期18个月。

       参会各方达成共识，项目正式启动。但剥开表面共识，中间存在巨大认知鸿沟：

       甲方想要“产品数据统一管理”，但并未明确：统一的标准是什么？BOM管控颗粒度如何界定？变更触发边界是什么？哪一个角色对产品数据正确性承担主体责任？

       乙方交付“软件模块功能”，但没有前置定义：哪些文档纳入PLM管控范围？哪些变更必须走构型变更流程？权限层级如何匹配型号研制分工？

       甲乙双方看似在沟通同一件事，实际处在两套完全不同的话语体系，还误以为彼此达成一致。

       十多个月后，系统按期上线，流程可以流转，模块全部配置完成。但业务部门实际使用后发现：历史数据依旧大量沉淀在Excel、本地文件夹，图纸依靠邮件传递。PLM更多承担审批载体，没有成为产品数据的核心底座。

       业务部门反馈：“系统不好用，数据不准。”

       IT部门反馈：“业务没有严格执行规范。”

       最终项目验收报告写明：已完成合同约定功能开发与上线，满足验收条件。

       项目归档，对外标记为“已完成PLM建设项目”，但数字化真正价值并未落地。
二、核心根因：PLM实践中，把“管理”拆成了“管”和“理”两件事

       在大量PLM项目当中，产品数据管理，我们可以管理说文解字，从两个维度看一下PLM的项目实施：

       “管”：系统层面的管控

       管理文档存储、审批流程、账号权限、对象版本。

       这一部分是PLM软件功能性的能力，实施阶段配置即可落地。绝大多数项目，“管”这一环都可以做得很好，系统跑得通，流程走得动，权限配得全。

       “理”：业务层面的数据治理

       梳理产品BOM架构、界定变更分级规则、定义各类基线建立/冻结/升版条件、厘清构型项划分、明确数据归属与责任主体。

       这才是研发业务真正需要的内核，但绝大多数PLM实施项目，前置没有完成“理”的工作。
       很多项目相当于修好了一条高速公路：路面宽阔、照明完备、收费站齐全，但是没有车道划分、没有交通标识、没有通行限速规则。道路硬件再好，依旧会拥堵、会碰撞。

       这就是很多PLM项目的现实：软件功能全部就绪，产品数据依旧混乱，业务价值无从谈起。

三、缺失“理”，带来三大致命业务后果

       后果一：业务不信赖PLM系统数据，系统沦为摆设

       PLM库内存在BOM，但BOM与现场实物不一致；图纸存在系统，但不是最新生效版本；变更有记录，但变更结果没有同步EBOM/MBOM。

       业务人员初次核对发现数据错误，多次遇到偏差之后，就会放弃以PLM作为数据源，继续沿用自己维护的Excel、本地图纸。即便不规范，但至少贴合现场实际，系统慢慢变成仅供归档走流程的工具。

       后果二：PLM变成审批流程工具，没有成为产品唯一可信源

       PLM的定位应当是全企业产品数据唯一可信源。现实当中，设计输出一套数据、工艺制造使用另一套BOM、售后备件维护第三套数据，多套数据并行，互相没有一致性约束。

       每一次设计变更，依靠人工通知、线下核对、口头同步，极易出现漏改、错改，为型号研制埋下质量隐患。

       后果三：型号追溯、合规审查变成“考古式工作”

       航空航天、高端装备属于强合规行业。出现质量问题需要回溯型号当时的基线状态：使用哪版BOM、哪版图纸、零部件的变更履历。

       如果缺少构型基线、完整变更追溯链路，追溯工作只能依靠翻旧邮件、找老员工回忆、翻阅零散纸质资料，效率极低，同时带来重大合规风险。
四、为什么多数项目不愿意做、做不好“理”这件事？

       根本差异：“管”可以标准化，“理”无法直接标准化。

       “管”（软件功能）存在通用参考范式：文档存储、权限模型、流程模板，厂商已经沉淀成熟方案，实施顾问按模板配置即可。报价、范围、验收指标清晰，方便签合同。

       “理”（业务数据治理）没有通用标准答案。不同企业的型号特点、构型复杂度、组织分工、研制流程完全不一样。需要深度扎根业务，梳理型号全生命周期，输出适配企业自身的规则体系。

       “管”售卖的是软件功能，可量化、好交付、容易验收。

       “理”输出的是业务规则、数据标准、构型管理制度，看不见摸不着，很多甲方难以感知它的价值，不愿意为此单独投入预算。

       市场趋利之下，大量项目优先选择简单路径：上线软件、配置模块、跑通流程。等到系统交付，才暴露核心问题：功能齐全，数据无序。

五、僵局来自系统性的认知缺失

       甲方视角：我们熟悉研制业务，但不懂PLM平台，实施方应当给出业务解决方案。

       乙方视角：我们负责软件落地配置，产品业务规则应当由甲方业务部门输出。

       双方互相观望，最终“理”这一环悬空，没有人完整承接。

       这不是简单甲乙双方互相推诿，属于行业系统性方法论缺失。过去二十年行业普遍把PLM建设等同于软件系统建设，默认重心放在功能配置，忽视了PLM的内核是产品数据秩序，软件只是载体。大家都在旧认知框架下开展项目，自然很难跳出困局。
六、破局路径：先“理”后“管”，以构型管理补齐数据治理

       PLM项目突破口不在于继续叠加软件功能，而在于前置完成产品数据治理规则设计。

       项目正式配置系统之前，必须把下面业务问题回答清楚，形成制度、标准、表单：

       1.产品哪些层级需要定义构型项CI，哪些节点需要独立版本与基线管控？

       2.变更如何分级，ECR/ECN分别适用什么场景，变更如何联动BOM、图纸、工艺数据？

       3.功能基线、分配基线、产品基线如何建立、冻结、发布、升版？

       4.CBB通用模块如何界定，平台与型号实例数据如何区分管理？

       5.每一类产品数据的创建、审核、发布、变更的责任主体是谁？

       以上问题，软件本身不能给出答案，属于业务规则设计范畴。

       而构型管理，就是解决这一类问题成熟完整的方法论（适配GJB3206A航空航天型号研制要求）。

       构型管理不是一套新软件，它相当于产品数据领域的“交通法规”。

       它就是PLM从单纯“系统管控”走向“业务治理”的桥梁，也是释放PLM真实业务价值的钥匙。

       先理清楚数据秩序，系统工具才能发挥价值；业务规则落地到位，研发、工艺、制造才会真正信赖PLM的数据。

七、行业呼吁

       PLM项目达不到预期，不能简单归因为甲方执行力弱、乙方实施能力不足，也不全是软件功能短板。

       根源在于行业长期存在认知错位：过度聚焦软件功能配置，轻视前置的产品数据治理。

       建议后续复杂型号PLM项目，坚持先理业务规则，再做系统实施。把构型管理、数据标准、基线变更体系作为项目前置输入，再开展软件模块配置。顺序理顺，项目的业务成效才会本质提升。
       整个PLM行业需要一次认知升级：我们建设PLM，目标不只是上线一套软件系统，而是搭建一套可信、可追溯、面向型号全生命周期的产品数据秩序。

       高比例项目业务不达预期，不应该成为行业默认的常态。

       作者简介

       李建军，25年西门子数字化PLM/构型管理领域资深专家，深耕高端装备、半导体、人形机器人行业，专注产品架构、BOM标准化、基线与变更管控，具备大量工业客户咨询实施经验，研究方向聚焦制造企业数字化转型、平台化产品数据治理。

       李恒，CM2认证构型管理讲师，本文联合作者；长期从事CM2构型管理标准、需求管理、工程变更体系培训，面向航空航天、动力装备、智能机器人行业输出实操方法论，推动构型管理体系在国内制造企业落地。