泳道与池：流程的组织结构与责任分工

发表于 更新于 分类于 ， ， ， 阅读次数：

在BPMN中，泳道（Swimlanes） 用来表示流程参与者与职责边界。泳道包括 池（Pool） 和 道（Lane） 两个层级，帮助清晰地展示”谁做什么”。本文讲解泳道的设计原则与跨组织协作的建模方式。

池与道：两层级的组织结构

池（Pool）

含义：代表流程的一个独立参与者，通常是一个组织部门或外部系统。

特点：

  • 池内包含完整的流程流（对象、活动、网关等）
  • 不同池之间通过消息流通信
  • 池与池之间的流程是异步、独立的
  • 可以有不同的泳道细分

常见场景：

  • 销售部门（Pool）
  • 财务部门（Pool）
  • 客户系统（Pool）
  • 第三方物流（Pool）

道（Lane）

含义：在一个池内，按照职能或角色进一步细分。

特点：

  • 属于某个池的内部细分
  • 通常代表”岗位”或”业务角色”
  • 同一个道内的活动由相同的角色执行
  • 可以嵌套多层道（子道）

常见场景：

1
2
3
4
5
6
7
8
9
销售部门（Pool）
  ├─ 销售员（Lane）
  ├─ 销售主管（Lane）
  └─ 销售经理（Lane）

采购部门（Pool）
  ├─ 采购员（Lane）
  ├─ 采购主管（Lane）
  └─ 财务（Lane）

泳道的设计原则

原则1：明确职责边界

将流程按组织部门或系统边界分开，而非按流程逻辑：

❌ 错误做法：

1
2
3
道1：用户填表
道2：系统验证
道3：管理员审批

（这是按逻辑步骤分的，不清晰）

✓ 正确做法：

1
2
3
4
5
6
7
客户系统（Pool）
  └─ 客户（Lane）
销售部门（Pool）
  └─ 销售员（Lane）
财务部门（Pool）
  ├─ 财务员（Lane）
  └─ 财务主管（Lane）

原则2：跨池通信用消息流

不同池之间的通信必须通过消息流（Message Flow），而非顺序流：

✓ 正确：

1
销售部门：[提交订单] → 消息流（订单信息）→ 财务部门：[审批订单]

❌ 错误：

1
2
[销售部门：提交订单] ─顺序流─ [财务部门：审批订单]
（顺序流不能跨池使用）

原则3：道内逻辑用顺序流

同一个道（即同一个角色）内的活动用顺序流连接：

1
2
3
销售部门 - 销售员（Lane）
  [收到订单] → [填写合同] → [提交审批]
   ↑─ 顺序流 ─↓

小案例：跨部门采购流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
┌─────────────────────────────────────┐
│        采购部门                      │
│ ┌──────────────────────────────────┐│
│ │ 采购员                             ││
│ │ [创建采购单] → [发送给供应商]      ││
│ └──────────────────────────────────┘│
│ ┌──────────────────────────────────┐│
│ │ 采购主管                           ││
│ │           ↑ 消息流（报价单）↓      ││
│ │ [评估报价] ←─────────────→ [批准]  ││
│ └──────────────────────────────────┘│
└─────────────────────────────────────┘
         ↓ 消息流（采购订单）
┌─────────────────────────────────────┐
│        供应商系统                     │
│ ┌──────────────────────────────────┐│
│ │ 供应商                             ││
│ │ [收到订单] → [发货] → [发送发货单] ││
│ └──────────────────────────────────┘│
└─────────────────────────────────────┘
         ↓ 消息流（发货单）
┌─────────────────────────────────────┐
│        财务部门                      │
│ ┌──────────────────────────────────┐│
│ │ 财务员                             ││
│ │ [收到发货单] → [核对发票] → [支付] ││
│ └──────────────────────────────────┘│
└─────────────────────────────────────┘

泳道与权限控制的关联

在实际工作流引擎中，泳道对应任务分配：

  • 销售员的Lane → 用户任务分配给”销售员”角色
  • 财务主管的Lane → 用户任务分配给”财务主管”角色
  • 系统的Lane → 服务任务由系统自动执行

伪代码示意：

1
2
3
4
5
6
// 基于泳道的任务分配逻辑
if (lane === '销售员') {
  assignTask(task, role: 'salesman');
} else if (lane === '财务主管') {
  assignTask(task, role: 'finance_manager');
}

常见设计误区

误区 原因 纠正
每个活动一个Lane 逻辑步骤混淆为组织结构 Lane代表组织/角色，不是步骤
跨Lane用顺序流 忽视参与者独立性 跨组织必须用消息流
过度细分Lane 追求细节 按实际岗位分，不要过细
同一Lane内用消息流 过度复杂 同角色内用顺序流即可

小结

掌握泳道设计：

  • ✓ 池代表参与者（组织/系统）
  • ✓ 道代表职能角色（岗位/部门）
  • ✓ 跨池必须用消息流
  • ✓ 清晰的组织结构映射

能够设计出责任明确、跨组织协作清晰的流程。

参考资料