2. Windchill组织模型解析

Windchill 的权限治理之所以容易“越配越乱”，根本原因往往不是 ACL 写得不对，而是没有先分清对象到底落在哪一层容器里。Windchill 把数据组织成一条自上而下的容器链：站点（Site）→ 组织（Organization）→ 产品库/存储库（Product / Library）→ 项目（Project）→ 文件夹（Folder）。每一层既是数据的归属位置，也是权限、生命周期模板、编号规则和团队角色的作用边界。理解这条链，等于拿到了后续所有权限配置的“坐标系”。

一、五层容器的定位与职责

站点是整个 Windchill 系统的最高层，通常一个企业部署只有一个站点。站点层管理的是全局性资源：用户与用户组、站点级首选项、全局类型与属性定义、站点级生命周期模板、审计与许可证。站点管理员（Site Administrator）的权限极大，因此站点层不应承载业务数据，只承载“规则”和“人”。

组织是站点下的第一个业务分区，用于隔离不同事业部、不同法人或不同保密域。组织拥有自己的管理员（Organization Administrator）、自己的用户组结构、自己的编号序列和容器模板。跨组织默认不可见，这是 Windchill 实现“数据隔离”的第一道闸门。例如集团下分“华东研发中心”和“华南研发中心”两个组织，两边工程师即使同名同岗，也看不到对方组织内的对象。

产品库（Product）与存储库（Library）是组织下的两类并列容器。产品库存放某个产品线的设计数据，强调“随产品演进”；存储库存放可复用的标准件、通用件、企业规范，强调“跨产品共享”。两者在权限模型上结构相同，但治理策略不同：产品库通常按项目阶段收紧，存储库通常对全组织开放读取、仅少数人可写入。

项目是产品库或存储库内部的一次性协作空间，用于承载有明确起止时间的任务，如“某型号改型项目”。项目拥有独立的团队成员（Team）、独立的角色（Role）和独立的文件夹结构。项目结束后可以归档或删除，而不影响产品库中的正式数据。

文件夹是容器链的最末端，是对象实际“存放”的位置。文件夹本身不产生新的权限域，它继承所属产品库/项目/存储库的权限，但可以通过文件夹级 ACL 做更细的收口，例如把“成本数据”文件夹单独限制给财务角色。

二、治理边界：谁管什么，谁不能越界

层级关系决定了治理边界。站点管理员管“规则”，组织管理员管“分区”，产品库/存储库管理员管“数据域”，项目经理管“临时团队”，文件夹所有者管“细粒度收口”。越往下，权限范围越小，但颗粒度越细。

一个常见的误区是把用户直接加到产品库团队里，却忘了产品库本身属于某个组织。如果该用户不属于这个组织，即使被加入产品库团队，也可能因为组织级隔离而无法访问。正确顺序是：先确认用户属于哪个组织，再确认目标容器属于哪个组织，最后才配置容器级角色。跨组织协作必须通过“共享”或“外部成员”机制显式开通，而不是默认可见。

三、生命周期模板的绑定层级

生命周期模板可以绑定在站点、组织、产品库/存储库、项目甚至文件夹层。绑定层级越低，优先级越高。例如站点层定义了通用“发布-修订-废弃”模板，但某产品库因为要满足汽车行业 IATF 16949 要求，单独绑定了带“PPAP 批准”状态的模板，则该产品库下的对象走产品库模板，而不是站点模板。文件夹层一般不建议单独绑定生命周期，否则同一产品库内会出现状态机不一致，导致升级和变更流程难以统一。

四、编号与命名规则的归属

编号序列（Numbering Sequence）通常定义在组织层，产品库和项目可以覆盖。例如组织层默认“PRJ-{YYYY}-{####}”，某产品库改为“HW-{####}”。文件夹不参与编号生成，但文件夹路径常被用作分类维度。治理建议是：编号规则尽量收敛到组织层，产品库只在有强合规要求时才覆盖，避免同一组织内出现多套编号逻辑导致检索混乱。

五、一个可落地的容器规划示例

假设某制造企业部署 Windchill，规划如下：站点层只保留一个，管理全公司用户和全局首选项；组织层按“研发中心”和“制造基地”划分两个组织；研发中心下建“智能硬件产品库”和“企业标准件存储库”；智能硬件产品库下为“A 型号改型项目”建独立项目；项目内按“结构”“电子”“软件”“测试”建四个文件夹。此时，一个结构工程师的访问路径是：站点 → 研发中心 → 智能硬件产品库 → A 型号改型项目 → 结构文件夹。他的权限由这五层叠加决定，任何一层拒绝都会导致最终不可见。

把这条五层容器链理解成“数据住在哪、规则由谁定、权限在哪收口”，后续的 ACL 配置、生命周期模板绑定和团队角色设计就有了统一的参照系。治理边界清晰之后，权限问题会从“玄学”变成可定位、可复现的工程问题。