1. Active Workspace实施全景
Active Workspace（简称 AWC）是 Siemens Teamcenter 的现代化 Web 客户端，它并不是一个独立于 Teamcenter 之外的新系统，而是运行在 Teamcenter 服务端之上的“前端呈现层与交互层”。理解这一点，是实施工作的起点：AWC 负责把 Teamcenter 的数据模型、权限、工作流、BOM、变更等能力，以现代化、可配置、可扩展的界面呈现给用户；而真正的业务数据、业务规则、访问控制仍然由 Teamcenter 服务端承载。因此，AWC 实施本质上是“在既有 Teamcenter 环境上做客户端落地”，而不是重建一套 PLM。
从架构定位看，AWC 位于用户与 Teamcenter 之间，向上提供浏览器访问入口，向下通过 Teamcenter 服务、SOA 接口、微服务与数据层交互。它通常与 Teamcenter 的 Rich Client（胖客户端）并存：工程师、设计师可能继续使用胖客户端完成复杂建模与深度操作，而管理者、审批者、供应链与外部协作人员更多通过 AWC 完成查询、浏览、审批、轻量编辑与协同。实施者必须清楚哪些能力在 AWC 中已经具备、哪些需要配置扩展、哪些仍应引导用户回到胖客户端，否则容易在需求阶段做出无法交付的承诺。
上图把“架构定位”和“实施生命周期”放在同一张图里，是因为二者在真实项目中是耦合的：架构决定了哪些层可以配置、哪些层必须开发、哪些层只能由 Teamcenter 服务端解决；而生命周期则决定了在每个阶段应该产出什么、由谁负责、用什么标准判断可以进入下一阶段。
实施生命周期各阶段的核心任务
评估与规划阶段的目标是回答“为什么做、做多大、谁参与”。实施者需要先梳理现有 Teamcenter 版本、已启用的模块、用户规模、并发量、网络与浏览器环境，再明确 AWC 的试点范围。例如，一个典型制造企业可能先选择“文档查询与审批”作为第一期范围，而不是一次性把 BOM 编辑、变更管理、供应商协同全部上线。此阶段应产出需求清单、角色矩阵、范围边界说明和初步风险清单。判断能否进入下一阶段的依据是：范围是否可被现有 AWC 能力覆盖、关键用户是否已确认、环境是否具备安装条件。
环境与部署阶段关注“装得上、连得通、跑得稳”。AWC 通常部署在 Web 应用服务器（如 Tomcat 或 Siemens 推荐的容器）上，需要与 Teamcenter 服务端、数据库、文件服务器、SSO 等基础设施正确对接。实施者要确认 AWC 版本与 Teamcenter 版本的兼容矩阵，配置数据库连接、服务地址、认证方式，并验证登录、搜索、打开对象、下载文件等基础链路。此阶段的关键交付物是环境架构图、部署记录和连通性验证结果。若登录后无法加载对象或搜索无结果，应优先检查服务地址、认证令牌和权限配置，而不是直接怀疑前端页面。
配置与扩展阶段是 AWC 实施工作量最集中的部分。AWC 的配置通常包括：页面布局与导航结构、命令与操作按钮、搜索与筛选条件、对象视图与属性卡片、工作流任务页面、权限与角色映射。扩展则通过 Extension 机制实现，例如自定义命令、自定义视图、自定义数据提供者。实施者需要区分“配置能解决”和“必须写扩展”的边界：如果只是调整字段显示顺序、隐藏某个按钮、增加一个查询条件，通常通过配置完成；如果要接入外部系统数据、实现特殊业务校验、动态生成界面元素，则需要开发扩展。此阶段应产出配置说明、扩展代码包和部署包，并在测试环境中逐项验证。
测试与验证阶段不能只做“页面能打开”的冒烟测试。应覆盖功能、权限、性能和用户体验四类验证。功能测试确认命令、搜索、打开、编辑、审批等操作符合预期；权限测试确认不同角色只能看到和操作其授权范围内的数据；性能测试关注并发用户数、页面加载时间、大装配打开时间等指标；用户体验测试则邀请真实业务用户完成典型任务，观察是否存在操作路径过长、术语不统一、反馈不清晰等问题。此阶段应产出测试用例、缺陷清单和用户验收报告。判断能否上线的依据是：关键业务场景全部通过、无阻塞性缺陷、性能指标在可接受范围内。
上线与运维阶段的重点是“平稳切换、持续优化”。上线前应完成用户培训、权限最终确认、数据备份和回滚方案；上线后应监控登录成功率、页面响应时间、错误日志和用户反馈。AWC 的运维不是一次性工作，而是需要根据用户使用情况持续调整配置、优化查询、补充扩展。此阶段应产出培训材料、运维手册和问题跟踪机制。
关键角色与职责边界
一个可落地的 AWC 实施团队通常包含以下角色：项目经理负责范围、进度、风险和沟通；Teamcenter 架构师负责整体架构、数据模型、权限模型和服务端集成方案；AWC 配置/开发人员负责界面配置、扩展开发、部署包制作；测试人员负责测试用例设计、执行和缺陷跟踪；业务关键用户负责需求确认、验收测试和培训推广；IT 运维人员负责服务器、网络、数据库、SSO 和监控。角色之间不是串行交接，而是并行协作：配置人员需要架构师确认数据模型，测试人员需要关键用户确认业务场景，运维人员需要开发人员提供部署说明。
交付物与判断标准
每个阶段的交付物不仅是文档，更是进入下一阶段的“通行证”。评估阶段的需求清单和角色矩阵用于确认范围；部署阶段的环境架构图和验证记录用于确认基础可用；配置阶段的配置说明和扩展包用于确认功能可复现；测试阶段的测试用例和验收报告用于确认质量达标；上线阶段的培训材料和运维手册用于确认可持续运行。实施者应养成“每阶段有输出、每输出可检查”的习惯，避免把问题堆积到上线前才暴露。
最后需要强调：AWC 实施的成功标准不是“功能全部做完”，而是“用户愿意用、用得顺、数据看得见、权限管得住”。因此，从第一天起就应把用户角色、业务场景和验收标准放在与安装配置同等重要的位置。只有架构定位清晰、生命周期完整、角色职责明确、交付物可验证，AWC 实施才能从“装好一个客户端”走向“真正支撑业务协同”。