一、项目背景
国家某权威部门明确提出要务实推进数字化软件自主可控，要求按照“已有国产软件坚决用，国内能研的加快研，短期难以替代的先引进后国产”的思路，逐步实现国产化替代。
航天某科研单位从2006年开始进行建设PDM系统的建设和应用。在2012年实现航天某科研单位各个厂所PDM版本的统一，形成以科研单位级PDM系统为中心的联邦式PDM系统架构。近几年航天某科研单位各厂所持续性的进行了基于PDM系统技术状态管理功能升级改造，航天某科研单位多个单位完成了大版本升级，三家设计所 Windchill升级到10.2版本，两家设计所升级到11.0版本，提高了产品设计和技术状态管理效率，但航天某科研单位还有较多的单位版本陈旧，五家设计所尚采用2011年实施的Windchill 9.1版本。
针对数字航天战略实施要求，为保障航天某科研单位数字化协同研发能力再上新台阶，支撑数字化系统工程建设，需要在原有航天某科研单位PDM系统能力基础上建设航天某科研单位PLM系统，构建装备体系模型、装备需求模型、数字样机模型（设计、制造、交付)、数字装备模型等模型的统一设计管理环境，建立各类模型库，支撑各类典型应用环境下模型的快速构建和应用,重点提升全科研单位整体协同研发能力、全型号总体分系统研发能力、全生命周期一体化协同能力。
1.1 现状分析
系统应用现状
航天某科研单位是我国航天领域建设和应用PDM系统最早的企业之一，三家设计所在21世纪初较早实施了PDM项目，开展了文档、模型、BOM等信息的电子化管理，积累了诸多经验，编制了相关的标准规范。
随着PDM系统在科研单位里应用的逐步扩大，单位与单位之间的协同管理需求越来越强烈。2012年实施了科研单位级PDM项目，同时，统一了科研单位内各单位的PDM系统及版本，将之前单独建设的各厂所PDM系统进行整合，建成了大型”联邦式”PDM系统，实现了各单位间基于PDM系统的协同设计与管理，实现了科研单位控型号在科研单位级的统一管控，满足了单位、型号、设计师等不同类型的需求，经过十余年的建设与应用，航天某科研单位PDM系统的建设规模、系统复杂性，应用绩效均处于国内前列。
Ø 功能应用现状
各厂所基于Windchill平台的产品结构、文档、工作流、可视化等基础管理功能，根据航天某科研单位航天产品研制业务流程深度定制PDM系统。具有完整的以产品结构树为核心的技术状态管理，全型号数字化归档管理，以及跨单位数据签审和收发管理等功能。产品结构树范围覆盖从系统级到零件级、元器级。PDM与MPM、ERP、TDM、档案、云雀、售后、onRoad等系统开展了集成应用，构建了支撑数字化管理、协同设计、智能制造、数字化保障等数据管理环境，形成组织、协调、控制和管理产品数字化技术状态管理模式；结合智云工具实现产品结构树、文档、更改、基线等系统信息的型号设计数据抽取和分析利用，支撑产品设计、生产等主题库建设。
1.2 建设必要性分析
1、 满足未来型号产品研制业务的要求
•
确保型号研制业务的连续性和可持续性发展；
•
支撑产品复杂性日益提高、节奏日益加快、质量可靠性要求更高等情况下的协同研制业务；
•
提供面向下一代高端装备快速敏捷研发和智能柔性制造的平台能力。
2、 满足国家工业软件国产化政策的要求
•
保障型号数据在国产自主可控平台下的安全和研制过程信息安全；
•
规避国外技术封锁带来的潜在供应链风险；
•
推动在工业软件支撑下的高端装备可持续快速发展。
•
满足航天某科研单位集中统筹管理的要求
•
科研单位级集中部署，统一管理编码、资源库、型号完整技术状态信息等；
•
各厂所通过多租户模式开展业务应用，个性化业务流程和应用可以在各自租户下实现；
•
基于微服务技术和数字主线技术，提供面向不同角色、不同场景的APP应用，增强敏捷化、智能化业务应用能力。
3、 满足当前各家PDM系统版本升级的要求
•
充分发挥新版本设计工具（Creo 6.0）能力，全面深化MBD技术应用的需要；
•
提升多专业协同和跨单位协同研制效率的需要（集成MBSE、CAE等工具，与其他科研单位协同）；
•
研制平台新能力扩展的需要（需求、模型管理、SBOM、MBOM等）；
•
提高现有PDM平台性能和应用体验的需要；
•
基于新技术革命支撑未来系统扩展，为实现智能研制夯实基础的需要（AI、DT、AR等）。
一、 实施过程
1.3 总体建设规划
航天某科研单位PLM系统建设路线分为四个阶段，前期验证阶段已经完成PLM系统基本平台的搭建以及需求管理、模型管理、Doors集成、Matlab集成基础功能的应用，后续三个阶段将逐步实现国产化PLM系统在航天某科研单位各下属单位的切换应用。
根据航天某科研单位PLM系统的整体建设路线思路，通过PLM系统建设将逐步实现航天某科研单位各各下属单位PLM系统的切换工作，转变现有航天某科研单位各各下属单位PDM系统的邦联式应用架构应用模式，逐步形成航天某科研单位PLM系统的微服务架构应用模式。
1) 一阶段主要工作
• 完善科研单位级统一平台
• 构建平台基础微服务
• 构建科研单位级通用微服务
• 构建厂所个性化微服务
• 科研单位本级PDM系统切换
• 某总体部PDM系统切换
2) 二阶段主要工作
• 平台优化完善
• 专用微服务
• 四家设计所PDM融合到科研单位级PLM平台
• 系统集成
3) 三阶段主要工作
• 平台持续改进
• 专用微服务
• 三家设计所PDM融合到科研单位级PLM平台
• 系统集成
1.4 一阶段实施计划
信息化系统实施是在实施方法学基础上结合国内用户的实际情况总结出来的，根据实施原则，信息化系统的实施一般分为如下宏观过程，这些宏观过程将覆盖从理解客户的业务过程和系统需求，到软件设计、构造、配置及维护该方案的整个生命周期，将信息化系统的综合功能与产品开发的所有过程相结合，将有利于关注客户的业务需求，优化信息化系统的所有潜能，让客户能够从他们的投资中得到最大的商业回报。
按照各宏观过程目标的不同，可以将这些宏观过程大体划分为五个阶段：项目启动阶段、系统分析阶段、系统设计阶段、系统实现、测试阶段、系统验收推广阶段。下面简单介绍各阶段要完成的工作：
项目启动阶段：建立项目章程和项目实施小组，明确项目计划，为项目实施确保项目管理的体系、项目中的协调、沟通与运作机制。召开项目启动会，由航天某科研单位领导完成对项目组织、计划的批准，对小组主要成员的任命、授权。
系统分析阶段：包括了对客户当前流程的调研与记录，未来流程（未来信息化系统支持的流程）的勾画，未来信息模型的归纳，功能流程模型的细化，权限规则的定义，接口需求的明确。本阶段完成之后，可以定义出精确的需求边界。
系统设计阶段：依据系统分析的成果，按照软件工程的思想，识别出所有解决方案部件或组件，以及这些组件或部件所实现的功能；分析系统需开发的功能以及开发工作量预估，并根据工作量修订项目计划；分析硬件系统架构设计，硬件的物理容量需求；进行接口设计，并提交相应设计报告；进行历史数据整理的方案的制定。本阶段完成之后，可以完成软件架构设计，确定详细规格。
系统实现、测试阶段：依据系统分析与系统设计的成果，组织用户进行开发培训，根据物理对象模型和二次开发说明，共同完成各类客户化代码的编写以及管理对象的定义、系统配置工作；并进行接口功能的实现。按照测试大纲，分层次的对系统及功能进行单元测试、功能测试、集成测试，并提交测试报告。本阶段完成之后，可以完成系统的软硬件配置和二次开发工作，完成项目组内部的集成测试和测试问题的整改，确认系统上线试运行的准备条件。
系统验收、推广阶段：完成数据迁移、安装、部署与优化，进行试运行并完成最终验收和系统上线。本阶段完成之后，可以完成较大规模的系统的试运行测试并不断对系统进行优化完善，准备系统正式上线运行的软硬件环境并进行历史数据迁移，发布系统运行相关规范制度，宣布系统正式上线运行，最终完成项目验收工作。
1.5 组织架构
项目决策组：为本项目之最高权责单位，由天圣华全资子公司凯锐科技及航天某科研单位高层管理人员共同组成；负责本项目的执行方向、原则的确立；主要时间点的决定，及项目经理无法决定的重大争议的裁决。提供高级管理层的支持，并负责决定项目验收。
项目管理组：由凯锐科技及航天某科研单位管理人员共同组成，双方负责项目的监督，提供项目执行时各项行政及技术支持，并调解参与项目人力资源的冲突，协调各部门合作。
项目经理：航天某科研单位和凯锐科技均需配备，负责项目实际的执行计划及控制，并调配参与项目的人力资源，确定详细工作内容，分派工作，进度追踪考核，技术问题解决，及项目成员间的沟通协调，并定期向监督委员会报告。
业务方案组：流程分析顾问：航天某科研单位与凯锐科技共同配备，能对现有的流程有清晰的了解，负责产品设计流程等的分析，并确定系统详细运行规格。
系统架构组：凯锐科技配备，确认系统分析结果的可行性，再根据系统分析结果，针对使用软件设计、配置系统。航天某科研单位配备相应的系统分析人员和系统设计人员。
开发配置组：航天某科研单位和凯锐科技均需配备，确认系统设计结果的可行性，再根据系统安装、配置系统，进行程序开发。负责系统实施完成后的系统安装，系统环境设定，系统权限规划，系统运作规范建立，系统维护管理，数据库维护管理。
实施工作组：实施工作组是项目的常设工作机构，除了有航天某科研单位的相关角色设置外，还有凯锐科技实施人员参加，在项目的整个寿命周期中，负责项目实施、方案设计、测试、项目支持和控制。
数据移植：航天某科研单位和凯锐科技均需配备，现有数据确认及格式转换、导入等工作。
系统测试组：航天某科研单位和凯锐科技均需配备，负责系统测试规范指定，测试资料准备，系统测试并产生测试记录（交叉）。航天某科研单位实施后的培训人员也包括在此组。
1.6 建设内容
1、 科研单位院级统一平台优化与完善
Ø 统一平台架构
• 基础层：提供服务器、网络环境等基础支撑能力；
• 数据层：通过数据库、文件存储、索引库、缓存库进行管理科研单位院级统一数据、各租户级数据和跨单位协同数据；
• 平台层：提供基础运行平台、基础服务支撑、通用应用服务、统一数据交换、统一集成框架等能力；
• 应用层：提供支撑型号全生命周期管理数据、信息、流程等的业务应用能力；
• 访问层：提供基于各类浏览器和设计工具进行访问应用的环境；
针对平台的优化完善
• 同时通过统一平台实现租户管理、人员管理、团队管理、组织管理、权限管理、属性管理、分类管理、生命周期管理、电子流程管理、三员管理、查询管理、菜单管理功能等通用能力。
2、 通用微服务构建
科研单位院级通用微服务是全科研单位各单位共同遵循的标准化、规范化应用模式下，统一定义的PLM各项业务能力。
科研单位院级通用微服务主要包含：文档管理、EBOM管理、PBOM管理、SBOM管理、审签流程管理、更改管理、基线管理、需求管理、模型管理、资源库管理、协同管理、编码管理、门户管理、系统集成接口、工具集成接口等微服务；
科研单位院级通用微服务应用模式：通用微服务定义在平台级，供各单位租户直接继承应用；同时，为各单位租户提供定制个性化微服务的能力，满足各单位差异化需求。
以文档管理微服务中的文档创建为例进行分析如下：包含创建入口、选择分类、填写名称、选择产品代号、填写编号、选择密级、其他属性、存放位置、基线控制、上载主要内容、上载附件、填写备注等。
3、 科研单位本级PDM系统替代
科研单位本级PDM系统升级与替代包含如下主要内容：
科研单位院级PDM租户建立
基于新一代PLM平台完善科研单位院级租户（ Windchill 9.1数据库与科研单位院级租户数据库结合），为科研单位院级用户提供统一应用门户；
通用微服务应用
科研单位院级租户能够继承和应用全部通用微服务，并可以基于此支撑型号研制管理业务；
三维设计管理
通过Windchill 9.1管理和存储三维设计相关的业务和数据；
数据存储管理
通过租户数据库管理三维之外的业务过程产生的数据，并将文档、变更等业务数据同步到Windchill 9.1数据库中；
Ø 统一索引管理
针对科研单位院级租户数据库和Windchill 9.1数据库建立统一索引，实现针对全部数据的统一查询检索、统计分析的能力；
全科研单位统一基础资源库管理
资源库构建：基于科研单位院级租户建立科研单位院级基础资源库，实现标准件库（基于WNC）、元器件库（PLM平台）以及电连接器库（基于WNC）的统一管理，实现与BDM系统的集成应用（BDM管理、PLM应用）；
资源库应用：科研单位院级资源库基础资源数据作为单一数据源，各厂所级租户通过“镜像”方式引用科研单位院级基础资源库的数据，供业务应用；
资源库数据规范化管理
当前问题：各单位基础资源数据不统一，存在同码不同物、同物不同码的情况；
引入统一物资编码，将物资编码赋码给所有基础资源模型数据，并用物资编码取代原有编号作为数据的唯一标识，无需处理数据。
4、 跨单位协同管理
通过科研单位PLM平台进行租户之间的协同管理模式
如某部与某公司之间的协同，通过协同流程直接进行跨租户之间的数据传输和流程衔接；协同数据无需物理转移，通过链接索引和流程授权实现业务协同应用；
科研单位PLM平台租户与原Windchill系统之间的协同管理模式
如某总体所与某设计所之间的协同，协同数据和流程在科研单位PLM平台中的X部租户和科研单位院级租户之间直接衔接无需物理传递数据，然后将数据和流程跨系统传递到某设计所的PDM系统中实现协同应用；
Ø 原Windchill系统之间的协同管理模式
如某设计所与某厂之间的协同，保持原有模式不变，即某设计所à科研单位系统à 某厂跨域协同；
Ø 跨科研单位协同模式
协同业务在某科研单位之外的部分与以往保持不变，协同业务在某科研单位内的部分参照上述各项描述。
5、 某总体部PDM系统替代
某总体部PDM系统替代包含如下主要内容：
Ø 某总体部PDM租户建立
基于新一代PLM平台建立某总体部租户（Windchill10.2数据库与某总体部租户数据库进行融合），为某总体部用户提供统一应用门户；
Ø 通用微服务应用
某总体部租户能够继承和应用全部通用微服务，并可以基于此支撑型号研制管理业务；
Ø 某总体部专用微服务构建
针对某总体部个性化专用业务需求，构建专用微服务能力；
Ø 三维设计管理
通过Windchill 10.2管理和存储三维设计相关的业务和数据；
Ø 系统集成
基于科研单位院级统一接口微服务进行调整、完善，实现某总体部PLM租户与其他业务系统的集成应用；
Ø 数据存储管理
通过租户数据库管理三维之外的业务过程产生的数据，并将文档、变更等业务数据同步到Windchill 10.2数据库中；
Ø 统一索引管理
针对某总体部租户数据库和Windchill 10.2数据库建立统一索引，实现针对全部数据的统一查询检索、统计分析的能力。
6、 某公司PDM系统建设包含如下主要内容：
Ø 某公司PDM租户建立
基于新一代PLM平台建立某公司租户（ 新建Windchill 11.0数据库与某公司租户数据库进行融合）， 为某公司用户提供统一应用门户；
Ø 通用微服务应用
某公司租户能够继承和应用全部通用微服务，并可以基于此支撑型号研制管理业务；
Ø 某公司专用微服务构建
针对某公司个性化专用业务需求，构建专用微服务能力；
Ø 三维设计管理
通过Windchill 11.0管理和存储三维设计相关的业务和数据；
Ø 系统集成
基于科研单位院级统一接口微服务进行调整、完善，实现某公司PLM租户与其他业务系统的集成应用；
Ø 数据存储管理
通过租户数据库管理三维之外的业务过程产生的数据，并将文档、变更等业务数据同步到Windchill 11.0数据库中；
Ø 统一索引管理
针对某公司租户数据库和Windchill 11.0数据库建立统一索引，实现针对全部数据的统一查询检索、统计分析的能力；
Ø 数据迁移
某公司业务数据从当前某总体部Windchill 10.2系统中进行剥离，并升级、迁移到某公司新Windchill 11.0系统中。
7、 需求结构化管理
需求结构化管理主要内容包括：
Ø 完善需求编制与分解功能
实现在PLM平台中进行需求定义和分解，包含对需求项所包含的各类属性描述定义。需求创建包含如下两种模式：
• 手工需求创建模式（可替代DOORS）
• 通过Doors集成创建需求项模式
Ø 实现需求发布、分配、变更及闭环等全过程管理，在PLM平台中实现需求的关联、追溯与闭环能力。
Ø 需求结构化管理作为科研单位院级通用微服务，供全科研单位各单位在统一模式下进行应用。
8、 仿真模型数据管理
仿真模型管理主要内容包括：
Ø 仿真数据建模
对仿真过程中仿真参数、仿真模型、分析结果、报告等仿真相关的数据进行定义和管理。
Ø 仿真模型管理
各类仿真数据按照一定方式进行组织，以便进行管控、检索和引用，包括多轮次、多方案和多工况分析仿真数据的分类组织、集中存储、版本控制、共享交换、接口集成和关联追溯等。
Ø 仿真模型可视化
实现Matlab/Simulink 、ANSYS、HFSS等多学科仿真工具产生的仿真模型的在线可视化查看、综合展示等。
Ø 仿真模型管理作为科研单位院级通用微服务，供全科研单位各单位在统一模式下进行应用。
9、 SBOM管理
SBOM管理主要内容包括：
Ø 功能迁移
将某总体部、某所的SBOM管理功能迁移到PLM平台上；
Ø SBOM管理
实现EBOM批量转换为SBOM，支持SBOM的导入/导出等功能，实现SBOM及相关维修数据的批量签审；
Ø 维修工具管理
支持维修工具信息的创建和编辑功能，支持从基础资源库中将基础资源转换为维修工具，支持服务部件和工具的关联；
Ø 报表管理
自动生成包括LRU清单、器材目录、初始备件清单、备附件及工具配套表、工具清单、连接件清单等报表；
Ø SBOM管理作为科研单位院级通用微服务，供全科研单位各单位在统一模式下进行应用。
10、 系统集成
Ø 需要集成以下各类系统和工具：
•
MRO集成：实现SBOM、维修数据等传递给MRO系统；
•
MPM集成：实现计划任务同步，实现计划交付物等数据的双向集成；
•
OnRoad集成：实现软件设计结果数据的管理，实现软件设计数据的单向集成；
•
BDM集成：实现基础资源库数据的集成关联，实现基础资源信息、模型、权限等信息的双向同步；
•
ERP集成：实现物料数据的同步，实现EBOM/PBOM、物料编码等信息的双向同步；
•
CAPP集成：实现工艺数据的管理，实现EBOM/PBOOM、工艺文件、工艺路线等信息的双向集成；
•
Altium集成：实现电子设计数据的管理，实现原理图、PCB图、元器件信息等的双向集成。
1.7 数据迁移
截止PLM系统数据正式迁移前，进行了四轮迁移演练。
Ø 第一轮迁移演练完成了某总体所两个型号数据的迁移演练工作；
Ø 第二轮迁移演练完成了某设计所16个型号数据及某总体所型号数据的迁移演练工作。
Ø 第三轮迁移演练重新迁移所有数据，同时记录迁移过程中各个过程所需时间，用户测算正式数据迁移所需时间。
Ø 第四轮迁移演练演练迁移数据检查工具成熟度：
•
检查数据库数据同步的完整性；
•
检查索引数据是否缺失；
•
检查数据属性是否缺失；
•
检查数据附件是否缺失。
1.8 硬件环境配置方案
|
名称 |
数量 |
配置要求 |
|
Web 服务器 |
2 |
OS：银河麒麟 CPU：飞腾 FT-2000+ 2200MHz 64核 内存：64G 存储：2T 部署为双活模式，利用现有硬件实现负载均衡能力 |
|
应用 服务器 |
4 现有1台 |
OS：银河麒麟 CPU：飞腾 FT-2000+ 2200MHz 64核 内存：128G 存储：2T 部署为双活模式 |
|
Oracle数据库 服务器 |
2 |
利用现有科研单位PDM的数据库服务器 |
|
中间件 服务器 |
2 现有1台 |
OS：银河麒麟 CPU：飞腾 FT-2000+ 2200MHz 64核 内存：128G 存储：2T+磁盘阵列 部署为双活模式 |
1.9 风险控制
第一阶段项目建设包含如下主要风险：
Ø 业务方面
• 通用微服务定义与设计难度较大，各单位原有系统差异性大，PDM管理的数据分类、属性、流程、模型、接口等均不统一，需要大量统筹、平衡、协调工作进行微服务抽象。通用微服务如果设计不合理，将会在很大程度影响科研单位院级统一平台的应用。
• 基础资源数据统一难度较大，当前各单位基础资源数据模型不一致，物码不对应，需要进行统一，否则无法开展协同设计应用。
Ø 应用方面
• 新平台与原有Windchill应用模式存在较大差异，需要加大力度进行宣传、培训，辅以规章制度进行推动应用，以免影响整体应用效果；
• 先行切换到新平台单位与保留Windchill系统的单位之间的协同模式发生变化，全科研单位两种不同的协同模式需要各单位设计师尽快适应，以免影响协同工作。
Ø 建设方面
• 年度计划时间紧任务重，大量需求梳理、业务定义、规则讨论等工作需要各厂所不同角色人员参与，平台建设、通用微服务开发、系统升级、数据迁移、接口开发调整、新能力建设等需要大量的方案设计、开发实施人员参与。
• 采用结合当前版本windchill的模式，未来需要进行系统升级与数据迁移，进一步增大了整体建设实施的工作量。
二、 建设成果
实现型号研制业务的连续性与可持续，发展建立覆盖全生命周期的型号研制管理机制，保障业务不中断、可演进、可扩展。
支撑复杂、快速、高可靠性协同研制，构建面向多专业、多单位的协同研制平台，支持高复杂度产品的并行设计与敏捷迭代。
实现型号数据的自主可控与信息安全，基于国产平台构建安全可靠的型号数据管理与防护体系，保障研制过程信息不出境、不泄露。
消除国外技术封锁带来的供应链风险，规避关键依赖国外工业软件的环节，形成自主可控的软件能力与工具链。
支撑高端装备可持续快速发展，建立以国产工业软件为核心的研制支撑体系，推动装备研制从依赖外部向自主引领转变。
实现科研单位院级集中统一管理与数据标准化，完成科研单位院级平台集中部署，统一管理编码、资源库及型号技术状态信息，确保数据一致性与可控性。
建成多租户架构平台，各厂所可在各自租户下独立配置业务流程与应用，兼顾统一与灵活。
基于微服务与数字主线技术，提供面向不同角色、场景的APP化应用，提升敏捷响应与智能化协同能力。
全面深化MBD技术应用，实现与Creo 6.0等新版本设计工具的深度集成，提升基于模型定义的应用成熟度。
提升多专业、跨单位协同研制效率，成功集成MBSE、CAE等工具，并与其他科研单位实现跨单位协同，显著提升协同效率。
扩展研制平台核心能力，新增需求管理、模型管理、SBOM、MBOM等关键功能模块，支撑更完整的研制过程管理。
显著提升PDM平台性能与应用体验，对现有PDM平台进行性能优化与交互体验升级，提升日常使用效率与用户满意度。
三、 经验总结与建议
1.10 成果经验
1、 业务统筹方面
· 识别出核心难点即重要成果：项目前期准确识别出“通用微服务定义”和“基础资源数据统一”两大业务难点，为后续投入资源、集中攻关提供了明确方向。
· 推动了跨单位业务对齐：在微服务抽象过程中，虽然难度大，但客观上倒逼各单位对数据分类、属性、流程、模型、接口进行了首次系统性对齐，为科研单位院级统一平台奠定了基础。
2、 应用推进方面
· 提前识别应用模式差异：认识到新平台与Windchill应用模式的显著差异，并提前制定了宣传、培训与制度配套计划，避免了后续应用落地阶段被动应对。
· 明确协同模式变化：主动识别出“双平台并行”带来的协同模式差异，并提示需要设计师适应，体现了对一线使用场景的深刻理解。
3、 建设管理方面
· 对工作量有清醒认知：清晰认识到时间紧、任务重、人员参与广、开发量大的现实，避免了乐观估计导致资源不足。
· 识别出“双模式迁移”的额外成本：明确指出现有Windchill模式 + 未来升级迁移模式会放大工作量，为项目计划和资源配置提供了重要依据。
1.11 教训与不足
1、 业务层面
· 通用微服务设计前期投入不足：在项目初期，对各单位原有系统差异性的评估可能偏乐观，导致微服务抽象过程中反复协调、返工，影响整体节奏。
· 基础资源数据统一启动偏晚：物码不对应、数据模型不一致等问题在协同设计应用前才集中暴露，说明前期数据治理工作未充分前置。
2、 应用层面
· 对双平台并行的复杂度估计不足：虽然识别了协同模式变化，但在实际推行中，设计师同时适应两种模式的难度仍然被低估，影响了短期协同效率。
· 培训与制度跟进速度滞后：新平台应用模式的转变要求高于预期，而相应的培训材料和规章制度更新未能完全同步，造成部分用户抵触或误用。
3、 建设层面
· 人员协调成本高于预期：各厂所不同角色人员需大量参与需求梳理、规则讨论，实际占用时间远超计划，影响各单位本职工作。
· “当前windchill + 未来迁移”路径存在隐性风险：该模式虽然在短期内降低了上线门槛，但导致后续系统升级和数据迁移工作被延后但未减少，整体建设周期拉长。
1.12 给其他企业的建议
1. 业务建议
· 先做数据治理，再做微服务抽象
在启动通用微服务设计前，先完成各单位数据分类、属性、模型、接口的标准化评估与治理，避免在抽象过程中陷入无尽协调。
· 设立科研单位院级业务协调组，常态化统筹
指定一个由各厂所业务骨干组成的常设协调组，统一负责微服务定义和资源数据标准，减少临时协调成本。
2. 应用建议
· 宁可晚上线，不可双模式长期并行
尽量避免新旧平台长期并存的双模式协同，如无法避免，应明确双模式切换的时间窗口，并在此期间提供高强度现场支持。
· 配套制度先行，培训分层次开展
在新平台上线前，先完成规章制度修订和考核机制配套；培训应区分设计人员、管理人员、系统管理员等不同角色，采用“案例式 + 实操式”培训。
3. 建设建议
· 采用“大版本跳迁 + 一次性迁移”策略
不推荐“当前版本上线 + 未来升级迁移”的两步走模式，建议在充分测试后直接进行大版本跳迁与数据一次性迁移，减少总体工作量。
· 提前锁定关键用户参与时间
在项目计划中，明确各厂所关键人员（业务、技术、数据）的参与周期与投入比例，并通过正式渠道锁定资源，避免人员临时抽调导致决策滞后。
· 分阶段交付微服务，而非一次性全量
通用微服务可按业务域（如编码、资源、BOM、状态）分阶段设计与交付，每阶段验证后再扩展，降低整体设计风险。
