设计真正可运行的审批流程

本章目标：把审批制度设计成参与者明确、条件完整、异常可处理、版本可管理的流程，而不是只画一条从开始到结束的连线。

1. 先判断是否真的需要审批

审批的价值是让有责任的人作出正式业务决定，并保留决定过程。

适合审批：

• 支出授权；
• 合同或制度例外；
• 高风险操作；
• 需要多方正式确认的事项。

不一定需要审批：

• 系统自动计算；
• 只需要通知某人；
• 普通数据补充；
• 已批准后的执行工作；
• 没有“同意/不同意”含义的状态更新。

如果每个步骤都设计成审批，用户会陷入大量没有决策价值的“同意”操作。

2. 流程设计前必须具备的信息

开始画流程前应明确：

• 业务对象和状态；
• 谁可以提交；
• 提交前必须满足的条件；
• 哪些人有权作决定；
• 分支依据；
• 同意、退回、拒绝和撤回的业务含义；
• 流程结束后业务由谁接手；
• 找不到处理人和超时时怎么办。

这些信息缺失时，先回到业务分析，不要用随意选择的节点填补空白。

3. 用人话理解五个流程概念

概念	说明
流程设计	绘制的审批路线与每一步规则
发布版本	把当前设计冻结成可使用的一版
模板绑定	说明哪类业务记录在什么条件下使用这条流程
流程实例	某一条具体申请实际运行的一次审批
审批任务	流程到达某一步后，交给具体人员处理的待办

一条流程画好但没有发布、没有正确用于相应模板，业务用户仍然无法按它提交。具体操作参见审批流程快速上手。

4. 从提交入口开始设计

首先回答：

• 哪些状态允许提交；
• 谁可以提交；
• 提交前检查什么；
• 一条记录是否允许重复提交；
• 退回后重新提交是否从头开始；
• 撤回后如何处理；
• 提交成功后用户看到什么状态。

采购案例：

申请人可以从草稿或已退回状态提交。提交前必须至少有一行有效明细并得到总金额。提交成功后记录进入审批中，申请内容对申请人只读，并形成直属主管待办。

5. 设计审批节点

每个节点填写节点卡：

项目	直属主管审批示例
节点目的	判断采购是否必要且符合部门安排
处理人规则	申请人的直属主管
需要查看	申请人、用途、明细、总金额、紧急程度
可执行决定	同意、退回、拒绝
是否允许修改申请	不允许
同意结果	进入高金额判断或待采购
退回结果	申请人修改后重新提交
拒绝结果	业务终止，记录保留
时间要求	两个工作日内
无处理人	不允许静默跳过，提示管理员处理

节点名称应说明业务责任，例如“直属主管审批”，而不是“审批节点 1”。

6. 选择处理人规则

常见方式：

固定人员

适合非常稳定、明确由某个人处理的场景。人员变动时需要维护。

角色

适合“行政采购员”“财务审核员”等岗位职责。要明确角色中多人时由一人处理还是所有人处理。

组织关系

适合直属主管、上级部门负责人等随申请人变化的处理人。必须检查组织信息是否完整。

记录中的人员

适合项目负责人、指定经办人等由当前业务记录决定的处理人。要说明该人员何时确定、提交后是否允许改变。

无论哪种方式，都要回答找不到人、找到多人、人员离岗和代理时怎么办。

7. 单人、或签和会签

单人审批

只有一个明确处理人。

或签

多名候选人中任意一人处理即可。适合共享职责，但要接受“谁先处理由谁决定”的业务含义。

会签

多名人员都必须处理。要定义：

• 全部同意才通过，还是达到一定数量；
• 一人拒绝是否立即结束；
• 有人未处理时流程是否一直等待；
• 人员变化是否影响已产生任务。

不要因为“不确定谁负责”就随意选择或签。先解决责任设计。

8. 设计条件分支

采购案例：

提交
  ↓
直属主管审批
  ├─ 总额 ≤ 5000 → 待采购
  └─ 总额 > 5000 → 行政负责人审批 → 待采购

分支设计要确保：

• 条件使用的字段和时点明确；
• 所有可能输入都有去向；
• 条件互斥时不会同时命中；
• 条件有重叠时有明确优先级；
• 一条都不命中时有清楚提示或默认处理；
• 边界值已经确定。

条件配置和绑定可参考绑定与发起。

9. 明确同意、退回、拒绝、撤回和作废

动作	谁执行	业务含义	后续
同意	审批人	当前节点认可	进入下一节点或批准
退回	审批人	信息需修改后可再审	回到申请人修改
拒绝	审批人	本次申请不再继续	终止，保留记录
撤销提交	原提交人	在允许条件下收回自己的提交	回到本人的流程待办，保留原单据
作废	有权角色	业务已经没有继续意义	终止并说明原因

不要把它们都实现成“回到草稿”。它们对统计、权限和历史含义不同。

当前实现：撤销与回退

下一站仍全部待办、无人暂存或完成等条件满足时，原提交人可在已办中撤销；经过子流程或已经结束等情形不能撤销。撤销不销毁实例、不回滚提交字段。需要补正时由当前步骤按允许方式回退；直接结束后不能再重提。详见撤销与回退。

10. 退回后的规则

必须决定：

• 退回到申请人还是某个前置节点；
• 退回意见是否必填；
• 哪些字段允许修改；
• 修改后是否从头审批；
• 已同意节点是否需要重新处理；
• 金额变化跨越流程边界时如何处理；
• 退回后多久未修改是否需要提醒或作废。

采购案例中，建议第一版采用简单、可解释的规则：

任何审批节点退回后，由申请人修改并重新提交；重新提交按最新内容从第一审批节点重新开始。

11. 流程中的表单权限

不同节点可能需要不同的查看和修改范围：

• 申请人提交后不能改申请明细；
• 审批人可以填写意见，但不能代替申请人修改数量和金额；
• 行政采购员在批准后只能登记采购结果；
• 已完成记录只读；
• 应用管理员的管理权限不应被当成日常业务处理方式。

流程节点权限不能替代应用整体权限，两者需要一致设计。

12. 流程结束后发生什么

审批通过不是整个采购业务完成。

流程结束时应明确：

• 采购申请进入“待采购”；
• 当前责任转给行政采购员；
• 行政待采购视图出现记录；
• 申请人收到批准通知；
• 申请内容保持只读；
• 后续采购结果由业务操作完成，而不是继续堆审批节点。

流程应交付一个明确的业务结果给后续阶段。

13. 超时、催办、代理与交接

设计时回答：

• 每个节点期望多久完成；
• 什么时候提醒当前处理人；
• 谁可以催办；
• 谁能看见超时事项；
• 代理期间由谁处理；
• 人员离岗时在途任务怎样交接；
• 是否允许自动升级，依据是什么。

自动升级会改变责任，必须有明确制度依据；没有依据时，提醒和人工协调通常更安全。

14. 流程版本

发布新流程后，需要保护已在运行的旧申请：

• 已提交记录继续按提交时使用的版本处理；
• 新提交记录使用新版本；
• 重大变更前检查在途记录；
• 旧版本不能因为页面上不再使用就随意删除；
• 变更说明要记录条件、节点和处理人规则的变化。

具体操作参见流程发布与版本。

15. 流程测试矩阵

采购流程至少测试：

场景	金额	操作	预期
普通申请	4999.99	提交、主管同意	进入待采购
边界申请	5000.00	提交、主管同意	进入待采购
高金额	5000.01	主管同意	增加负责人审批
退回修改	6000	负责人退回，改为 4000 重提	按新金额重新选择路线
拒绝	任意	主管拒绝	终止且保留拒绝结果
撤回	任意	允许时撤回	回到草稿，无重复待办
无主管	任意	提交	明确失败并提示处理
重复点击	任意	连续提交两次	只形成一次有效审批

16. 常见错误

• 把所有业务步骤都画成审批；
• 处理人规则只考虑正常人员，没有空缺和多人情况；
• 分支条件有重叠或空白区；
• 退回、拒绝、撤回和作废含义相同；
• 流程结束后没有交给后续业务负责人；
• 修改金额后仍沿用旧路线；
• 新版本直接改变在途申请；
• 只测一路同意，没有测试边界和异常。

17. 本章完成标准

• [ ] 已确认哪些步骤真正需要审批；
• [ ] 提交状态、人员和前提明确；
• [ ] 每个节点都有目的、处理人、信息和结果；
• [ ] 人员缺失、多人、代理和交接有处理方式；
• [ ] 条件分支覆盖所有输入并明确边界；
• [ ] 同意、退回、拒绝、撤回和作废含义不同；
• [ ] 流程结束后的业务责任清楚；
• [ ] 已建立正常、边界、异常和重复操作测试。

下一步

流程决定谁在什么时候处理，权限决定谁能进入、查看和操作。下一章学习设计角色、权限与数据范围。