达索系统云PLM案例（2）
一边是本地部署PLM的顽疾：版本升级滞后数年、IT运维成本高企、灾难恢复能力薄弱、跨地域协同效率低下，每一个都在拖慢企业创新的脚步。另一边是对云原生PLM的深层焦虑：核心研发IP的安全保障、主权数据的合规要求、与现有ERP系统的集成难度、定制化能力的缺失。
而在2026年3月，达索系统于波士顿举办的3DEXPERIENCE & ENOVIA全球用户大会上，一场汇聚了4家全球顶尖制造企业转型操盘手的圆桌对话，给了这个行业最真实、最硬核的答案。
这场名为《Transformation with 3DEXPERIENCE on Cloud》的创新圆桌，没有空泛的技术宣讲，没有营销话术的堆砌，只有来自一线操盘手的决策逻辑、踩坑经验、财务模型与落地细节。
从核聚变能源的国家级重大工程，到工业装备巨头的全价值链转型，从新能源汽车初创企业的从零搭建，到全球自动化巨头的全球化体系整合，4位嘉宾覆盖了制造业的全赛道。
这场圆桌对话，是2026 3DEXPERIENCE & ENOVIA全球用户大会的收官重磅环节。本届大会以“Supercharge Your PLM with AI-Powered Virtual Twin Experiences”为主题，汇聚了全球PLM与数字化转型领域的顶尖专家与企业决策者。
大会为期两天，从AI驱动的虚拟孪生技术落地，到PLM全价值链的数字化重构，从全球头部企业的转型实战，到达索系统最新的产品路线图与研发战略，全方位拆解了PLM行业的未来趋势。
而这场云转型圆桌，之所以成为全场焦点，核心在于它直面了企业最关心的“最后一公里”问题：当我们谈PLM云化时，我们到底在谈什么？企业究竟该如何落地？
本次圆桌的主持人，是达索系统ENOVIA全球行业流程高级总监Michael Mark。深耕PLM行业数十年的他，精准抓住了企业决策层的核心痛点，所有提问都直击本质，全程没有一句废话。
圆桌的四位重磅嘉宾，他们都是各自企业PLM云化转型的第一操盘手，手握最真实的项目数据与实战经验。
第二位嘉宾，是来自威猛公司的PLM系统分析经理Nick Martens。他在威猛公司已深耕超过12年，从大学实习生一路成长为企业PLM转型的核心负责人。
Nick亲历了企业从传统PDM体系，向3DEXPERIENCE云原生PLM全面转型的全过程，更经历了自然灾害倒逼企业重构数字化基础设施的关键节点，对云转型的业务价值有着最切身的理解。
Nick Martens：我们威猛公司的情况，是从传统的PDM体系，向完整的PLM体系升级。
在启动这个项目之前，我们公司其实并没有一套完整的PLM系统，只有面向设计环节的PDM体系，这套体系已经完全跟不上公司管理层的战略规划，也无法满足我们对客户的服务承诺。
我们的核心业务是工业装备制造，产品覆盖了从工程机械到农业机械的多个领域，产品的全生命周期管理，从设计、制造到运维，都需要一套完整的PLM体系来支撑。
而就在我们启动PLM选型的关键节点，一场龙卷风袭击了我们的工厂，直接摧毁了我们的两座生产厂房，也让我们本地部署的PDM系统，面临了前所未有的灾难恢复考验。
这场自然灾害，给我们的管理层和团队，上了最深刻的一课：本地部署的系统，在灾难面前的抗风险能力，远比我们想象的要薄弱得多，灾难恢复成了我们必须直面的生死问题。
也就是在这个时候，云原生的SaaS方案，从一开始的可选项，变成了我们的核心必选项。我们深刻意识到，我们必须摆脱对本地基础设施的强依赖，构建一套更具韧性的数字化架构。
除此之外，我们还有一个核心痛点：我们的本地PDM和SolidWorks系统，版本更新一直严重滞后，通常要落后官方发布版本三年之久，完全无法用上最新的功能和技术。
我们的管理层一直希望打造“移动优先”的数字化体系，让一线的工程师、生产人员、服务人员，能够随时随地访问产品数据，而本地部署的方案，根本无法满足这个需求。
正是这些核心的业务挑战，让我们在PLM选型的早期，就坚定了选择SaaS方案的方向，它不仅解决了我们当下的痛点，更支撑了公司未来长期的数字化战略。
对于我们威猛公司而言，版本升级的灵活性，也是我们选择SaaS方案的核心原因之一，这里我也补充一下我们的决策逻辑。
我们在传统PDM体系里，最大的痛点之一，就是版本升级的“牵一发而动全身”。每一次SolidWorks或者PDM的版本升级，都需要全公司所有团队同步完成，否则就会出现数据兼容问题。
这种全公司同步的大版本升级，不仅需要耗费数月的准备时间，还需要投入大量的人力做测试、做培训、做适配，稍有不慎就会影响正常的生产研发工作，风险极高。
也正是因为如此，我们的版本更新才会一直滞后三年之久，因为我们根本承担不起频繁升级带来的业务中断风险，也没有足够的资源去支撑这种大规模的升级动作。
而3DEXPERIENCE的SaaS方案，彻底打破了这个困局。我们可以根据不同业务团队的需求，分批次、分阶段地完成版本升级和功能启用，不需要全公司同步推进。
比如我们的新业务团队，可以直接启用最新的SolidWorks版本，用上最新的功能；而负责 legacy 项目的团队，可以继续沿用原有的版本，不需要做强制升级，两者之间完全不会出现数据兼容问题。
这种灵活的版本管理能力，是本地部署方案根本无法实现的，它让我们彻底摆脱了“为了升级而升级”的恶性循环，真正做到了“为了业务价值而升级”。
除此之外，云原生架构带来的灾难恢复能力，也是我们最终选择SaaS方案的核心决策因素，龙卷风事件给我们带来的教训，实在是太深刻了。
对于本地部署的系统而言，想要实现异地容灾、多活部署，需要投入成倍的资金和资源，搭建一套完整的备用机房和系统，对于我们这种中型企业而言，这个投入是难以承受的。
而3DEXPERIENCE的SaaS方案，天生就具备了多地域容灾、高可用的架构能力，我们不需要做任何额外的投入，就能获得企业级的灾难恢复保障，这一点直接击中了我们的核心痛点。
对于威猛公司这种传统制造企业而言，我们的财务论证模型，会比初创企业更加复杂，需要覆盖更多的维度，去说服管理层和财务部门，这里我分享一下我们的核心逻辑。
我们的财务论证模型，核心分为三个部分：可量化的成本节约、可量化的效率提升、不可量化的战略价值，我们没有只谈虚的战略价值，而是先把可量化的账算清楚。
首先是可量化的成本节约，我们做的第一件事，就是拆解了现有PDM体系的全量成本，包括硬件折旧、软件维保、IT运维团队的人力成本、版本升级的服务成本、灾难恢复的投入等。
我们发现，仅仅是把这些现有成本，替换成SaaS方案的订阅费用，我们在5年周期内，就能实现接近20%的成本节约，这是一个已经能够说服财务部门的基础数据。
然后是可量化的效率提升，这也是我们财务模型的核心部分，我们从多个业务环节，测算了SaaS方案带来的效率提升，以及对应的成本节约和收入增长。
比如研发环节，我们测算，通过版本的持续更新，工程师能够用上最新的设计工具和仿真能力，单个产品的研发周期，能够缩短15%，对应的研发人力成本节约，是非常可观的。
再比如供应链协同环节，通过云原生的PLM体系，我们和供应商的协同效率，能够提升30%，原材料的采购周期能够缩短，对应的库存成本和资金占用成本，都会有明显的下降。
还有生产和服务环节，通过“移动优先”的云平台，一线的生产人员和服务人员，能够随时随地访问产品数据，解决生产和现场服务中的问题，停机时间能够大幅缩短。
我们把这些所有可量化的效率提升，都换算成了具体的金额，放进了财务模型中，最终测算下来，项目的投资回报周期，不到3年，这对于制造企业而言，是一个非常有吸引力的数字。
最后是不可量化的战略价值，包括灾难恢复能力、业务韧性、未来的数字化转型支撑、全球化业务拓展的支撑等，这些内容，是用来打动公司高管层的核心内容。
我们的龙卷风事件，让管理层深刻意识到了业务韧性的重要性，而SaaS方案带来的高可用、高容灾能力，正是对公司长期经营风险的有效对冲，这一点，获得了管理层的高度认可。
最终，我们的财务模型，既有严谨的可量化数据支撑，又有清晰的战略价值阐述，顺利通过了管理层和董事会的审批，项目也得以快速启动。
我们威猛公司的集成实践目前还处在项目的早期落地阶段，核心的集成需求，就是PLM系统和我们的ERP系统的打通，这里我分享一下我们的实践和感受。
首先介绍一下我们的现状，我们用的ERP系统，是一个相对小众的行业化系统，可能在场的大多数人都没有听过，它的标准化集成能力，相对SAP、Oracle这些主流ERP，会弱很多。
在项目启动之初，我们最担心的问题，就是云原生的PLM系统，能不能和我们这个小众的ERP系统，完成稳定、高效的集成，这也是我们团队内部，对SaaS方案最大的顾虑之一。
而在实际的调研和测试中，我们发现，3DEXPERIENCE SaaS平台，提供了非常完善的Web Service API接口，能够让我们灵活地提取PLM系统中的产品数据、BOM数据、变更数据。
这些标准化的API接口，给我们的集成工作，提供了极大的灵活性，不管是什么样的ERP系统，只要它提供了数据接口，我们就能通过这些API，完成两个系统之间的数据打通。
当然，在实际的落地过程中，我们也遇到了挑战，这个挑战不是来自于PLM系统，而是来自于我们的ERP系统本身，它的接口能力和数据架构，还无法支撑和PLM系统的实时集成。
所以目前，我们采用了一个阶段性的集成方案：通过PLM系统的API，提取我们需要的产品数据和BOM数据，整理成标准化的Excel模板，再由用户手动导入到ERP系统中。
这是一个过渡性的方案，我们已经同步启动了ERP系统的升级项目，等ERP系统完成升级，具备了对应的接口能力，我们就会实现两个系统之间的全自动实时集成。
很多人都会问，云原生的PLM和ERP集成，是不是比本地部署更难？我的答案是，从技术层面来看，两者的集成难度，其实是基本相当的，没有本质的区别。
但从业务和战略层面来看，云原生的集成方案，反而有着更大的优势，它逼着我们去重新梳理我们的主数据模型，去规划我们未来二十年的数字化架构，而不是像以前一样，用定制化接口去掩盖数据架构的问题。
在本地部署的模式下，我们可以无限制地做定制化开发，不管ERP系统的数据架构有多乱，我们都能通过定制化接口，强行把数据打通，看起来解决了问题，实际上积累了大量的技术债务。
而在SaaS模式下，我们必须用标准化的方式去做集成，这就让我们必须从源头上去优化主数据模型，去规范业务流程，最终实现的集成方案，会更稳定、更高效，也更符合长期的数字化战略。
在本地部署的时代，我们的集成思路，是“适配现状”，不管我们的业务流程和数据模型有多乱，都通过定制化开发，让系统去适配我们的现状，最终的结果就是，集成方案越来越复杂，技术债务越来越重。
而在SaaS模式下，我们的集成思路，变成了“拥抱最佳实践”，我们会先梳理全球统一的主数据标准、业务流程规范，再基于这些标准和规范，去设计标准化的集成方案。
这种思路的转变，看起来前期需要投入更多的时间去做流程梳理和标准制定，但从长期来看，它让我们的集成方案，变得更简洁、更稳定、更易于维护，也彻底摆脱了技术债务的恶性循环。
更重要的是，这套标准化的集成架构，能够让我们在收购新的公司时，快速完成新业务的系统集成，极大地提升了并购整合的效率，这对于我们的全球化战略而言，是极其重要的价值。
我们威猛公司，虽然没有国家级工程那么严苛的合规要求，但作为美国的工业装备制造企业，我们同样面临着严格的出口管制要求、数据安全合规要求，这里我分享一下我们的实践。
在项目选型的初期，我们对云方案的核心安全顾虑，主要有两个方面：一是核心研发IP的保护问题，二是灾难恢复和业务连续性的保障问题。
首先是核心研发IP的保护，我们的产品设计数据，是公司最核心的知识产权，也是我们的核心竞争力，一旦出现泄露，会给公司带来毁灭性的打击。
在本地部署的时代，我们的安全逻辑，是“把门锁好”，把所有的数据，都放在公司内网里，通过防火墙，把外部的访问全部挡在外面，我们觉得，数据在自己的机房里，就是最安全的。
但龙卷风事件之后，我们意识到，这种安全逻辑，有一个致命的缺陷：它只能防范来自外部的网络攻击，却无法应对自然灾害、机房故障、硬件损坏等物理层面的风险。
更重要的是，随着我们的业务发展，越来越多的工程师需要远程办公，越来越多的供应商需要协同，我们不得不给内网开越来越多的访问入口，防火墙的防护效果，已经大打折扣。
而3DEXPERIENCE的SaaS平台，给我们提供了一套全新的安全逻辑：不是把数据锁在一个固定的地方，而是给数据本身，加上全生命周期的安全防护，不管数据在哪里，都能得到有效的保护。
平台提供的零信任架构，实现了“永不信任，始终验证”的安全逻辑，不管用户是在公司内网，还是在外部远程访问，都必须经过严格的多因素身份认证，才能获得对应的权限。
同时，平台还提供了精细化的数据权限管控，我们能够给不同的用户、不同的供应商，分配最小必要的数据访问权限，确保每个人只能看到自己工作需要的数据，从源头上降低了数据泄露的风险。
所有的用户操作，都有完整的日志审计，我们能够清晰地看到，谁在什么时间，访问了什么数据，做了什么操作，一旦出现异常行为，系统会自动触发告警，及时进行处置。
在灾难恢复和业务连续性方面，SaaS平台的多地域容灾架构，能够实现RPO=0，RTO<1小时，这是我们自己的本地机房，无论如何都无法实现的能力。
现在我们完全不用担心，自然灾害、机房故障会导致系统瘫痪，数据丢失，哪怕我们的工厂再遇到龙卷风，我们的工程师，在任何有网络的地方，都能继续工作，业务完全不会中断。
我可以非常明确地说，对于我们威猛公司而言，SaaS转型，极大地降低了我们的运营风险，这不是理论上的判断，而是我们已经亲身验证的事实。
我给大家举一个非常真实的例子，就在我们的平台刚刚上线的时候，我们就遇到了一个非常典型的场景，也让我们真切地感受到了SaaS方案，对运营风险的降低。
我们公司是SolidWorks的老用户，已经用了很多年，当时我们正在运行的，是SolidWorks 2023版本，而官方已经发布了SolidWorks 2025版本，其中有一个新的设计功能，是我们的研发团队急需的。
在传统的本地部署模式下，想要用上这个新功能，我们必须做全公司的SolidWorks版本大升级，这个升级，需要我们做至少3个月的准备工作，包括环境部署、兼容性测试、用户培训、集成适配等。
更重要的是，这个升级，需要我们全公司所有的团队，同步完成版本切换，一旦有一个环节出了问题，就会导致设计数据不兼容，影响正常的研发生产工作，风险极高。
也正是因为如此，我们过去的版本更新，才会一直滞后三年之久，因为我们根本承担不起这种全公司同步升级带来的运营风险。
而在SaaS模式下，我们完全不需要做这种全公司的强制升级。我们只需要给需要用到新功能的研发团队，开通SolidWorks 2025的使用权限，他们就能直接用上最新的功能。
而负责遗留项目的团队，完全可以继续使用SolidWorks 2023版本，不需要做任何的升级，两个版本之间的数据，在3DEXPERIENCE平台上，完全兼容，不会出现任何的问题。
这件事情，给我们的团队带来了极大的震撼，我们第一次意识到，原来软件版本升级，可以不用承担这么大的运营风险，可以这么灵活，这么简单。
除此之外，SaaS转型，还从多个维度，降低了我们的运营风险，包括灾难恢复的风险、IT团队人员流失的风险、系统运维的风险、版本滞后带来的技术落后风险等。
在本地部署的时代，我们的PLM系统，高度依赖于几个核心的IT工程师，他们熟悉系统的所有定制化开发和配置，一旦他们离职，整个系统的运维，都会面临极大的风险。
而在SaaS模式下，我们的系统，基于标准化的架构和最佳实践，不再依赖于特定的个人，哪怕团队人员有变动，新的人员也能快速接手，极大地降低了人员流失带来的运营风险。
很多人会觉得，把核心系统放在云上，会增加运营风险，但在我们的实际实践中，恰恰相反，SaaS转型，帮我们规避了绝大多数，在本地部署模式下，不得不面对的运营风险。
对于制造企业而言，最大的运营风险，从来都不是“数据不在自己的机房里”，而是系统无法稳定运行、版本持续落后、业务中断、数据丢失，而SaaS方案，恰恰完美解决了这些问题。
观众提问：您好，我是来自Joby Aviation的Jack Brown，我的问题是提给四位嘉宾的。我们公司，已经在本地部署的3DEXPERIENCE环境上，做了大量的投入，也有非常成熟的应用，现在很难做一次性的全面转型。
我想请问各位嘉宾，对于我们这种已经有成熟本地部署体系的企业，有没有什么渐进式的转型路径，能够让我们逐步地、平滑地向SaaS方案过渡，而不是一次性的大切换？
Nick Martens：这个问题，其实也是我们很多同行，都会面临的问题，我先分享一下我们的实践，因为我们也是从成熟的本地PDM体系，向SaaS方案过渡的，我们采用的，就是渐进式的转型路径。
我们的核心思路，就是“新老划断，逐步迁移”，对于新启动的研发项目，我们全部放到新的3DEXPERIENCE SaaS平台上，用全新的流程和体系来做；对于已经在进行的遗留项目，继续在原来的本地PDM系统里完成。
这样的模式，就避免了一次性的全量迁移，带来的业务中断风险，我们不需要让所有的团队、所有的项目，在同一个时间点，完成切换，而是可以分项目、分团队，逐步地向SaaS平台过渡。
同时，我们在新平台上，先从最核心的BOM管理、变更管理流程入手，先把核心的业务流程跑通，验证成功之后，再逐步把更多的业务场景，迁移到新平台上，实现平滑的过渡。
在这个过程中，我们还做了新旧系统之间的接口打通，实现了两个系统之间的数据同步，确保在过渡期间，两个系统的数据是一致的，不会影响正常的业务协同。
这种渐进式的转型路径，风险极低，不会影响正常的业务运营，还能让我们在试点的过程中，积累经验，优化方案，让用户逐步适应新的系统和流程，最终实现全面的转型。
页:
[1]