泳道图示例：呈现每一次交接的跨职能流程图

一位客户在周一申请 40 USD 的退款。支持在一小时内批准，并转给财务，而财务在周四批量处理退款。之后，银行显示这笔入账可能还要 5 到 10 个工作日。申请十天后，账单上仍然什么都没有，客户对这笔扣款提出了争议。

每个团队都按时完成了自己的工作。延误出在团队之间，出在请求等待下一个负责人的队列里。这个流程的普通流程图看起来无害。泳道图则把每个步骤放进执行它的人所在的泳道，问题就显现为跨越泳道的箭头。

本文讲解泳道图，以及什么时候该用它而不是流程图或 BPMN，然后演示一个退款示例：符号、交接、改进和绘图技巧。

什么是泳道图

泳道图是被划分成若干平行泳道的流程图，每个参与者一条泳道：一个人、一个角色、一个团队或一个系统。每个步骤放在执行它的人所在的泳道里。箭头仍然表示顺序，泳道则加上了归属。跨职能流程图、swim lane 图和泳道流程图是同一种东西的其他叫法。

泳道内部的箭头，是工作在团队内部流转。跨越泳道边界的箭头是交接：工作换了负责人，通常要先在队列里等待，才会有人处理。

Geary Rummler 和 Alan Brache 在 1990 年首次出版的 Improving Performance 中提出：“绩效改进最大的机会往往在职能之间的接口上”，也就是工作在部门之间传递的地方，用他们副标题的话说，就是组织架构图上的空白。泳道图画出的正是这片空白。

泳道图、流程图还是 BPMN？

根据你要回答的问题来选。如果问题是“下一步会发生什么”，流程图就够了，比如一位值班工程师遵循的事件响应流程图。如果问题是“现在谁手里有这件事，已经等了多久”，你就需要泳道。当流程引擎要运行这个模型，或者组织之间的事件和消息流必须精确时，选择 BPMN。BPMN 2.0.2 规范把它的池和泳道都称为 swimlane，并把泳道的含义留给建模者；BPMN 图示例介绍了这套符号。

示例：一个退款申请，逐步来看

一家网店用四个参与方处理退款：客户、支持、财务和支付系统（支付服务商加计费）。示例中的政策接受 30 天内的退款，允许支持批准低于 100 USD 的退款，更大的金额则交给财务。

1. 客户申请退款。
2. 支持对照退款政策检查订单。
3. 如果申请不在政策范围内，支持发送带理由的拒绝。
4. 如果低于 100 USD，支持批准并在当天发起退款。
5. 如果是 100 USD 或更多，由财务审核。如果财务找到拒绝的理由，支持向客户解释这个决定。
6. 支付系统把钱退回原支付方式，并发送确认邮件。
7. 银行大约在 5 到 10 个工作日后显示入账，依据是 Stripe 的退款文档。

泳道图符号

不要再多加符号：每多一个符号，财务分析师在检查你的图之前就多一样要学的东西。

泳道能暴露什么

交接

数一数跨越泳道边界的箭头。低于 100 USD 的退款跨越三次：客户到支持，支持到支付系统，支付系统回到客户。100 USD 或以上的退款跨越四次，被财务拒绝的申请也是四次。在设置阈值之前，每笔退款都走四次交接的路径。每次交接都是一个队列；在开头的故事里，工作花了几分钟，等待却花了几天。

等待和返工循环

等待藏在交接处，所以把它们写在箭头上。要详细测量每个步骤以及步骤之间的时间，可以画一张价值流图。

返工循环是指回工作已经到过的泳道的箭头。财务的拒绝有意返回支持，因为客户沟通归支持负责。支持向客户索要表单本可以设为必填的订单号，则纯属浪费。

缺失的负责人

无法放进任何泳道的步骤，就是归属空缺。检查失败的退款：Stripe 指出，退款可能失败，例如客户的银行账户已关闭，资金最长可能要 30 天才能回到你的余额，而且你必须自己构建逻辑来通知客户或团队。如果没有泳道负责这一步，就没有人会做。

根据图改进流程

1. 去掉一次交接。 让支持直接发起小额退款，这样低于阈值的每笔退款都不再进入财务的队列。支付服务商允许在不给完整权限的情况下做到这一点：Stripe 的 Refund Analyst 角色可以查看支付并退款，但不能创建支付，也看不到余额（截至撰写本文时，2026 年 11 月）。
2. 加入审批阈值。 用数据来选：把上个季度的退款按金额排序，看每个候选值之下有多少申请、多少金额。把这个数字写进判断本身，这样没人需要去查。如果必须强制执行这个上限，而不是靠信任，就在退款工具调用支付 API 之前检查它。
3. 给每次交接设一个目标， 写在箭头上：支持在 1 个工作日内回复，财务在 2 个工作日内决定。这样小额退款在 1 个工作日内发起，大额退款在 3 个工作日内发起。银行的 5 到 10 个工作日不在你的控制范围内，所以要在确认邮件里说明。

水平泳道还是垂直泳道

BPMN 允许泳道朝任一方向。区别在于实际使用：

对一组相关的图只选一个方向，读者就不必反复调整视角。

退款申请泳道图

这张图的读法如下：

• 四条泳道，从上到下：客户、支持、财务和支付系统。
• Yes 总是向右，No 总是向下。 每个问题的表述都让 Yes 表示有事需要关注：不在政策内、100 USD 或以上、存在拒绝的理由。
• 绿色是退款路径。 低于 100 USD 的申请从支持直接落到支付系统，不会进入财务泳道。
• 红色是拒绝路径。 两种拒绝都以支持把理由发给客户结束。
• 交接上的标签标明目标； 虚线箭头是银行的 5 到 10 个工作日。
• Markdown 块列出了政策、目标，以及每条路径上的交接。

把泳道图画清楚

• 每条泳道一个负责方。 泳道按角色、团队或系统命名，不要用人名；叫 Dana 的泳道在下一次重组后就错了。
• 每个方框以动词开头： 写“Check order and refund policy”，不要写“Order check”。
• 给每个判断的出口加标签， 并让同一个答案在每个菱形上都在同一侧。
• 按流量排列泳道， 让大多数交接只跨越一条边界。只在有意为之时才跳过泳道，就像这里的小额退款那样。
• 把等待写在交接上。 等待时间在有人写下来之前一直是看不见的。
• 省略系统内部细节。 API 调用和 webhook 属于架构视图，比如支付网关集成图。
• 把当前流程和改进方案分开画， 免得有人把计划当成现状。
• 每条路径都以终止符结束， 如果需要超过六七条泳道，就拆分这张图。

在 Archboard 中构建

1. 用 Google 或 GitHub 登录并创建图，或者打开已带泳道的跨职能流程图模板。
2. 从 BPMN 包添加一个 池，命名为 Refund request process，包含四条泳道：Customer、Support、Finance 和 Payment system。
3. 从 流程图 包向 Customer 泳道添加三个 开始 / 结束 节点：Request refund、Request closed 和 Refund received。
4. 在 Support 中添加一个检查订单的 处理、两个 判断 节点（Outside refund policy?、$100 or more?），以及一个发送拒绝的 处理。
5. 在 Finance 中添加一个 处理（Review refund）和一个 判断（Reason to decline?）。在 Payment system 中添加一个用于退款的 处理 和一个用于确认邮件的 文档。
6. 连接各步骤，每个 Yes 向右，每个 No 向下。给交接标上目标，把退款路径涂成绿色、拒绝路径涂成红色，并把银行的等待画成虚线。
7. 从 基础 包添加一个写有政策和目标的 Markdown 块，再加两条 文本 备注。

如果流程已经有 Mermaid 流程图，Mermaid 转图表工具可以把它变成可编辑的初稿。Free 图表最多容纳 15 个图表节点，所以更长的流程需要 Pro 或第二张图。这个示例共用 13 个图表节点，在 Free 套餐的限制之内。

常见问题

什么是泳道图？ 一种被划分为泳道的流程图，每个人、团队或系统一条泳道，每个步骤放在执行它的人所在的泳道里。跨越泳道边界的箭头就是交接。

泳道图和流程图有什么区别？ 流程图展示步骤和判断的顺序。泳道图增加了归属，让交接、等待和没有负责人的步骤变得可见。

跨职能流程图和泳道图是一回事吗？ 是的，这些名称可以互换，泳道流程图也一样。BPMN 同样使用泳道，但是放在池里，符号也更严格。

泳道应该水平还是垂直？ 两种都可以。水平泳道适合宽屏上的长流程；垂直泳道适合向下滚动的文档和手机。每组图选一种。

系统可以有自己的泳道吗？ 可以。自主完成工作的支付服务商或调度器值得拥有一条泳道；BPMN 规范也把系统列为泳道的典型用途之一。

免费开始 — 1 个席位，无需信用卡。