大多数审批流程要么藏在人的脑子里，要么埋在 wiki 的一段话里：「交给你经理，超过 5000 就还要财务。」正是这种模糊让请求卡住。审批流程图把这些没写下来的规则变成任何人都能照着走的图。
本文用一个真实的「请求到签批」流程作例子，讲解如何画一个。格式基础参见什么是流程图？和流程图符号指南。
审批流程图展示什么
一个好的审批流程图回答三个纯文字通常说不清的问题：
- 谁来审核请求，按什么顺序？
- 请求不完整或被驳回时会怎样？
- 批准后的请求最终去了哪里？
第二个问题是大多数人会忘的。一个线性的「提交 → 批准 → 完成」图不是审批流——是一厢情愿。真实的审批有驳回环，把它画出来才是关键。
分步讲解
下面是我们的审批流程图模板所画的流程，你可以拿它当自己流程的范本：
1. 开始 — 提交请求。 流程从有人提交请求开始：采购、内容稿件、预算、合同。
2. 完整性检查（判断）。 「信息完整？」如果否，请求进入修改请求步骤并回退——没人该审核一个不完整的请求。如果是，继续向前。
3. 经理审核。 第一个审批阶段。审核人评估完整的请求。
4. 审批判断（判断）。 「已批准？」这是核心分支：
- 是 → 处理并归档 → 已批准（终点）
- 否 → 回退到修改请求，让申请人针对反馈修改后重新提交
5. 应用门槛规则。 判断金额、风险、合同类型或数据敏感度是否需要额外审核。菱形里直接写「超过 5000 元？」比「是否需要额外审批？」更有用。
6. 设置时限和升级。 等待审核本身就是一个真实状态。增加 SLA 判断，把逾期事项发给提醒、代理人或升级负责人。
7. 结束并记录结果。 明确写出「批准并下单」「驳回并关闭」或「申请人撤回」等结果，同时记录请求版本、审批人、时间、决定理由和证据。
驳回时的回退环正是让它成为流程图而非清单的关键。用这个模板打开流程图工具，就能看到驳回箭头如何回退到修改步骤。
完整示例：采购申请
假设员工要采购一套年费 7500 元的分析软件。真正有用的审批流不只是把表单发给经理：
- 申请人提交业务用途、供应商、年费、预算编码、合同和数据访问要求。
- 入口检查确认必填项和附件齐全；缺资料先退回，不占用审批人的时间。
- 经理确认业务必要性和预算归属；驳回时必须带理由并形成新版本。
- 金额判断检查是否超过组织的 5000 元门槛；本申请超过，因此进入财务审核。
- 数据敏感度判断检查供应商是否处理客户或员工数据；若是，安全与法务可以并行审核。
- 财务批准支出，采购创建订单，系统写入完整决定记录。
- 申请人收到三个明确结果之一：批准并下单、驳回并关闭、退回修改。
这里有两种不同分支：业务规则分支改变谁需要审核，质量分支把不完整的工作退回修正。把两者区分开，未来金额门槛或政策变化时更容易维护。可以打开审批流程图示例对比不同布局。
画图前先写路由规则
先列一个简短决策表，能避免模糊判断，也能看出哪些审核可以并行：
| 条件 | 路由 | 必要证据 |
|---|---|---|
| 请求不完整 | 退回申请人 | 缺失项清单 |
| 预算内且低于门槛 | 经理审批 | 业务用途、预算编码 |
| 超过支出门槛 | 增加财务审核 | 报价和总成本 |
| 涉及敏感数据 | 增加安全与法务审核 | 数据流说明、合同 |
| 审核超过 SLA | 升级或转代理 | 提醒和升级时间 |
每一行要么变成带标签的判断分支，要么成为图外的校验规则。不要把整段政策塞进图里；图保持可读，再链接到详细制度。
用泳道明确负责人
如果大多数步骤由一个团队完成，普通流程图就够了；当关键问题是责任如何交接时，改用泳道。采购流程可以分为申请人、经理、财务、安全/法务、采购五条泳道。
操作要放在实际执行者的泳道，而不是收到通知的人那里。跨泳道箭头代表交接。如果财务和安全可以同时审核，就拆成并行路径，在所有必要决定完成后再汇合。
自动化很重要时，把系统与人分开。「工作流系统」泳道负责校验、提醒、时间戳和通知；人的泳道负责判断。这样既能看见自动化机会，也不会假装所有审批都能自动完成。其他布局可参考流程图类型。
把 SLA、代理和升级画出来
审批中最危险的状态往往不是驳回，而是没人处理。应明确表示等待：
- 完整请求进入审批人队列时开始计时；
- 截止前发送提醒，不要等逾期后才提醒；
- 允许指定代理，但保留实际决定人的记录；
- 逾期升级到角色或队列，避免升级给同样可能不在线的个人；
- 退回修改时暂停还是重启计时，要在 SLA 规则中写清楚。
除非制度明确允许，不要因为审批人超时就自动通过。支出、安全、法务或合规事项通常应该升级，而不是把沉默当成同意。
用真实请求验证流程
发布前拿三条记录走一遍：一次顺利批准、一次资料不全、一次高风险驳回。检查每个判断出口都有标签，每条退回线都写明修改什么才能重提，并行审核有汇合规则，每条路径都抵达有名字的结果。
还要确认每个等待状态都有负责人和时限，最后一步保存的信息足够还原当时的决定。再请一个没有参与设计的人沿图走一次；如果他必须口头询问才能选分支，就重写图上的规则。
常见错误
没有驳回路径。 如果你的图只画了顺利路径，那它记录的是你期望发生的，而非真实流程。每个审批判断都需要一条「否」分支。
判断出路没标注。 每个菱形出路都要标注——「是/否」「批准/驳回」。没标注的分支逼读者去猜。
跳过完整性检查。 把不完整的请求送进审核浪费审核人的时间。前面加一个快速的「信息完整？」关卡能拦住它。
审批层级太多。 如果一个请求要顺序经过五个审批人，图（和流程）就成了瓶颈。流程图往往让过度设计的审批链一目了然——这正是值得画它的理由。
何时用更简单的方式
如果一个负责人只检查一个条件并作出一次决定，简短清单或状态字段可能比多泳道图更清楚。存在分支、退回、金额门槛、并行审核或责任不清时，流程图才真正有价值。目标不是把每个行政动作都画出来，而是让关键路由变得可见。
常见问题
什么是审批流程图？
审批流程图是展示一个请求从提交、经审核到最终决定如何流转的图，包含信息缺失或被驳回时会发生什么。
审批流程图里怎么表现驳回？
用一个判断菱形（比如「已批准？」），它的「否」分支回退到「修改请求」步骤。修改后的请求再次进入审核。
审批流程应该设置多少级？
只保留控制真实风险所需的最少层级。增加审核人应该因为门槛或政策需要其专业判断，而不是单纯因为层级存在。
怎么避免审批请求一直卡住？
给每个等待状态指定负责人和 SLA，在截止前提醒，支持代理，并把逾期事项送到升级队列。
审批审计记录应包含什么？
保存请求版本、申请人、审批人、决定、时间、理由、证据和采用的政策规则。
想梳理自己的流程？从审批流程图模板开始——它已经预置了请求、审核和驳回回退结构，无需注册。
