2. Windchill协同环境搭建

Windchill 的供应商协同并不是把外部账号直接塞进内部系统，而是要在同一套 Windchill 实例中，为外部伙伴建立一套“可隔离、可授权、可审计”的协同环境。本节围绕四个相互咬合的构件展开：供应商协同门户决定外部用户看到什么、从哪里进入；组织建模决定数据归属与隔离边界；用户与权限体系决定谁能对哪些对象做什么；合作伙伴注册与准入配置决定外部主体如何被引入、验证并激活。四者缺一，协同环境要么无法用，要么存在越权与数据泄露风险。

一、协同门户：外部用户的唯一入口

供应商协同门户通常以 Windchill 的“外部组织上下文”为基础，通过专用站点、专用导航或专用工作区呈现。门户不是简单换皮，而是要在入口层就完成三件事：身份识别（外部用户登录后进入其所属组织上下文）、功能裁剪（只暴露与协同相关的功能，如查看受控图纸、提交交付物、响应变更请求）、数据过滤（默认只显示该供应商被授权访问的对象）。

在 Windchill 中，门户常通过“站点—组织—工作区”的层级来组织。例如，为供应商 A 建立独立组织 ORG_SUP_A，其用户登录后默认落在该组织上下文，只能看到本组织容器下的对象。门户首页可配置为“待办任务 + 受控文档 + 变更通知”三块，避免外部用户进入内部产品结构或成本数据区域。

二、组织建模：隔离与归属的骨架

组织建模的核心是回答“数据属于谁、谁可见”。Windchill 中常见的做法是：内部按产品线或事业部建立组织，外部按供应商主体建立独立组织，并通过“共享”或“上下文关联”把必要的对象暴露给外部组织。组织建模的关键参数包括：组织标识、组织类型（内部/外部）、默认容器、可见性策略、以及与其他组织的共享关系。

一个可参考的建模示例：内部组织 ORG_INT_PRODUCT 下存放产品结构、设计文档与变更单；外部组织 ORG_SUP_A 下存放该供应商的交付物、回复文档与协同任务。通过“共享文件夹”或“上下文链接”把内部已发布的受控文档共享给 ORG_SUP_A，而内部未发布或成本相关对象不共享。这样，供应商在门户中只能看到被共享的受控版本，无法遍历内部完整结构。

三、用户与权限体系：从“能登录”到“只能做该做的事”

Windchill 的权限模型通常由“用户—组—角色—上下文—对象—操作”六个维度共同决定。外部用户不应直接授予个人权限，而应通过外部组和外部角色来管理。例如，为供应商 A 建立组 GRP_SUP_A_ENG（工程）、GRP_SUP_A_QA（质量）、GRP_SUP_A_BIZ（商务），再为每个组分配角色：工程组可查看受控图纸、提交交付物；质量组可查看检验规范、回复质量问题；商务组可查看报价相关共享对象。

权限配置的关键在于“最小必要”。以受控文档为例，外部工程组通常只应具备 Read 和 Download，不应具备 Modify、Delete 或 Change State。对于交付物提交，可授予外部组在指定文件夹下的 Create 和 Modify，但该文件夹位于外部组织容器内，内部用户通过共享或任务查看，不直接修改外部数据。这样既保证协同，又避免外部用户误改内部受控对象。

实际配置时，建议先建立“权限矩阵”再落系统。矩阵行是外部角色，列是对象类型与操作，单元格填写允许/拒绝。例如：

矩阵确定后，在 Windchill 中通过“策略管理”或“访问控制规则”逐条落地。注意：外部组织的默认权限应设为“拒绝”，再按角色逐项开放，避免默认继承内部权限导致越权。

四、合作伙伴注册与准入配置：把外部主体“请进来”并验证

合作伙伴注册不是简单建账号，而是一条从“申请—审核—建组织—建用户—授权—激活”的准入链。Windchill 中可借助“注册请求”或外部表单收集供应商信息，审核通过后再由管理员创建外部组织与用户。关键字段包括：供应商名称、统一社会信用代码、联系人、邮箱、拟协同的产品线、所需角色、保密协议编号、准入有效期。

准入配置的核心判断是“是否允许该供应商进入协同环境”。建议设置三道检查：资质检查（营业执照、质量体系证书是否在有效期内）、协议检查（保密协议是否签署、是否覆盖当前协同范围）、角色匹配检查（申请角色是否与协同任务一致）。三道检查通过后，才创建组织与用户，并设置账号有效期。例如，某供应商准入有效期为 12 个月，到期前 30 天系统自动提醒续期，逾期未续则账号自动禁用，但历史交付物保留可查。

综上，Windchill 供应商协同环境的搭建，本质是在“隔离”与“协同”之间找到精确边界：组织建模划出数据归属，门户决定入口与可见范围，权限体系控制操作粒度，注册与准入则把外部主体安全地引入。四者按“先建模、再授权、后准入、最后验证”的顺序推进，才能形成可运行、可审计、可扩展的协同环境。