使用 Visual Paradigm 的 BPMN 指南

1. BPMN 是什么

业务流程模型与符号（BPMN）是一种用于描述工作如何在流程中流转的标准化可视化语言。它帮助业务利益相关者、分析师和技术团队使用一致的符号讨论相同的工作流。BPMN 由对象管理组（OMG）维护；BPMN 2.0.2 已作为 ISO/IEC 19510 发布。

BPMN 图不仅仅是流程图：其符号具有定义的含义，其连接规则区分了流程流与参与者之间的消息。一个有用的模型可以记录当前流程（“现状”），阐明拟议流程（“未来状态”），并帮助团队发现延迟、交接、返工或缺失的异常路径。

2. BPMN 核心概念

BPMN 的主要构建块包括流对象、连接对象、泳道、数据和工件。

事件

事件的轮廓和标记传达其角色和触发条件：

• 开始事件：启动一条流程路径。

• 中间事件：发生在流程过程中——例如收到消息或计时器到期。

• 结束事件：结束一条路径。不同的结束事件类型可表示不同的结果，例如正常完成或错误。

• 边界事件：附加到活动或子流程，以显示可能中断或影响该活动的事件，例如超时。

使用消息事件当流程响应通信时，以及计时器事件当时间部分是流程规则的一部分时，例如截止日期。

活动

使用清晰的动词 + 宾语，例如“检查库存”、“批准付款”或“发送确认”。使用：

• 任务表示单个步骤。

• 子流程表示某个步骤具有足够的细节，可以单独建模。

• 调用活动表示在重用全局定义的流程时使用，前提是您的建模方法支持该功能。

常见的任务标记可以指定工作类型，例如用户执行、手动或自动工作。仅在有助于读者理解或实现时才添加此类细节。

网关

根据流程逻辑选择网关，而不仅仅是您想绘制的形状：

• 排他（XOR）：选择一条 outgoing 路径。示例：“有库存吗？”→ 是或否。

• 并行（AND）：启动所有 outgoing 路径；相应的汇合点可等待所有必需路径完成。

• 包容（OR）：根据条件选择一条或多条 outgoing 路径。

• 基于事件：下一条路径由首先发生的事件决定，例如支付响应或超时。

用条件标记 outgoing 决策流，例如是 / 否或批准 / 拒绝。当网关分流时，请明确汇合逻辑。排他汇合将替代路径重新合并；并行汇合则同步那些并行启动的路径。

连接对象与池

一个顺序流显示流程顺序，通常保留在一个池内。一个消息流显示不同池之间的通信——例如，客户向公司发送订单。请勿使用消息流表示下一个内部任务，也请勿使用顺序流表示不同参与者之间的通信。

池可代表独立参与者，如客户、公司和支付提供商。池内的泳道表示角色或部门。请确保责任边界具有实际意义：泳道应明确谁负责执行工作，而不仅仅是装饰图表。

3. 实用的建模工作流

1. 设定范围。明确流程的触发条件、预期结果和边界。例如：“从接收订单到确认发货。”

2. 识别参与者和角色。决定哪些参与者需要独立的池，以及哪些职责应放在泳道中。

3. 编写主流程（成功路径）。在添加网关和异常路径之前，按顺序列出常规步骤。

4. 添加事件和决策。展示有意义的触发器、结果、业务规则和备选路径。

5. 添加交接点和数据。在有助于理解的地方，标注参与者之间的通信以及所需或产生的信息。

6. 检查完整性。追踪每条从开始到结束的路径。确认网关具有可理解的条件，且异常路径不会以模糊的方式消失。

7. 与流程用户一起审查。与执行或接收工作的人员一起验证模型。当模型与实际做法不符时，请进行修订。

8. 保持图表的可读性。使用一致的命名，尽量减少线条交叉，并在需要时将详细的子流程移至单独的图表中。

从能够回答业务问题的模型开始。一次性添加所有 BPMN 符号或实现细节通常会使图表更难审查。

4. 示例：在线订单履行

范围：从客户提交订单到发货确认。本示例侧重于公司的流程，并使用单独的客户池来展示 incoming 订单和 outgoing 确认。

流程叙述

1. 客户提交订单。

2. 公司接收订单并检查库存。

3. 如果商品不可用，公司通知客户并结束该订单路径。

4. 如果商品可用，公司处理付款。

5. 如果付款被拒绝，公司通知客户并结束该路径。

6. 如果付款获批，仓库拣选并打包订单。

7. 公司将包裹交给承运商，并发送发货确认。

文本图表

客户池：
(开始) → 提交订单 ──消息──▶

公司池：
(消息开始：订单已接收)
  → 检查库存
  → XOR：有库存吗？
      否  → 通知客户：不可用 → (结束)
      是 → 处理付款
             → XOR：付款获批？
                 否  → 通知客户：付款被拒 → (结束)
                 是 → 拣选并打包订单
                         → 将包裹交给承运商
                         → 发送发货确认 ──消息──▶ 客户
                         → (结束)

BPMN 自定义 PlantUML 代码（仅 VPasCode 编辑器支持）

@startuml
标题：订单履行业务流程图
<style>
    element { MaximumWidth 160 }
    start   { Backgroundcolor #00695C }
    stop    { Backgroundcolor #C2185B }
    activity{ Backgroundcolor #81D4FA; MaximumWidth 150 }
    diamond { Backgroundcolor #FFB74D; MaximumWidth 80 }
    arrow   { LineColor #424242; Fontcolor #000000 }
    swimlane{ Fontcolor #000000; FontSize 14 }
</style>

|#F0F8FF|客户|
start
:<<SendTask>>
提交订单;

|#E8F5E9|公司|
:<<ReceiveTask>>
订单已接收;
:<<UserTask>>
检查库存;
if (有库存？) then (是)
  :<<ServiceTask>>
  处理付款;
  if (付款获批？) then (是)
    :<<ManualTask>>
    拣选并打包订单;
    :<<SendTask>>
    将包裹交给承运商;
    :<<SendTask>>
    发送发货确认;
  else (否)
    :<<SendTask>>
    通知客户：付款被拒;
  endif
else (否)
  :<<SendTask>>
  通知客户：不可用;
endif
stop
@enduml

使用顺序流用于公司内部步骤，以及消息流在客户池与公司池之间。为每个 XOR 网关的流出流标注其条件。在 Visual Paradigm 中，“有库存吗？”和“付款已批准吗？”这些问题可作为网关标签，而流出的箭头则标注“是”和“否”。

可能的扩展：如果业务有付款截止日期，可为付款处理添加定时器边界事件；为承运商交接失败添加异常路径；或者如果需要独立的详细工作流，则将拣货和打包建模为子流程。

5. 在 Visual Paradigm 中构建模型

Visual Paradigm 提供 BPMN 2.0 建模工具，并支持子流程下钻，因此高层流程可链接到更详细的流程图。其 BPMN 功能还包括记录工作流程以及建模当前状态（as-is）和目标状态（to-be）流程。

实用的构建顺序：

1. 创建一个BPMN 业务流程图，在 Visual Paradigm 中。

2. 添加一个客户池和一个公司池；如果这些职责很重要，可将公司池划分为客户服务、仓库和运输等泳道。

3. 放置开始事件和活动，然后添加库存网关和付款网关。

4. 在公司池内绘制顺序流；与客户之间的交互使用消息流。

5. 用通俗语言标注任务和条件路径。仅在有助于读者理解流程的地方添加数据对象，例如订单或付款结果。

6. 安排图表使主流程阅读一致——通常从左到右——并尽量减少连接线的交叉。

7. 与利益相关者一起审查图表。如果某步骤的细节掩盖了主路径，可考虑将该细节放在子流程图中。

8. 以适合您团队的格式和工作区保存并共享模型。

Visual Paradigm 宣传 BPMN 图表建模、流程下钻、工作流程文档以及当前状态/目标状态建模。特定功能的可用性可能取决于版本。

6. 常见建模错误

• 使用错误的连接器：顺序流表示内部流程顺序；消息流表示参与者之间的通信。

• 使用逻辑不清晰的网关：标记决策及其所有输出条件。

• 将每个操作视为独立的池：在单个参与者内使用泳道表示职责；为不同的参与者使用独立的池。

• 路径不清晰：展示在拒绝、超时、信息缺失及其他相关异常情况下会发生什么。

• 单张图表信息过载：使用子流程将详细工作与概览分离。

• 建模理想状态而非现实情况：在提出改进建议之前，先准确记录当前流程。

• 无目的地添加细节：当数据、事件和任务标记能够回答建模或审查问题时，将其包含在内。

7. 快速审查清单

• 该图表是否为每条相关路径都设置了清晰的起点和终点？

• 读者能否识别出每项活动由谁执行？

• 决策及其输出条件是否明确？

• 顺序流和消息流的使用是否恰当？

• 是否表示了异常情况和替代结果？

• 该图表在预期的查看尺寸下是否清晰可读？

• 执行该流程的人员是否已确认其准确性？