4. Teamcenter客户端体系

Teamcenter 并不是“一个客户端打天下”的系统。它把同一套 PLM 数据与服务，通过不同客户端形态暴露给不同角色：有人需要重度建模与批量编辑，有人只需要审批和查看，有人要在车间或出差途中用手机处理任务。理解客户端体系的关键，不是记住四个名字，而是理解它们各自连接的服务端能力、承载的交互深度，以及由此决定的适用边界。

四种客户端的能力定位

Rich Client（胖客户端）是 Teamcenter 功能最完整的桌面客户端，通常以 Java 应用形式安装，直接连接 Teamcenter 服务端。它提供完整的结构管理器、变更管理、工作流设计、分类管理、权限配置、批量导入导出、NX/CAD 集成等能力。适合工程师、数据管理员、系统管理员进行深度操作。代价是安装部署重、升级需逐机维护、对终端环境有要求。

Web Client（传统 Web 客户端）通过浏览器访问，覆盖了相当一部分日常业务功能，如查询、检入检出、工作流任务处理、BOM 查看等。它降低了部署成本，但交互深度和响应体验弱于 Rich Client，复杂结构编辑、大批量操作、深度定制场景仍显吃力。

Active Workspace（AW）是 Teamcenter 的现代化 Web 前端，基于响应式设计，强调搜索驱动、图形化导航和角色化工作台。它把“找数据、看关系、做决策”作为核心体验，支持 3D 可视化、BOM 对比、变更影响查看、任务审批等。AW 已成为很多企业面向大多数业务用户的主入口，尤其适合产品经理、项目经理、采购、质量、审批人等非深度建模角色。

移动端通常以 AW 的移动适配或专用 App 形式存在，聚焦“轻任务”：审批、查看、拍照上传、扫码定位、任务提醒。它不承担复杂建模，而是把流程中的等待环节从办公桌解放出来。

选型的核心判断维度

客户端选型不是“哪个新用哪个”，而是围绕四个维度做匹配：任务深度（是否需要复杂结构编辑、批量操作、深度配置）、用户角色（工程师、审批人、现场人员、管理员）、部署与运维约束（终端是否可控、是否允许安装、网络条件）、使用场景（办公室、车间、出差、移动审批）。

一个常见的误区是：企业上线 AW 后，试图让所有用户都放弃 Rich Client。实际上，结构工程师做复杂 BOM 重构、管理员做权限与工作流配置时，Rich Client 仍是效率最高的工具。合理的策略是“AW 做广度，Rich Client 做深度，Web Client 做过渡与补充，移动端做流程加速”。

典型角色与客户端匹配示例

实施中的关键注意点

第一，AW 的推广需要配套的角色工作台设计。AW 默认界面如果直接开放给所有用户，信息密度和导航路径未必贴合每个角色。实施时应按角色配置工作台、搜索过滤器和快捷操作，否则用户会觉得“找不到东西”，反而退回 Rich Client。

第二，Rich Client 的版本与补丁管理要纳入运维计划。胖客户端安装包大、依赖 Java 环境，升级时需逐机推送或通过软件分发系统批量处理。建议在实施初期就明确 Rich Client 的版本基线、升级窗口和回滚方案。

第三，移动端不是“缩小版 AW”。移动端应聚焦审批、查看、拍照、扫码等短任务，避免把复杂表单和长流程塞进小屏幕。实施时可先选一个高频审批流程做试点，验证推送、登录、附件查看等环节的体验。

第四，Web Client 的定位要清晰。如果企业已全面推广 AW，Web Client 可作为过渡期入口或特定功能的补充，但不宜长期作为主入口，否则用户会在两套 Web 界面之间产生认知负担。

总结来看，Teamcenter 客户端体系的设计逻辑是“服务端统一、客户端分层”。选型的本质，是把用户的任务深度、使用场景和运维约束三者对齐，而不是追求单一客户端的全覆盖。只有让每个角色在合适的客户端上完成合适的任务，PLM 的推广阻力才会真正下降。