BPMN 图示例：一步步构建订单履约流程

BPMN（Business Process Model and Notation，业务流程模型和标记法）看起来像是多了些符号的流程图，大多数人也是这样开始用它的。但这些额外的符号恰恰是关键：有了它们，一张图就能说明每一步由谁来做、什么触发了流程、哪些工作并行进行、哪些环节跨越了组织边界，而且精确到开发人员和运营经理读出来的是同一件事。

本文以一家网店的订单履约流程为例，一步步构建一张 BPMN 图，并在每个元素出现时加以解释。读完之后，你会得到一个可以改造套用的流程，以及一份让 BPMN 图难以阅读的常见错误清单。

你需要的元素

BPMN 2.0 的词汇量很大，但大多数流程图只会用到一个很小的核心子集：

元素	形状	含义
池	大框	一个参与者，例如一家公司或一位客户
泳道	池中的一行	该参与者内部的一个角色、团队或系统
开始事件	细线圆	触发流程的东西（消息、定时器，或没有特定的触发条件）
结束事件	粗线圆	流程的一种结束方式
中间事件	双线圆	流程中途发生或需要等待的事情
任务	圆角矩形	一个工作单元；标记表明它是用户任务、服务任务、发送任务还是手工任务
排他网关	带 X 的菱形	只走其中一条出向路径
并行网关	带 + 的菱形	所有出向路径都会执行；与之配对的网关会等待它们全部完成
顺序流	实线箭头	一个池内各步骤的顺序
消息流	虚线箭头	池与池之间的通信

示例：订单履约

用通俗的话来说，这个流程是这样的：

1. 客户发来一个订单。
2. 销售系统检查库存。
3. 如果商品缺货，就通知客户并取消订单。
4. 如果有货，就扣款，同时由仓库对订单进行拣货和打包。
5. 两者都完成后，发货部门把包裹交给承运商。
6. 销售系统通过邮件发送物流跟踪链接，流程结束。

用 BPMN 画出来是这样的：

下面我们一块一块地把它搭起来。

第 1 步：池和泳道

先从参与者开始。店铺是一个池，包含三条泳道：Sales system（销售系统）、Warehouse（仓库）和 Shipping（发货）。客户是第二个池，画成折叠起来的空白长条：我们关心的是客户发送和接收了什么，而不是客户如何做决定。

泳道不需要在任务上加任何标签，就能回答“这件事由谁来做？”。如果你无法决定某个任务应该放在哪条泳道里，这通常说明存在一个真实的职责归属问题，值得拿出来讨论。

第 2 步：开始事件和结束事件

流程在订单消息到达时开始，所以开始事件带有消息标记。流程有两种结束方式，所以有两个结束事件：Order fulfilled（订单已履约）和 Order cancelled（订单已取消）。按结果给每个结束事件命名，图的各种结局就一目了然。

第 3 步：用动词加宾语命名任务

每个任务都用动词加宾语来命名：Check stock（检查库存）、Charge payment（扣款）、Pick and pack（拣货打包）、Ship order（订单发货）、Send tracking email（发送跟踪邮件）。在有帮助时加上任务类型：服务任务无需人工即可运行，用户任务需要有人来完成，发送任务负责发出消息。仅凭这一个标记，开发人员就知道哪些步骤需要自动化。

第 4 步：用网关表达决策和并行工作

Check stock 之后的排他网关提出一个问题 In stock?（有货吗？），它的出向流上标着答案 yes 和 no。只会走其中一条路径。

在 yes 分支之后，一个并行网关把流程分叉：Charge payment 和 Pick and pack 同时进行。第二个并行网关再把它们汇合，因此只有两者都完成后才会开始发货。分叉和汇合要成对出现；只有分叉没有汇合的并行分支，会让令牌一直流过流程的其余部分，而这几乎从来都不是你想要的。

第 5 步：池之间的消息流

顺序流只留在一个池内。池与池之间的通信使用消息流，用虚线表示：订单消息进入开始事件，缺货通知和跟踪邮件发回给客户。BPMN 不允许顺序流跨越池的边界，这条规则迫使你把组织之间的每一次交接都明确地画出来。

扩展流程

真实的流程需要更多内容。下面是几种常见的扩展，以及 BPMN 如何表达它们：

• 扣款失败。 把 Charge payment 和 Pick and pack 放进一个子流程，在子流程上附加一个错误边界事件，并把它连到一个把商品退回库存并通知客户的任务。如果错误路径只从其中一个并行分支引出，汇合处就会永远等下去。
• 拣货耗时过长。 在 Pick and pack 上附加一个非中断定时器边界事件，例如 24 小时，并把它连到一个升级处理任务。
• 仓库是合作伙伴。 把仓库单独画成一个池，并把流入它的顺序流替换为消息流。这样，图就能体现两家公司之间的约定。

只有在讨论需要时才加入这些扩展。一张试图画出所有异常的流程图，最后会变成一堵箭头墙。

常见错误

• 跨池使用顺序流。 参与者之间请使用消息流。
• 并行路径未经汇合就合并。 备选路径可以直接流入下一个任务，但并行路径必须通过并行网关汇合，否则下一个任务会按分支数重复执行。
• 问题放错了元素。 把问题写在网关上，把答案写在它的出向流上，而不是写在任务上。
• 任务名称含糊。 “处理订单”背后藏着五个步骤。如果一个任务需要一段话才能说清，它就应该是一个子流程。
• 所有内容都在一条泳道里。 没有泳道的 BPMN 图，只是一张符号更花哨的流程图。

BPMN 还是流程图？

快速梳理逻辑、算法和操作步骤时，用流程图。当职责归属、等待、并行工作或参与者之间的通信很重要时，用 BPMN；涉及多个团队的业务流程大多属于这种情况。Archboard 在同一块画布上同时支持两者；想要更简单的风格，可以看看流程图使用场景和跨职能流程图模板。

在 Archboard 中构建

1. 使用 Google 或 GitHub 登录，并新建一张图。
2. 从 BPMN 节点包中为店铺添加一个池，在其中分出三条泳道，再为客户添加第二个空的池。
3. 添加开始事件和结束事件、设置好任务类型的任务节点，以及网关类型设为排他或并行的排他网关节点。
4. 连接池内的各个步骤，并在池与池之间画虚线连线来表示消息流。
5. 在网关的出向流上标注答案，并为读者需要了解的信息添加文本注释。

这个示例用了 14 个图表节点，在 Free 套餐的限制之内。相关流程可以参考支付流程图和价值流图这两个使用场景。

常见问题

我需要学会全部 BPMN 2.0 吗？ 不需要。池、泳道、开始和结束事件、任务、排他网关和并行网关，以及消息流，足以覆盖大多数图。等真实场景需要时，再加入其他符号。

BPMN 图可以执行吗？ 流程引擎可以运行包含所需技术细节的 BPMN 模型。像本文这样画给人看的图，首先是为了就流程达成一致。

一张图应该画多大？ 如果一屏已经放不下，就把一组任务移到子流程中，并单独画出这个子流程。

系统和数据放在哪里？ 执行工作的系统用泳道表示，比如本文中的销售系统；任务读取和写入的信息用数据对象或数据存储表示。

如何评审一张流程图？ 和实际做这项工作的人一起，拿一个真实案例（比如一个缺货订单）在图上从头走一遍。每当他们说“其实我们……”，那就是一处需要修正的地方。

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