系统流程图栏目 ·

审批流程图怎么画：串签/会签/或签的画法与节点模板

把审批规则画成“能落地”的流程图：讲清串签/会签/或签的区别与画法，给出节点命名规范、异常分支、超时升级与变更重审等关键细节，并提供文本生成流程图与导出交付入口。

审批流程图最难的往往不是“画得好看”，而是把审批规则写得足够明确：谁在什么条件下审批？多人审批是全票通过还是任意一人通过？驳回后回到哪里？超时怎么办？申请内容变更要不要重走审批？

如果你希望这张图能直接变成 PRD、配置单甚至开发任务的输入，建议用一种更工程化的做法：先把节点与条件写成结构化文本，再让工具自动排版成图，最后再做少量美化。

下文会按“教程百科 + 可落地交付”的方式，系统讲清：串签/会签/或签的画法、节点命名规范、异常与边界条件、以及一份你可以直接用于评审的检查清单。

1. 先把“审批流程”讲清楚：你画的到底是哪一层？

很多审批流程图画到一半就乱，原因是把不同层的东西混在一张图里。

建议你在开画前先确定这张图的层级（画太大必乱，画太小不落地）：

  • 业务层（Why/What）：为什么要审批、审批覆盖哪些风险点（合规/预算/权限/审计）。
  • 规则层（Policy）：谁审批、什么条件触发、怎样算通过、超时/驳回/撤回怎么处理。
  • 系统层（How）：哪些页面/接口/任务队列/消息通知参与；数据表与权限校验在哪里。

本文聚焦在“规则层 + 可交付的系统表达”：让图能直接支撑配置、开发与验收。

2. 审批流程图里必须出现的 8 个核心要素（少一个都容易翻车）

你可以把审批流程理解为一段“受控的状态机”。为了可落地，建议至少在图或旁注里覆盖这些要素：

  1. 发起人（Initiator）：谁能发起？是否允许代提交？
  2. 审批对象（Object）：申请单/合同/费用/权限申请等，它的关键字段有哪些（金额、类型、部门、项目）。
  3. 审批人来源（Assignee Source）：按组织树？按角色？按表单字段（例如项目负责人）？
  4. 通过规则（Pass Rule）：串签/会签/或签，以及会签的“全票/多数/按权重”规则。
  5. 驳回与退回（Reject/Return）：驳回是结束还是回到某节点修改后重提？
  6. 撤回与取消（Withdraw/Cancel）：在什么状态可撤回？撤回后审计怎么记录？
  7. 超时与升级（Timeout/Escalation）：多久算超时？提醒几次？升级给谁？
  8. 变更触发重审（Change & Re-approve）：申请内容变更（金额、收款方、条款）是否触发重新审批？触发规则是什么？

经验：画审批流程图时，不要把“通知、抄送、归档”当作主干节点塞满整张图。它们通常以事件/旁注表达更清晰。

3. 串签 / 会签 / 或签：定义、适用场景、以及在图上怎么画

这三个概念看似简单，但最常见的坑是：规则在嘴上，图上却表达不出来。下面给你一套“画法对照”。

3.1 串签（Serial Approval）：按顺序一个个来

定义：审批人按固定或可计算的顺序依次处理；前一位通过后才到下一位。

适用场景：

  • 多级管理审批（主管 → 部门负责人 → 分管领导）
  • 先业务后合规（业务负责人 → 法务/合规 → 财务）

图上画法：

  • 直接用“任务节点串联”即可；每个节点标清楚审批人来源。
  • 若某一步可能跳过（例如“金额 < 5000 跳过总监”），一定用判断网关把跳过条件画出来，而不是写一句“可能不需要”。

落地提示：串签在系统实现里通常意味着“下一节点的候选人需要在上一节点完成后才能计算”，尤其涉及组织树、代理、临时授权时。

3.2 会签（Parallel Approval / Countersign）：多人同时审

定义：同一环节需要多人审批，通常并行进行；满足某个通过规则后进入下一步。

会签最关键的是把“通过规则”明确写出来：

  • 全票通过：所有人同意才算通过（常见于合规/安全类）。
  • 任意一人通过：只要有人同意就通过（这更像或签，见下）。
  • 多数通过：超过 50% 同意通过（常见于评审委员会）。
  • 按权重通过：不同角色权重不同（复杂但真实存在）。

图上画法（推荐）：

  1. 用一个“并行分支（并行网关）”把审批任务拆成多个并行任务。
  2. 用一个“汇聚节点（并行汇聚）”把分支收回来，并在汇聚处标注通过规则（例如：全部同意 / ≥2/3 同意）。
  3. 明确一票否决是否存在：如果任意一人拒绝就直接结束/退回，需要画出拒绝分支。

落地提示：会签会引出三个实现细节，最好在图旁注：

  • 是否允许“部分人未处理但已满足通过规则就提前进入下一步”（例如多数通过后自动结束未处理人的任务）。
  • 未处理人的任务如何处理（自动取消 / 标记为无需处理 / 保留审计记录）。
  • 并行任务的超时与提醒是否独立计算。

3.3 或签（Any-of Approval）：多个候选人，任意一人处理即可

定义：候选审批人是一组人，但不要求所有人都审；谁先处理就算。常见于“值班组/共享队列/同岗互备”。

适用场景：

  • 客服主管组、值班经理
  • 财务共享中心的出纳/会计池

图上画法：

  • 用一个任务节点表示“审批（候选人：A/B/C 任一）”，旁注“处理人抢占/认领”。
  • 或者用“事件/中间事件”表达“被任一人认领后进入处理”。

落地提示：或签要画清楚两个问题：

  • 认领机制：先到先得，还是按负载分配？
  • 并发冲突：两人同时点通过怎么办（幂等/乐观锁）？这在验收时经常被问。

4. 一套可复用的画法：6 步把审批流程画到“能评审、能开发、能验收”

第 1 步：定义边界（这张图不画什么）

写在图的开头或注释里：

  • 不画 UI 细节（按钮、弹窗文案），只画状态与规则。
  • 不画消息渠道差异（短信/邮件/飞书），统一写“通知”。
  • 不画所有异常，只画“对业务风险有影响”的异常（例如驳回、超时、重审）。

边界明确后，图会立刻干净一半。

第 2 步：画泳道（角色与责任）

审批类流程强烈建议用泳道图：

  • 发起人
  • 审批人（按角色拆：直属主管/部门负责人/财务/法务）
  • 系统（自动任务：校验、生成编号、通知、归档）

泳道的意义不是“好看”，而是强制你回答：这个动作是谁负责。

第 3 步：先画主干（Happy Path 控制在 5～9 个节点）

主干节点太多会让评审变成“读图考试”。建议先画最常见的一条路：

  • 提交申请 → 校验 →（串签/会签/或签）→ 通过 → 生效/归档

细节（抄送、消息、日志）先别塞进主干。

第 4 步：补 3 类必画异常：驳回/撤回/超时升级

审批流程可落地与否，往往取决于异常分支。至少把这三类画出来：

  • 驳回：结束？退回修改？退回到哪个节点？
  • 撤回：哪些状态可撤回？撤回是否需要审批人确认？
  • 超时升级：提醒次数、升级对象、升级后是否自动通过/自动驳回（通常不建议自动通过）。

第 5 步：把“规则”落到判断网关：条件要可计算

判断条件建议满足两点：

  • 可计算：来自表单字段/组织关系/权限配置，而不是“看情况”。
  • 互斥且穷尽：分支要覆盖所有情况，避免“漏网之鱼”。

写法建议：

  • ✅ 金额 >= 5000、类型 in {采购, 合同}、发起人部门 = 审批人部门
  • ❌ 金额较大、重要合同、特殊情况

第 6 步：用检查清单做一次“落地审查”

文末给了清单，你可以直接拿去做评审，快速定位缺口。

5. 节点命名与符号规范：让读图的人不需要猜

5.1 节点命名：用“动词 + 对象 + 结果”

审批流程图里，节点名如果都是“审批/处理/操作”，读者只能靠上下文猜。

推荐命名格式：

  • 提交申请（生成单号）
  • 主管审批（同意/驳回）
  • 财务复核（校验预算/发票）
  • 系统：写入审批记录（审计日志）

如果一个节点里包含多个动作，拆分原则是：

  • 会影响下游判断的动作（例如“校验预算”）尽量单独成节点或旁注。
  • 纯展示/纯通知可以合并。

5.2 常用符号（按“能交付给开发”的标准）

  • 开始/结束：明确触发与终态（例如“已生效/已归档/已取消”）。
  • 任务节点：人做的事；旁注审批人来源与权限。
  • 判断网关：条件必须可计算；分支标注清楚（是/否、不通过/通过）。
  • 事件/定时：超时提醒、自动升级、自动撤销等。
  • 数据对象（可选）：关键产物（审批单、合同附件、付款指令）。

小技巧：如果你经常被问“这个节点到底是人做还是系统做”，那就说明泳道或节点标注还不够清晰。

6. 变更与重审：审批流程图里最容易被忽略、但最要命的一段

真实业务里，审批不是一次性的。常见情况：申请人在审批中途改了金额、改了供应商、改了合同条款。到底要不要重审？重审从哪里开始？

建议在图中增加一个明确的规则（用判断网关或旁注表达）：

  • 允许变更的字段范围（例如备注/附件可改，金额不可改）。
  • 变更触发重审的阈值（例如金额变化 > 10% 或跨越 5000/20000 档位）。
  • 重审的起点：从第一个审批人开始，还是从受影响的审批环节开始。
  • 已产生的审批意见如何处理：保留但标记为“针对旧版本”。

这段规则一旦缺失，后续一定会出现“图上没说、线上扯皮”的情况。

7. 只给 1 个小例子：把“串签 + 会签 + 异常”写成可生成的文本

下面这个例子是“费用报销”的简化版，用来演示画法（不追求业务完整）。你可以把它当成你自己业务的骨架，替换节点名称与条件。

你也可以直接把类似结构的文本丢进工具，让它自动排版，再按你公司的术语微调：

示例（仅 1 个）：

开始 -> 提交报销申请(员工)
提交报销申请 -> 系统校验(必填/预算/附件)
系统校验 -> 判断 金额>=5000?
判断 金额>=5000? -> 主管审批(串签) : 否
判断 金额>=5000? -> 部门负责人审批(串签) : 是
部门负责人审批 -> 主管审批
主管审批 -> 会签 财务复核+出纳复核(全票通过)
会签 财务复核+出纳复核 -> 结束 通过(生成付款指令)
主管审批 -> 结束 驳回(退回修改)
会签 财务复核+出纳复核 -> 结束 驳回(退回修改)
系统校验 -> 结束 失败(提示补充材料)

你会发现：当你能把流程写成这种“节点 + 条件 + 结果”的文本时，图基本就不会歪到哪里去；反过来，如果你写不出来，大概率规则也还没想清楚。

8. 常见错误与反例：审批流程图为什么“看起来很对，实际没法用”

错误 1：把会签画成串签（或反过来）

  • 反例：画成一条直线，但文字说“财务和法务并行审批”。
  • 修正：并行必须有“分支 + 汇聚”，并在汇聚处写清通过规则。

错误 2：条件写成主观词（无法计算）

  • 反例：金额较大、重要客户。
  • 修正：写成阈值或枚举：金额>=20000、客户等级 in {A,B}。

错误 3：驳回回路不清楚

  • 反例：只画一个“驳回”终点，但业务上实际需要修改后重提。
  • 修正：明确是“结束驳回”还是“退回到提交/退回到某审批节点”，并说明是否保留历史版本。

错误 4：缺少超时与升级

没有超时，你的系统就会出现“卡单”。建议至少定义：

  • 超时阈值（例如 24h）
  • 提醒次数（例如 2 次）
  • 升级对象（主管的主管/值班经理/审批管理员）

错误 5：审批人来源不明确

“领导审批”不是规则。至少明确一种可配置的来源：

  • 组织树：直属主管/部门负责人
  • 角色：财务经理、法务专员
  • 字段：项目负责人（来自表单选择）

9. 可交付的审批流程设计清单（评审/开发/验收都用得上）

把下面清单当作你画完图后的“自测题”：

9.1 规则完整性

  • 发起条件是否明确（谁能发起、哪些单据类型）
  • 审批人来源是否可计算/可配置
  • 串签/会签/或签是否表达清楚，尤其是会签的通过规则
  • 驳回/退回的去向明确（回到哪个节点）
  • 撤回/取消的允许状态与后果明确
  • 超时提醒与升级规则明确
  • 变更触发重审的规则明确（字段范围/阈值/重审起点）

9.2 系统落地性

  • 状态枚举是否清晰（草稿/审批中/已通过/已驳回/已取消/已超时等）
  • 是否需要幂等（重复点击同意、网络重试、并发处理）
  • 审计日志字段是否定义（谁在何时对哪个版本做了什么决定）
  • 权限校验点是否明确（谁能看、谁能催办、谁能加签/转交）
  • 通知策略是否可控（触发点、接收人、频率）

9.3 交付与沟通

  • 图上是否写清关键术语（串签/会签/或签）与公司内部叫法的映射
  • 是否能在 1 分钟内向新人讲明白主干流程
  • 是否提供导出交付格式（PNG 给评审、draw.io 给二次编辑）

10. 导出与交付：怎么把流程图交到别人手里还能保持清晰

如果你要把审批流程图放进 PRD、Confluence、飞书文档或投到评审群里，建议：

  • PNG：适合阅读与评审；导出时选择更高分辨率（2x/3x），字体用常见无衬线。
  • draw.io：适合协作与二次编辑；建议把泳道、网关、注释分组，方便后续调整。

你也可以用“文本 → 图”的方式留一份源文本，作为可审计的版本控制素材（git 更友好）：

FAQ：串签/会签/或签的高频问题

Q1：会签里有人一直不处理怎么办？ A：在图上补“超时提醒 → 升级”分支，并明确多数通过时是否提前结束未处理人的任务（审计要保留）。

Q2：或签和会签怎么区分？ A：或签是“多人候选，任一人处理即可”；会签是“多人都要参与（按规则统计）”。图上一个是单节点+候选人集合，一个是并行分支+汇聚规则。

Q3：能不能画‘加签/转交’？ A：能，但建议作为旁注规则或扩展流程，否则主图会爆炸。至少写清：谁有权限加签、加签是否影响通过规则、转交是否保留原审批人痕迹。

Q4：驳回后重新提交，要不要从头审批？ A：看风险。一般“关键字段变更/跨档位”从头走；仅补附件可从当前节点继续。把规则写成可计算条件，避免口头争议。

Q5：审批意见和附件怎么在图里表达？ A：不建议每个节点都画“填写意见/上传附件”。你可以用数据对象或旁注：审批意见（必填/选填）、附件校验规则。

Q6：如何让审批流程图更适合开发？ A：在图旁加一小段“状态机说明”（状态枚举 + 触发事件），并标注哪些动作是系统自动、哪些需要人工操作。

Q7：审批通过后一定要归档吗？ A：建议有“归档/审计记录写入”这一类系统节点（可以合并），因为它决定后续追溯与合规能力。

Q8：审批流和工作流引擎有什么关系？ A：审批流是工作流的一类。你先把规则画清楚，再决定用引擎配置、还是自研状态机。图清楚了，两条路都能走。

Q9：一张图放不下怎么办？ A：把主干控制在 5～9 节点，把“加签/转交/特殊条款”等做成子流程（单独一张图或附录），主图只保留入口与出口。

Q10：怎么看图就知道是否容易卡单？ A：检查是否存在“无人负责的节点”“无超时升级的会签汇聚”“无法计算的条件”。这三类几乎必卡。

如果你接下来要快速把自己的审批规则转成一张可交付的流程图，推荐你先写出“节点 + 条件 + 结果”的文本，再用工具自动排版，最后再按公司规范调整术语与泳道：

流程图在线制作 - AI生成 | 自动排版