第4章 审批流程角色定义：申请人、审批人、会签人、知会人、驳回节点
4.1 适用场景
在B端审批流程建模中，角色定义是构建泳道图的基础。本章定义的5种角色适用于以下典型场景：
- 多级审批流程：需要逐级审核的采购申请、合同审批、费用报销等业务。
- 协同决策场景：需要多人共同签署确认的财务会签、技术评审、法务审核等。
- 信息同步场景：审批结果需要抄送或通知相关方的HR备案、项目变更知会等。
- 异常回退场景：申请材料不符合要求时，需要驳回至指定节点重新处理的流程。
- 跨部门协作流程：涉及多个职能部门（如行政、财务、法务、技术）协同审批的复杂流程。
判断标准：当流程中存在“发起→审核→确认→通知→回退”五个环节中的至少三个时，就需要明确定义本章所述的角色类型。
4.2 前置条件
在定义审批流程角色之前，需要完成以下准备工作：
| 序号 | 前置条件 | 说明 |
|---|---|---|
| 1 | 流程范围界定 | 明确要建模的审批流程起止边界，识别流程涉及的所有部门与岗位 |
| 2 | 组织架构梳理 | 获取当前组织架构图，明确汇报关系、部门职责与岗位职级 |
| 3 | 审批规则文档 | 收集或起草审批制度文件，包括审批权限表、会签规则、知会范围等 |
| 4 | 流程节点清单 | 列出流程中所有操作节点，标注每个节点的预期处理角色 |
| 5 | BPMN建模工具就绪 | 确认已安装或可访问BPMN建模工具（如Camunda Modeler、Signavio、Draw.io BPMN插件等） |
4.3 操作步骤
在BPMN泳道图中定义审批流程角色的操作步骤如下：
- 绘制泳道容器：在BPMN画布中创建Pool（泳池），代表整个审批流程系统；在Pool内部按部门或角色划分Lane（泳道）。
- 创建申请人泳道：将第一个Lane命名为“申请人”，拖入Start Event（开始事件）并标注“提交申请”，此泳道通常位于最上方或最左侧。
- 创建审批人泳道：新建Lane命名为“审批人”，依据审批层级数量可拆分为“一级审批人”“二级审批人”等子泳道，放置User Task（用户任务）节点。
- 创建会签人泳道：若需要多人签署，新建Lane命名为“会签人”，在会签节点上添加Multi-instance（多实例）标记，配置会签完成条件（如“全部通过”或“多数通过”）。
- 创建知会人泳道：新建Lane命名为“知会人”，在流程末端放置Send Task（发送任务）或Intermediate Throw Event（中间抛出事件），配置通知模板与接收人列表。
- 配置驳回节点：在审批人泳道的User Task下方添加Boundary Event（边界事件），类型选择Intermediate Catch Event（中间捕获事件）并标记为“驳回”，通过Sequence Flow（顺序流）连接至目标节点（申请人或前序审批人）。
- 标注角色职责说明：在每个Lane的注释区域或节点属性中，填写该角色的具体职责描述、操作时限、权限范围等元数据。
关键原则：每个Lane代表一个独立责任主体，同一角色出现在多个泳道时应拆分为不同Lane；驳回节点的目标泳道决定了“驳回至谁”，须在流程图中明确标注。
4.4 输入输出物
| 类型 | 输入物 | 输出物 |
|---|---|---|
| 文档类 | 审批权限表、组织架构图、审批制度文件 | 角色定义矩阵表、泳道图草图、角色职责说明书 |
| 模型类 | 流程节点清单、审批规则文档 | 标注角色的BPMN泳道图（.bpmn文件或等价格式） |
| 配置类 | 会签规则、知会人列表、驳回路径规则 | 角色权限配置表、会签条件表达式、通知触发器配置 |
| 验证类 | 角色定义评审意见、试点流程反馈 | 角色定义验收报告、流程仿真日志 |
4.5 责任边界
每种角色的职责边界定义如下，用于避免职责重叠或流程空挡：
| 角色 | 核心职责 | 操作权限 | 禁止行为 |
|---|---|---|---|
| 申请人 | 填写申请信息、提交申请、补充或撤回申请 | 查看申请进度、修改申请内容（未审批前） | 不可自审自批、不可修改已审批的申请内容 |
| 审批人 | 审核申请内容、做出通过/驳回决策、填写审批意见 | 查看申请详情、通过/驳回/转办/加签 | 不可跳过审批层级、不可修改申请内容 |
| 会签人 | 协同审核、签署确认、补充会签意见 | 查看申请详情、签署通过/拒绝、查看其他会签人意见 | 不可单独否决流程（会签规则决定最终结果） |
| 知会人 | 接收审批结果通知、确认已阅、必要时执行后续动作 | 查看审批结果、查看审批意见摘要 | 不可干预审批决策、不可修改申请内容 |
| 驳回节点 | 记录驳回原因、触发驳回后流程、通知相关角色 | 配置驳回目标节点、设置驳回条件、记录驳回日志 | 不可无限循环驳回（须设置最大驳回次数） |
常见误区：会签人与审批人职责重叠时，必须在流程图中明确标注“会签节点”与“审批节点”的先后顺序和通过条件，否则会导致流程卡死或决策权争议。建议在会签节点前增加并行网关（Parallel Gateway）或包容网关（Inclusive Gateway）来分流。
4.6 异常处理
| 异常场景 | 可能原因 | 处理方案 |
|---|---|---|
| 申请人提交后流程无响应 | 审批人泳道未配置实际用户或角色映射缺失 | 检查Lane的“角色分配”属性，确保绑定到具体的组织单元或用户组 |
| 会签节点长期未完成 | 会签人中某位未及时处理，且无超时机制 | 为会签节点添加定时边界事件（Timer Boundary Event），设置超时自动流转或通知管理员 |
| 知会人未收到通知 | 知会人泳道使用Send Task但未配置消息通道或接收人列表失效 | 确认知会人的消息通道（邮件/系统消息/短信）配置正确，并设置消息重试机制 |
| 驳回后流程陷入死循环 | 驳回节点目标设为申请人，但申请人重新提交后再次被同一条件驳回 | 设置驳回次数计数器，达到上限后自动转交人工处理或升级至更高层级审批人 |
| 角色权限冲突 | 同一用户同时属于申请人泳道和审批人泳道，导致自审自批 | 在BPMN模型中增加排除规则：申请人不可出现在审批人泳道的候选列表中，或通过脚本任务校验 |
最佳实践：建议在驳回节点后增加人工处理任务（Manual Task），由流程管理员判断驳回原因是否合理，避免系统自动驳回导致的死循环。同时，为每个角色配置代理规则，防止角色缺席时流程阻塞。
4.7 验收标准
完成审批流程角色定义后，需按以下标准进行验收：
- 角色完整性：流程图中包含且仅包含本章定义的5种角色类型（申请人、审批人、会签人、知会人、驳回节点），无多余或遗漏角色。
- 泳道对应性：每个角色拥有独立的Lane，Lane名称与角色名称一致，且泳道内节点类型与角色职责匹配（如申请人泳道包含Start Event，审批人泳道包含User Task）。
- 会签规则可执行：会签节点的Multi-instance配置完整，会签通过条件（全部通过/多数通过/比例通过）已明确标注且可被流程引擎解析。
- 驳回路径可追溯：驳回节点的目标节点在图中清晰标注，驳回条件（如“材料不齐”“审批拒绝”）已定义，驳回次数限制已配置。
- 知会通道有效：知会人泳道的通知任务已配置消息模板和接收人映射，经测试可正常发送和接收通知。
- 边界条件覆盖：对“驳回后重新提交”“会签超时”“知会失败”等异常场景均有对应的边界事件或补偿机制。
验收交付物：完整的BPMN泳道图文件（含所有角色泳道及节点）、角色职责说明书（一人一页）、会签规则配置表、驳回路径矩阵、知会人通知模板。以上交付物需通过流程干系人评审签字。