📚 课程目录第3章组织建模与用户管理

3. 组织建模与用户管理

在 Teamcenter 中，权限并不是直接授予某个人的，而是沿着“组织—角色—用户”这条链路逐层传递的。理解这条链路，是后续做访问控制治理的前提。本节要解决的核心问题是：如何把企业真实的组织架构，映射成 Teamcenter 里可维护、可授权、可扩展的 Group、Role、User 三层结构，并完成用户账户的创建、属性维护与组织归属配置。

一、三层对象各自承担什么职责

Teamcenter 的组织模型由三个基本对象构成，它们不是简单的“文件夹套文件夹”，而是各自承担不同的语义：

Group（组）：代表组织单元，如“研发部”“工艺部”“供应商A”。它回答的是“这个人属于哪个部门/团队”。Group 是权限继承和对象归属的主要载体，也是数据隔离的边界。
Role（角色）：代表岗位职能，如“设计师”“审核员”“只读访客”。它回答的是“这个人干什么活”。Role 决定该用户能执行哪些操作（创建、修改、审批、发布）。
User（用户）：代表具体的人或系统账号，如“zhangsan”“svc_integration”。它回答的是“具体是谁”。User 必须同时挂接一个 Group 和一个 Role，才能形成有效的“组织+职能”身份。

关键点在于：Group 与 Role 是正交的两个维度。同一个人可以属于“研发部”，同时拥有“设计师”角色；也可以属于“工艺部”，同时拥有“审核员”角色。权限判定时，Teamcenter 会综合 Group 的继承权限与 Role 的操作权限，取并集或按规则叠加。因此，建模时不要把部门名和岗位名混在同一个对象里，否则后期授权会非常混乱。

二、从企业架构到 Teamcenter 结构的映射方法

设计组织模型时，建议按以下顺序推进，而不是一上来就建用户：

梳理企业实际组织树：先画出部门层级，明确哪些是独立核算或需要数据隔离的单元。
确定 Group 层级：通常顶层是公司，第二层是事业部/中心，第三层是部门/科室。层级不宜超过 4～5 层，过深会导致权限继承难以追踪。
抽象 Role 集合：按“操作能力”而非“职位名称”来定义。例如“设计工程师”和“结构工程师”如果操作权限相同，可以共用一个 Role。
建立命名规范：Group 用“部门代码_部门名”，Role 用“职能_权限级别”，User 用“工号或邮箱前缀”，保证可读且唯一。
最后批量创建 User 并挂接归属：用户是模型的使用者，不是模型的设计者。

一个常见误区是“一个部门建一个 Group，一个职位建一个 Role，然后一人一个专属 Role”。这会导致 Role 数量爆炸，授权无法复用。正确做法是 Role 数量控制在 10～30 个以内，覆盖绝大多数岗位。

三、用户账户创建与属性维护

在 Teamcenter 中创建用户，通常通过“组织”应用或管理控制台完成。一个用户账户的核心属性包括：

属性	说明	示例值
User ID	登录名，全局唯一，创建后一般不可改	zhangsan
姓名	显示名称，用于界面识别	张三
默认 Group	登录后默认归属的组织单元	RND_研发部
默认 Role	登录后默认使用的角色	Designer_设计师
邮箱	用于通知与找回	zhangsan@corp.com
状态	Active / Inactive，控制是否可登录	Active

属性维护中有两个容易出问题的点：一是默认 Group/Role 与附加归属的关系。用户可以有多个 Group 和 Role 归属，但登录时只激活默认的那一组；需要切换时通过“设置默认”或重新登录实现。二是停用而非删除。员工离职时应将状态置为 Inactive，而不是删除账户，因为该用户创建的历史数据、审批记录仍需要保留归属信息，删除会导致数据归属悬空。

四、组织归属配置的实际操作链路

下面这张图展示了从企业组织到 Teamcenter 用户身份的完整映射关系，以及用户登录后权限是如何沿 Group 和 Role 两条路径汇聚的。图中同时标出了默认归属与附加归属的区别，便于理解“一个人为什么会有多重身份”。

五、配置示例与结果判断

假设某制造企业要为新入职的结构工程师“李四”配置账号。按照前面的方法，操作链路如下：

1. 确认组织归属：研发中心 → 结构设计部
2. 创建/复用 Group：RND_研发中心 / RND_结构设计部
3. 选择 Role：Designer_设计师（具备创建、修改、检入权限）
4. 创建 User：
   User ID   : lisi
   姓名      : 李四
   默认 Group: RND_结构设计部
   默认 Role : Designer_设计师
   邮箱      : lisi@corp.com
   状态      : Active
5. 附加归属（可选）：QMS_质量部 + Reviewer_审核员
6. 保存并通知用户首次登录修改密码

配置完成后，如何判断是否生效？可以从三个层面验证：

登录验证：用 lisi 登录，检查界面左上角显示的组织与角色是否为“RND_结构设计部 / Designer_设计师”。
权限验证：尝试创建一个 Item（如零件对象），能成功创建并检入，说明 Designer 角色的创建权限已生效。
隔离验证：用另一个部门的用户登录，确认其无法看到结构设计部的私有数据，说明 Group 的数据隔离边界正确。

如果用户登录后看不到预期的菜单或按钮，优先检查三件事：默认 Role 是否选错、Group 层级是否挂到了错误的父节点、用户状态是否为 Inactive。这三类问题占实际配置故障的绝大多数。

六、治理视角下的维护要点

组织模型不是一次建完就结束的。随着企业调整，Group 会新增、合并或废弃，Role 会随流程变化而增减。治理层面需要建立几条纪律：

变更留痕：Group 和 Role 的增删改应有审批记录，避免随意新建导致模型膨胀。
定期审计：每季度核对一次“在职人员—账号状态—组织归属”三者是否一致，重点清理离职未停用、跨部门未调整的账号。
最小权限：新增 Role 时先问“能否复用现有 Role”，而不是直接复制一个近似角色。Role 越多，权限叠加的不可预测性越高。
命名不随业务改名而频繁变动：Group 的显示名可以改，但内部标识尽量稳定，否则会影响已配置的权限规则和查询条件。

把 Group、Role、User 三层关系设计清楚，后续的访问控制、数据隔离、审批流转才有稳定的基础。组织建模的质量，直接决定了权限治理是“可维护”还是“越管越乱”。