流程图设计规范
泳道 · 节点 · 全景 · 分层分级 · 实战费用报销 — 对标五大咨询 + BPMN 2.0
核心原则: 「一张图讲清楚一件事」 · 所有标准以 BPMN 2.0 规范为基准,咨询机构惯例为参考
第一章:泳道图 · 角色/部门数量标准
1.1 各机构标准对照
| 机构 | 最佳 | 硬上限 | 超标处理 |
|---|---|---|---|
| McKinsey | ≤5 | 5 | 拆子流程 |
| BCG | 4-6 | 7 | 改为流程架构图 |
| Deloitte | 3-5 | 6 | 合并角色池+RACI |
| Accenture | ≤5 | 7 | Role Clustering |
| 华为 IPD | ≤5 | 6 | 改用角色矩阵 |
1.2 员工和主管分两个泳道
发起(信息输入)和审批(决策输出)是两种不同职责。按决策权划分泳道,非按组织架构。
第二章:流程节点数量标准
2.1 各机构标准
| 机构 | 最佳 | 上限 |
|---|---|---|
| McKinsey | 7-10 | 12 |
| BCG | 8-15 | 15 |
| Deloitte | 6-10 | 12 |
| Accenture | 8-12 | 12 |
| 华为 IPD | 5-15 | 15 |
| BPMN 2.0 OMG | 7-9 | 12 |
2.2 节点计数
计为节点: 活动、网关、中间事件、子流程折叠块
不计为节点: 开始/结束事件、文本标注、数据对象、跨页连接符
第三章:泳道图 · 详细画法规范
3.1 菱形分支数量
XOR 网关可以有多条条件出线。BPMN 2.0 无分支数量硬性上限,但行业通行做法:3条以内最佳,4条为上限,超过考虑嵌套或决策表。
3.2 菱形放在哪个泳道
放在规则归属部门的泳道内。业务方交付件中菱形可放在触发该判断的角色泳道,标注⚙表示系统自动。
3.3 菱形之间可以插任务节点
BPMN 2.0 关键确认: Gateway → Task → Gateway 是合法的结构。Sequence Flow 可连接任意 Flow Node(Activity、Gateway、Event)。所谓"同一条件域的两个菱形之间不能插节点"——BPMN 2.0 没有这条规则。
3.4 Gateway Chaining
两个菱形直接连接(中间无节点)也是合法的,称为网关串联。条件线直接连接两个 Gateway。
3.5 连接线规范
线交叉用桥线标记,横线不超过8节点宽度,返回线标注条件。
3.6 节点与节点之间的连接规则
一个节点可以有多个下一步(分流)。
[A] ──→ [B]
[A] ──→ [C]
[A] ──→ [D]
一个节点可以有多条出线(Sequence Flow)。条件出线根据条件真假触发;无条件出线作为默认路径。
多个节点可以汇聚到同一个下一步(汇聚)。
[A] ──┐
├──→ [D]
[B] ──┘
一个节点可以有多条入线。三条路径汇聚到同一个节点是标准的 BPMN 2.0 结构。以费用报销案例为例:≤1万、1-5万、>5万三条路径最终汇聚到同一个合规终审和出纳付款节点。
BPMN 2.0 标准: 节点可以有零到多条入线和出线,无数量上限限制。Task 间通过 Sequence Flow 连接,每条 Flow 代表一个独立路径。咨询项目中,出于可读性考虑,一屏内入线/出线数量建议不超过 4-5 条,超过建议用汇聚/分流网关。
第四章:全景图
McKinsey三层式(价值流/里程碑/KPI)、BCG漏斗式、Deloitte分层式(战略/流程/使能)。上限5-7阶段。
第五章:分层分级
L1(流程域,3-5域)→ L2(流程组,4-7组)→ L3(子流程,5-15节点) → L4(活动,3-9操作)→ L5(步骤,≤5动作)。华为加L6(指令,无需视图)。
严禁混层: 一张图只画一个层级。
第六章:汇总速查
| 维度 | 最佳 | 上限 |
|---|---|---|
| 泳道数 | 3-5 | 6-7 |
| 节点数 | 7-12 | 15 |
| 菱形分支 | ≤3 | 4 |
| 菱形位置 | 规则归属部门泳道 | — |
第七章:实战案例——费用报销流程设计
以费用报销为案例,运用前述规范。核心关注:双重金额分判、逐级审批不跳级、驳回路径处理、BPMN 2.0 结构合法性验证。
7.1 泳道图(文本描述)
泳道(5道): 员工 / 部门主管 / 财务部 / 管理层(总监/总经理)/ 出纳
流程路径(文本示意):
员工提交报销申请
↓
主管审批(是否真实·是否必要)
↓
◇≤1万?(财务部泳道)
├── ≤1万 ────→ 合规终审(财务部)──→ 出纳付款
│
└── >1万 ────→ 总监审批(管理层泳道)
↓
◇1万-5万?(管理层泳道)
├── 1-5万 ──→ 总监审批(2) ──→ 合规终审 ──→ 出纳付款
└── >5万 ──→ 总监审批(3) ──→ 总经理审批 ──→ 合规终审 ──→ 出纳付款
注: 完整 SVG 泳道图请查看同目录的 HTML 版本文件。
7.2 设计逻辑
| 问题 | 答案 | 依据 |
|---|---|---|
| 为什么两个菱形? | 分两层路由:先≤1万/>1万,再在>1万里分1-5万/>5万。条件区间不重叠。 | BPMN 2.0 合法 |
| 两个菱形之间是什么? | 总监审批(任务节点)。◇ → Task → ◇ 合法。 | BPMN 2.0 Sequence Flow 可连任何节点 |
| 总监审批画几个? | 两个——1-5万路径一个,>5万路径一个。路径独立完整。 | 面向业务方交付件通行做法 |
| 菱形放哪个泳道? | 财务部泳道。金额分判规则由财务维护。 | 规则归属部门泳道 |
| 菱形前一个节点? | 第一层:主管审批。第二层:总监审批。 | 判定前一个完成节点 |
| >5万跳不跳级? | 不跳。先总监审批,再总经理审批。 | 逐级审批原则 |
7.3 三条审批路径
| 金额 | 完整审批链 |
|---|---|
| ≤1万 | 提交 → 主管审批 → ◇≤1万? → 合规终审 → 出纳付款 |
| 1万-5万 | 提交 → 主管审批 → ◇>1万 → 总监审批 → ◇1-5万? → 总监审批 → 合规终审 → 出纳付款 |
| >5万 | 提交 → 主管审批 → ◇>1万 → 总监审批 → ◇1-5万? → 总监审批 → 总经理审批 → 合规终审 → 出纳付款 |
7.4 BPMN 2.0 结构验证
从 Camunda(BPMN 2.0 参考实现)官方文档确认: ① XOR 网关可有多条条件出线,所有出线按定义顺序评估,条件为 true 的被选中 ② Sequence Flow 的目标节点可以是任何 Flow Node(Task、Gateway、Event) ③ ◇ → Task → ◇ 是合法的 BPMN 2.0 结构 ④ 同一角色(总监审批)在两条路径上各出现一次,BPMN 2.0 无限制
7.5 驳回路径的处理
主泳道图只画正常路径。驳回、退回、异常归入《异常流程图》或 SOP。行业通行做法:高频短循环(1-2步内)可考虑在主图标注退回箭头,低频驳回和长循环不入主图。
附录:核心理念对比
| 机构 | 核心理念 | 适用范围 |
|---|---|---|
| BPMN 2.0 OMG | BPMN 2.0 规范定义流程建模的标准符号和规则 | 所有 BPMN 建模工具的最低合规标准 |
| McKinsey | "One page, one message" — 对客户交付的流程图规范 | 咨询项目交付件 |
| BCG | "Layer & Link" — 分层条件路由 | 流程诊断与再设计 |
| Deloitte | "Process = System" — 流程设计需可落地到系统 | 系统实施类项目 |
| Accenture | "Role Clustering" — 角色压缩优化泳道 | 大规模流程梳理 |
| 华为 IPD | "Level 3 is King" — L3 是业务负责人看流程的最佳层 | 企业流程体系建设 |
文档编制:JJ 参考来源:OMG BPMN 2.0 规范、Camunda BPMN 参考文档、McKinsey/BCG/Deloitte/Accenture/华为 IPD 流程设计方法论