1. 课程导入与治理全景
在Windchill中，数据“能不能被看见”和“能不能被修改”是两件完全不同的事。前者由组织权限决定，后者由生命周期状态决定。很多项目上线后出现“工程师看不到自己参与设计的图纸”“已发布的物料仍被随意改属性”“跨部门协作时权限要么过宽要么过死”等问题，根源往往不是某个功能不会用，而是没有把组织、权限、生命周期这三者当成一个整体来治理。本课程要解决的，正是这套治理体系的设计、配置与持续维护。
一、治理目标：让正确的人在正确的阶段做正确的事
Windchill的权限模型不是简单的“用户—文件夹”授权，而是由组织（Organization）→ 域（Domain）→ 访问控制规则（ACL）→ 参与者（Participant）逐层收敛，再叠加生命周期状态对操作能力的动态约束。因此治理目标可以拆成三条可检验的线：
- 可见性正确：用户只能检索、打开、下载其职责范围内的对象，既不遗漏协作所需数据，也不越权看到敏感图纸。
- 可操作性正确：同一对象在不同生命周期状态下，允许的操作集合不同。例如“设计中”可编辑，“已发布”只读，“已冻结”禁止检出。
- 可追溯性正确：任何权限变更、状态跃迁、版本升级都留下审计记录，能回答“谁在什么时候把什么改成了什么”。
这三条线共同构成治理的验收标准。后续章节中出现的每一个配置动作，都应能回答它服务于哪一条线。
二、治理范围：从组织建模到生命周期模板
本课程覆盖的范围可以按“静态结构”和“动态过程”两类来理解。静态结构包括：组织与子组织的划分、用户与用户组的归属、域树的建立、参与者角色的定义、访问控制规则的优先级。动态过程包括：生命周期模板的状态定义、状态跃迁条件、跃迁时的权限重算、版本与版序的推进规则、以及对象在状态变化后的可见性变化。
需要特别说明的是，Windchill中权限是“域 + 状态”共同作用的结果。同一个用户在同一域下，对“设计中”对象可能有修改权限，对“已发布”对象则只有读取权限。因此治理范围不能只画组织树，也不能只画状态机，必须把两者叠在一起看。
三、核心对象：治理工作真正操作的东西
在Windchill的管理界面里，治理工作最终落在以下几类对象上，理解它们的职责边界是后续实操的前提：
| 核心对象 | 作用 | 典型配置位置 |
|---|---|---|
| 组织 / 子组织 | 划分管理边界与数据归属 | 组织管理 |
| 用户 / 用户组 | 权限授予的参与者载体 | 参与者管理 |
| 域（Domain） | 承载访问控制规则的容器 | 策略管理 |
| 访问控制规则（ACL） | 定义“谁对什么有什么权限” | 域内规则编辑 |
| 生命周期模板 | 定义状态、跃迁与状态权限 | 生命周期模板管理 |
| 对象类型 / 软类型 | 决定适用哪套生命周期与权限 | 类型管理 |
其中“域”和“生命周期模板”是最容易被割裂看待的两个对象。实际治理中，它们通过“对象类型”绑定在一起：某类型对象创建时落入某个域，同时套用某个生命周期模板，于是权限 = 域规则 ∩ 状态规则。
四、整体框架：三层治理视图
为了把上述对象和关系讲清楚，本节用一张结构关系图来呈现治理全景。图中左侧是组织与参与者层，中间是域与规则层，右侧是生命周期与状态层，三者通过“对象类型”汇聚到具体业务对象上。
这张图要表达的核心判断是：权限不是单一来源。左侧决定“谁属于哪个组织、扮演什么角色”，中间决定“在哪个域里被授予什么操作”，右侧决定“对象处于什么状态时这些操作是否仍然有效”。三者缺一，治理就会出现漏洞。
五、一个可对照的示例场景
假设某制造企业有“设计部”和“工艺部”两个组织，共用一套产品数据。设计工程师属于“设计部”，工艺工程师属于“工艺部”。企业希望：设计中的图纸设计部可改、工艺部只读；图纸发布后双方都只读；冻结后任何人不得检出。
按本框架落地时，需要同时配置三处：
- 在组织层建立“设计部”“工艺部”，并把人员归入对应用户组。
- 在域层为图纸对象所在域添加 ACL：设计部授予“修改”，工艺部授予“读取”。
- 在生命周期模板中定义“设计中→已发布→冻结”三个状态，并在“已发布”状态上把设计部的“修改”权限收回，在“冻结”状态上对所有角色收回“检出”。
配置完成后，判断某用户能否修改某图纸，只需两步：先看该图纸落在哪个域、该用户在该域被授予了什么；再看该图纸当前处于哪个状态、该状态是否收回了该权限。两步都通过，操作才被允许。这个“两步判断法”会在后续章节反复使用。