1. 课程导入与治理全景

在Teamcenter的实际项目中，权限问题往往不是"某个按钮点不动"这么简单。它通常表现为一连串彼此纠缠的现象：新入职的工程师看不到自己该看的图纸；离职人员的账号仍然能下载关键数模；同一个零件在A项目里可编辑、在B项目里却只读；审计时发现某位供应商账号能访问三个事业部全部数据。这些现象背后，是组织模型、角色定义、访问规则、数据归属与生命周期状态五条线索没有对齐。本课程要解决的，正是把这条从"组织结构"到"权限生效"的链路治理清楚。

一、业务驱动：为什么组织权限需要"治理"而不只是"配置"

Teamcenter的访问控制能力非常强，强到可以组合出成千上万条规则。但能力强不等于结果可控。企业常见的驱动因素有三类：

• 合规与审计驱动：汽车、航空、医疗器械等行业要求可追溯"谁在什么时间、以什么身份、访问了哪些受控数据"。权限配置若缺乏统一模型，审计时无法自证。
• 协作边界驱动：主机厂与供应商、总部与工厂、设计与工艺之间需要共享，但共享必须"最小必要"。边界模糊会直接导致数据泄露风险。
• 变更效率驱动：组织调整、项目立项、人员轮岗频繁发生。如果每次变更都要逐条改权限，运维成本会迅速失控。

因此，治理的目标不是"把权限配好"，而是建立一套可建模、可复用、可审计、可演进的机制，让权限随组织与业务变化自动收敛，而不是靠人工救火。

二、核心挑战：权限失控的四个典型根因

结合大量实施与排障经验，权限问题几乎都能归到以下四类根因：

1. 组织模型与业务模型脱节：Group/Role被当成"通讯录"来建，而不是按职责与数据边界来建。结果是角色数量膨胀，语义模糊。
2. 规则叠加不可预测：ACL、项目、Owning Group、Owning User、状态、分类等多层规则同时作用，允许与拒绝的优先级没有统一约定，导致"看起来该能访问却访问不了"。
3. 数据归属不清：对象创建时没有明确Owning Group/User，后续靠ACL补救，形成大量例外规则。
4. 缺乏验证与回归：权限变更后没有用测试账号矩阵验证，问题往往在业务上线后才暴露。

三、治理目标与整体框架

本课程将治理目标归纳为四句话：组织有语义、角色有边界、规则有优先级、结果可验证。围绕这四句话，整体框架分为五层，从下到上依次是：

• 组织层：Group、Role、User、User Group Membership，定义"谁是谁"。
• 数据归属层：Owning Group、Owning User、项目（Project）、分类（Classification），定义"数据属于谁"。
• 规则层：Access Manager中的ACL、Rule Tree、访问者（Accessor），定义"谁能对什么做什么"。
• 状态与生命周期层：对象状态（如Released、In Work）与流程节点，定义"在什么阶段可做什么"。
• 验证与审计层：测试账号矩阵、权限报告、审计日志，定义"结果是否符合预期"。

这五层不是并列的，而是逐层收敛的关系：组织层决定主体，数据归属层决定客体，规则层把主体与客体连接起来，状态层对连接加上时间与阶段约束，验证层确认最终效果。任何一层缺失，权限都会出现"漏"或"堵"。

四、一个可复现的入门示例：从组织到权限的最小闭环

为了把框架落到可操作层面，这里给出一个最小示例。假设某企业有"设计部"和"工艺部"，设计部工程师需要编辑自己部门的零件，工艺部只能查看已发布零件。示例参数如下（属于教学假设，非实测数据）：

配置思路是：在Access Manager中为零件对象类型建立规则树，先按Owning Group匹配，再按状态分支。设计部工程师在In Work状态下拥有写权限；工艺部查看者在Released状态下拥有读权限。配置完成后，用u_zhang和u_li两个测试账号分别登录，验证四件事：u_zhang能否编辑In Work零件、u_li能否查看Released零件、u_li能否编辑Released零件（应为否）、u_zhang能否查看工艺部私有数据（应为否）。只有四项都符合预期，这个最小闭环才算成立。

五、本课程的学习路径

接下来的章节会沿着这五层框架逐层展开：先讲组织建模与命名规范，再讲数据归属与项目隔离，然后深入Access Manager的规则优先级与排障方法，最后落到审计、验证与治理运营。学习时建议始终带着一个问题：当前这一层，是在解决"谁是谁"、"数据属于谁"、"谁能做什么"、"什么阶段能做"还是"结果对不对"。把每层职责分清，权限治理就不会再是一团乱麻。