4. 变更管理角色与权限体系
在Windchill中，ECR与ECO能否高效、合规地流转，核心不在于流程图画得多漂亮，而在于“谁在什么阶段能做什么”。角色定义与访问控制是变更管理体系的骨架：角色决定职责边界，权限决定数据可见性与操作范围，二者共同构成变更流程的“交通规则”。如果角色模糊或权限过宽，轻则流程反复退回，重则出现越权审批、数据泄露或变更遗漏。
一、五类核心角色的职责边界
变更管理通常涉及五类角色，它们并非简单的“职位名称”，而是与流程节点绑定的职责集合。同一名工程师在不同变更单中可能扮演不同角色，因此角色必须与“变更上下文”绑定，而非与“人”绑定。
- 变更发起人（Change Initiator）：识别变更需求并创建ECR。发起人需要填写变更原因、影响范围、紧急程度、初步方案等。发起人通常是问题发现者，如设计工程师、工艺工程师、质量工程师或售后人员。发起人对变更需求的真实性负责，但不一定拥有审批权。
- 评审人（Reviewer）：对变更的技术可行性、影响面、成本、风险进行专业评估。评审人按领域划分，如结构评审、电子评审、工艺评审、采购评审、质量评审。评审人给出“同意/不同意/有条件同意”的意见，但不做最终决策。
- 审批人（Approver）：拥有变更的最终决策权，通常为变更控制委员会（CCB）成员或授权代表。审批人关注的是“是否批准变更”“是否投入资源”“是否承担风险”。审批人可批准、驳回或要求补充信息。
- 执行人（Implementer）：变更批准后，负责在Windchill中落实具体任务，如修改CAD模型、更新BOM、修订工艺文件、切换物料版本、更新ERP主数据。执行人必须按任务清单逐项完成并提交证据。
- 观察者（Observer）：只读权限，用于知会相关方，如项目经理、生产计划、财务、客户代表。观察者不参与审批，但可查看进度、下载受控文件，确保信息透明。
二、Windchill参与者管理与访问控制策略
Windchill通过“参与者管理”将上述角色映射到具体用户或用户组。参与者可以是单个用户、用户组、组织或动态角色。访问控制策略则通过“访问控制规则”定义谁对哪些对象拥有何种权限。Windchill的权限模型通常包括：读取、下载、修改、创建、删除、修订、提升、更改状态等。
在实际配置中，建议采用“角色+生命周期状态”的二维控制矩阵。例如，ECR在“草稿”状态时，只有发起人可修改；进入“评审中”后，评审人可读取并添加评审意见，但不可修改内容；进入“审批中”后，审批人可读取并执行批准/驳回操作；批准后进入“执行中”，执行人可修改受控对象，但发起人变为只读。这种矩阵能有效防止“自己发起、自己审批”的合规风险。
三、角色与权限的映射关系图
下图展示了ECR/ECO流程中五类角色与Windchill访问控制策略的对应关系。图中左侧为角色，中间为流程阶段，右侧为权限类型。箭头方向表示权限的授予方向，虚线表示只读或知会关系。
四、配置实操：以“结构评审组”为例
假设某企业需要为ECR流程配置“结构评审组”，要求该组在ECR进入“评审中”状态时，能够读取ECR内容、添加评审意见，但不能修改ECR正文，也不能批准。具体配置步骤如下：
- 在Windchill中创建用户组“结构评审组”，将结构工程师、CAE工程师、工艺工程师加入该组。
- 在ECR生命周期模板中，为“评审中”状态添加访问控制规则：参与者为“结构评审组”，权限为“读取”“下载”“添加评审意见”，不勾选“修改”“删除”“批准”。
- 为“评审人”动态角色配置解析规则：当ECR进入“评审中”时，系统自动将“结构评审组”解析为当前评审人集合。
- 在ECR表单中增加“评审意见”字段，并设置该字段在“评审中”状态下对评审组可写，对其他角色只读。
- 测试验证：以结构评审组成员账号登录，打开一张处于“评审中”的ECR，确认可添加意见但无法修改正文；以发起人账号登录，确认无法自行批准。
五、权限矩阵示例
下表给出一个简化的权限矩阵示例，用于指导Windchill访问控制规则的配置。矩阵中的“R”表示读取，“W”表示修改，“A”表示批准，“D”表示下载，“—”表示无权限。该矩阵为示例，实际配置需结合企业组织架构与合规要求调整。
| 角色 | 草稿 | 评审中 | 审批中 | 执行中 | 已发布 |
|---|---|---|---|---|---|
| 变更发起人 | R/W | R | R | R | R/D |
| 评审人 | — | R/D + 意见 | R | R | R/D |
| 审批人 | — | R | R/A | R | R/D |
| 执行人 | — | — | R | R/W | R/D |
| 观察者 | — | R | R | R | R/D |
该矩阵的核心逻辑是：权限随生命周期状态动态变化，且同一角色在不同状态下权限不同。例如，发起人在“草稿”状态拥有修改权，但进入“评审中”后即变为只读，防止发起人在评审过程中擅自修改内容。执行人在“执行中”状态才获得修改权，确保变更批准前不会误改受控数据。
六、角色与权限体系的落地要点
第一，角色定义要“职责清晰、边界明确”，避免出现“万能角色”。第二，访问控制策略要“最小权限”，即只授予完成当前任务所必需的最小权限。第三，动态角色要“上下文感知”，利用Windchill的动态角色机制自动解析当前变更单中的具体人员，减少手工维护。第四，权限矩阵要“可审计”，每次权限变更都应记录操作人、时间、变更内容，便于追溯。第五，定期复核角色成员与权限配置，防止人员岗位变动后权限未及时回收。
在实际项目中，建议将角色与权限配置纳入变更管理体系的标准化模板，新项目上线时直接复用，减少重复配置与人为错误。同时，结合Windchill的“访问控制报告”功能，定期导出权限清单，与组织架构进行比对，确保权限体系始终与业务实际保持一致。