3. 审批体系的核心模型与角色设计

在Windchill中，审批体系并不是“把几个人拉进流程”这么简单。它本质上是一套角色—权限—解析规则共同作用的模型：流程模板定义“需要谁参与”，参与者解析规则决定“运行时到底是谁”，而权限模型决定“这个人能做什么”。三者缺一不可，任何一环设计不当，都会导致流程卡死、越权审批或审批记录无法追溯。

一、四类审批角色的职责边界

Windchill审批流程中最常见的参与者角色有四类，它们的职责和权限差异非常明确：

• 审批人（Approver）：对流程对象做出“批准/拒绝”的决策，是唯一能推动审批节点状态跃迁的角色。审批人通常拥有对流程任务的完成权，但不一定拥有对业务对象的修改权。
• 会签人（Reviewer / Co-signer）：与审批人共同承担决策责任，但通常需要“全部通过”或“达到指定比例”才视为通过。会签人一般不能单独批准流程，只能表达同意或反对意见。
• 知会人（Notifier / Acknowledger）：只接收通知，不参与决策。知会人可能被要求“确认已阅”，但确认动作不影响流程走向。
• 观察者（Observer）：只读查看流程进展，不接收任务、不产生审批记录，常用于质量、审计或管理层跟踪。

这四类角色的关键区别在于是否产生决策权重。审批人和会签人产生决策权重，知会人和观察者不产生。设计角色矩阵时，必须先把“谁决策、谁见证、谁只读”分清楚，再谈具体人员。

二、权限模型：角色权限与对象权限的叠加

Windchill的权限模型是基于角色和基于对象的叠加结果。一个用户在某个审批任务中能做什么，取决于两层：

1. 流程角色权限：由流程模板中的参与者配置决定，例如“审批人可完成任务”“知会人只能查看任务”。
2. 对象访问权限：由生命周期模板、文件夹权限、团队角色共同决定，例如审批人是否有权读取CAD文档、是否有权修改属性。

实际项目中常见的错误是：流程角色配了审批人，但该审批人对业务对象没有读取权限，结果任务打开后看不到内容，审批无法进行。因此，角色设计必须与对象访问控制一起验证，而不是只检查流程模板。

三、参与者解析规则：静态角色与动态角色

参与者解析规则决定“流程运行时，这个角色到底解析成谁”。Windchill中主要分为静态角色和动态角色两类。

静态角色是在流程模板中直接指定的用户或用户组。例如把“审批人”直接绑定到“张工”或“研发经理组”。优点是解析简单、结果可预测；缺点是人员变动后必须改模板，不适合组织频繁调整的场景。

动态角色则通过规则在运行时解析，常见方式包括：

• 按对象属性解析：例如“审批人 = 对象创建者的部门经理”。
• 按团队角色解析：例如“审批人 = 该对象团队中的‘设计负责人’”。
• 按组织关系解析：例如“会签人 = 该产品线下的所有质量工程师”。
• 按变量或上下文解析：例如“审批人 = 流程启动时选择的评审组组长”。

动态角色的优势是自适应组织变化，但代价是解析结果依赖数据质量。如果对象的“部门经理”字段为空，或团队角色未分配，流程就会在运行时找不到参与者，导致任务无法创建。

四、审批角色矩阵的设计方法

角色矩阵是把“流程节点”和“组织角色”交叉映射的工具。设计时建议按以下顺序推进：

1. 先列出流程中的决策节点，例如“设计评审”“工艺评审”“批准发布”。
2. 为每个节点确定决策类型：单人审批、多人会签、知会、观察。
3. 再根据组织架构，把每个决策类型映射到具体岗位或团队角色，而不是具体人名。
4. 最后检查每个映射是否有对象权限支撑，以及解析规则是否会产生空结果。

下面这张图展示了一个典型的审批角色解析链路：从流程节点出发，经过角色类型判断，再通过静态或动态规则解析到具体参与者，最终落到权限校验。

五、角色矩阵示例与落地检查

下面给出一个可直接参考的角色矩阵示例，适用于“设计评审—工艺评审—批准发布”三段式审批流程。表中“解析方式”一列明确标注静态或动态，便于后续维护。

落地时建议做三项检查：第一，空结果检查——对每个动态角色，确认解析字段在对象上一定有值，否则流程会卡在任务创建阶段；第二，权限交叉检查——审批人是否同时具备对象读取权和任务完成权；第三，会签比例检查——如果会签规则是“达到2/3通过”，要确认参与人数和比例在人员变动后仍然成立。

总结来说，审批体系的核心模型可以概括为一条链：流程节点 → 角色类型 → 解析规则 → 具体参与者 → 权限校验。静态角色保证确定性，动态角色保证适应性，权限模型保证安全性。三者配合得当，审批流程才能在组织变化中稳定运行，而不是每次人员调整都去改模板。