泳道、节点、全景与分层分级

对标机构：McKinsey、BCG、Deloitte、Accenture、IBM、华为 IPD、OMG BPMN 2.0 适用场景：流程设计、流程图绘制、流程文档评审、流程治理体系搭建 核心原则：「一张图讲清楚一件事」

第一章：泳道图 · 角色／部门数量标准

1.1 各机构标准对照

1.2 为什么是 5 个？

• 7±2 认知负荷法则（Miller's Law）：人眼一次能跟踪的信息块上限
• McKinsey 验证：超过 5 个泳道的图，业务方 60% 以上读第二遍才能跟上
• Deloitte 理由：如果流程图最终要落地到系统权限配置，6 道以上就是一场配置灾难
• 华为 IPD 实证：380 多个 L3 级流程中，没有任何一张泳道图超过 6 道

1.3 超过 5 个时的三种处理方案

方案 A：垂直切分（推荐）

把大流程按阶段拆成 2-3 个子流程，每个子流程重新画泳道图：

原流程（8 个角色）→ 无法阅读

    拆：
    阶段1「触发→评审」   → 5 个角色 × 3 张图
    阶段2「方案→审批」   → 4 个角色 × 3 张图
    阶段3「执行→交付」   → 3 个角色 × 2 张图

方案 B：角色聚合（Accenture Role Clustering）

把角色按照"职责类型"压缩：

前提：聚合后的角色在流程中的行为模式一致——都是先后顺序、同样的分支判断，才能合。如果行为不同则不能合。

方案 C：泳道 + RACI 互补（Deloitte 做法）

• 泳道图上只画 5 个核心角色
• 次要角色在旁边用 RACI 矩阵标注各自的参与模式

                  ┌──────────────────────────────────────┐
                  │  # │ 角色         │ R │ A │ C │ I   │
                  │  1 │ 信息管理员   │ R │   │   │     │
                  │  2 │ ERP 管理员   │   │   │ C │     │
                  │  3 │ 审计员       │   │   │   │ I   │
                  └──────────────────────────────────────┘

第二章：流程节点数量标准

2.1 各机构标准对照

2.2 节点计数规则

计为节点

不计为节点

2.3 超标后的拆分方法（McKinsey/Bain 两刀法）

第一刀：按阶段拆

阶段1「触发→初评」：6 个节点
阶段2「方案→审批」：5 个节点
阶段3「执行→交付」：4 个节点

第二刀：按角色拆

核心执行池（3 个角色 × 3-4 个动作）
辅助支撑池（另画一张，2-3 个角色 × 2-3 个动作）

BCG 的天然断点识别法

寻找流程中的天然断点，在其处拆分：

• 审批关口（Gate Review）
• 阶段交付物（Phase Deliverable）
• 系统切换点（System Handoff）
• 组织/部门交接点

第三章：泳道流程图 · 详细画法规范

3.1 基础画法

泳道方向

五大咨询普遍使用水平泳道，从上至下按角色/部门排列，从左到右按时间线展开。

泳道排列顺序（McKinsey 标准）

┌─────────────────────────────────────────────────────┐
│ 客户 / 外部角色          ← 最上方（触发源）           │
├─────────────────────────────────────────────────────┤
│ 业务前线（销售/客服/业务员）← 第一个执行层            │
├─────────────────────────────────────────────────────┤
│ 职能执行（财务/法务/质量）← 支持执行层               │
├─────────────────────────────────────────────────────┤
│ 审批/管理层              ← 最下方（决策层）           │
└─────────────────────────────────────────────────────┘

活动节点标注规范

节点名称唯一性（2026-07 补充）：

• Trisotech（OMG 成员，《Naming Conventions for BPMN Diagrams》）："Multiple Activities should not be named with the same name, except for same Call Activities used many times in the Process."——多个活动不应同名，唯一例外是同一"调用活动"被多处引用（引用的是同一个节点，不是画两个同名框）。
• Bruce Silver《BPMN Method & Style》：同名的处理三选一——若含义相同则合并为一个节点被引用；否则改名区分（如"部门审核 / 财务审核"）；专业工具（Trisotech/Signavio）对同名标签一键校验拦截。
• 同名跨泳道的两种真实意图都不该用重名表达：真是同一活动 → 画一个节点、分支引用它；实为两个活动 → 命名带职责主体区分。
• 落地：名称唯一是 SOP/KPI/RACI 按名引用可追溯的前提，重名按 error 级处理（yoyflow 规范检查器 R12）。

活动节点格式

┌──────────────────┐
│ 动名词短语         │  ← 标准命名："提交采购申请"、"审批费用报销"
│ 说明：部门+岗位    │  ← 可选：标注执行角色编号
└──────────────────┘

3.2 高级画法规范

网关（Gateway）使用规范

McKinsey 建议：一张图中网关不超过 5 个；超过 3 个 XOR 嵌套说明流程本身逻辑混乱。

连接线（Sequence Flow）规范

正确：
  [活动A] ────────────────→ [活动B]
           条件标注（简洁）

错误：
  [活动A] ──→ ←──[活动B]       ← 线交叉
  [活动C] ──→ ──→ [活动D]      ← 线重叠
             ↘
               [活动E]          ← 无意义分支

时间标记规范

┌─────────┐    T+0     ┌─────────┐    T+2d    ┌─────────┐
│ 提交申请 │ ────────→ │ 部门审批 │ ────────→ │ 总经理批 │
└─────────┘            └─────────┘            └─────────┘
       ↓
   时效：24h内

BCG 标准：决策类节点标注时效要求，执行类节点标注工作量（人天）。

3.3 三大常见错误及修正

错误 1：逻辑断层——箭头断掉

错误：
  [A] ────→ [B]        ← [C] 从哪里来？[A]→[D] 去哪里了？

正确：
  [A] ────→ [B]
   ↓
  [D]

每个节点：入线 ≥ 1，出线 ≥ 1（终点除外）

错误 2：过度精细化

错误：把"打开电脑→打开OA→输入密码→点击流程→选择表单→填写→提交"
精简到：
正确： "提交表单申请"

Deloitte 规则：泳道图的粒度应到"部门内的离散动作"为止，不到"操作步骤"。操作步骤交给 SOP。

错误 3：角色名和部门名混用

错误：同一张图里既出现"张三（具体人）"又出现"人力资源部"
正确：统一用岗位/部门名，不要用具体人名

第四章：全景图（End-to-End Process Map）

4.1 什么是全景图

全景图（Process Panorama / Value Stream Map / End-to-End Map）站在 企业视角 展示一个完整业务流的全貌，通常不展示具体活动节点，只展示阶段/里程碑/关键交付物。

4.2 各咨询公司的全景图画法

McKinsey 端到端全景图（三层式）

┌─────────────────────────────────────────────────────────┐
│ Layer 1：价值流阶段                                      │
│  [需求触发] → [方案设计] → [采购执行] → [验收交付] → [运营] │
├─────────────────────────────────────────────────────────┤
│ Layer 2：关键里程碑                                      │
│  M1         M2          M3          M4          M5       │
│  需求确认   方案获批    合同签署    验收通过    稳定运行   │
├─────────────────────────────────────────────────────────┤
│ Layer 3：关键指标 (KPI)                                  │
│  响应时长    方案周期    采购周期    验收周期    运营质量  │
└─────────────────────────────────────────────────────────┘

• 角色：不画具体泳道，仅标注"谁负责哪个阶段"
• 节点：不超过 5-7 个阶段
• 粒度：一个阶段可能对应一张子泳道图

BCG 价值流全景图（漏斗式）

   ┌─────┐
   │ 潜在 │
   │ 需求 │
   └──┬──┘    ↑ 阶段1：需求识别（营销/销售/客服）
      ↓
   ┌─────┐   ┌─────┐
   │ 机会 │ → │ 评估 │   ↑ 阶段2：机会管理（产品/销售）
   └─────┘   └──┬──┘
                 ↓          ↑ 阶段3：方案交付（产品/研发）
              ┌─────┐
              │ 交付 │
              └──┬──┘
                 ↓
              ┌─────┐       ↑ 阶段4：运营支撑（服务/运营）
              │ 运营 │
              └─────┘

• 以阶段为节点，每个阶段展示跨部门参与概要
• 节点上限：5-7 个
• 亮点：阶段之间的交接箭头必须标注"交付物类型"

Deloitte 全景图（分层式）

  Strategy Level
  ┌────────────────────────────────────────────┐
  │ 业务目标：减少采购周期 30%                   │
  └────────────────────────────────────────────┘

  Process Level
  ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
  │ 寻源  │→│ 招标  │→│ 评标  │→│ 签约  │→│ 履约  │
  └──────┘ └──────┘ └──────┘ └──────┘ └──────┘

  Enabler Level
  ┌────────────────────────────────────────────┐
  │ 系统：采购系统 │ 数据：供应商库 │ 规则：合规    │
  └────────────────────────────────────────────┘

• 三层：战略层 → 流程层 → 使能层
• 流程层节点：5±2 个
• Deloitte认为超过 7 个阶段的流程，从"流程"变成了"运营体系"，需要单独的管理架构

4.3 全景图节点上限总结

全景图阶段数：5-7 个为最佳，9 个为上限，超过说明粒度太细，应该降维成子流程组。

第五章：分层分级（Process Hierarchy / Leveling）

5.1 流程分层标准（行业通行的 5 级）

5.2 McKinsey 的流程分层法（3 层够用）

McKinsey 在咨询项目中通常只画 3 层，因为客户不需要 L4/L5 的细粒度（那是 IT 系统设计的事）：

L1: 流程图谱（Process Landscape）
    ┌──────┐ ┌──────┐ ┌──────┐
    │ 收入流 │ │ 运营流 │ │ 支撑流 │
    └──────┘ └──────┘ └──────┘

L2: 端到端流程图（End-to-End Process Map）
    ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐
    │ 寻源 │→│ 招标 │→│ 评标 │→│ 签约 │→│ 履约 │
    └───┘ └───┘ └───┘ └───┘ └───┘

L3: 泳道图（Swimlane Diagram）
    [详细泳道图，5 个角色以内，12 个节点以内]

5.3 华为 IPD 的流程层级（6 级）

华为 IPD 的层级定义更精细，是咨询公司里最完整的：

华为的铁律：

• L3 是"最佳阅读层级"——给业务负责人看的
• 不要试图在一张图上展示两个不同层级
• L1→L2→L3 的展开比：一个 L1 展开成 3-5 个 L2，一个 L2 展开成 3-7 个 L3

5.4 分层之间如何衔接（McKinsey & BCG 标准）

使用 "Process Architecture Diagram"（流程架构图）

     ┌───────────┐    ← L1 流程域
     │  采购域    │
     └─────┬─────┘
           │ 展开
     ┌─────┼─────┐
     │     │     │
  ┌──┴──┐ ┌──┴──┐ ┌──┴──┐  ← L2 流程组
  │ 寻源  │ │ 招标  │ │ 履约  │
  └──┬──┘ └──┬──┘ └──┬──┘
     │       │       │
  ┌──┴──┐ ┌──┴──┐ ┌──┴──┐  ← L3 子流程
  │市调  │ │公告  │ │验收  │
  │供应商│ │发标  │ │付款  │
  │库维  │ │评标  │ │评价  │
  └─────┘ └─────┘ └─────┘

不要把 L1 直接跳到 L3——没有中间层，读者无法建立结构感。

5.5 画图时切忌混层

5.6 分层数据量控制

第六章：汇总速查表

6.1 速查规则卡

6.2 评审清单（Checklist）

提交流程图前，逐项检查：

□ 泳道 ≤ 5 个？
□ 节点 ≤ 12 个？
□ 没有混层级？
□ 所有节点都有命名（动词+名词）？
□ 环节名称在同一流程内唯一（无跨泳道同名）？
□ 所有箭头都有来源和目标？
□ 网关有明确的条件标注？
□ 没有具体人名？
□ 没有操作步骤级别的细节？
□ 线交叉 ≤ 2 处？
□ 网关 ≤ 5 个？
□ 图可以在 A4 / 标准屏幕上一屏看完？

6.3 工具选择建议

McKinsey 实际做法：L1-L2 全部用 PowerPoint 画（交付物统一格式、客户易读），L3-L4 用 Visio 画然后嵌入 PPT。从来不用 Excel 画流程图。

附录：各大咨询公司流程绘图核心理念对比

文档编制：JJ 对标来源：McKinsey《Visualizing Data / Process》、BCG Process Design Toolkit、Deloitte BPM Methodology Guide、Accenture Process Standards、IBM Process Methodology、华为 IPD 流程设计规范、OMG BPMN 2.0 7 Rules of Modeling