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