业务流程模型与符号（BPMN）作为描述工作流的通用语言。在此框架中，流程的清晰度往往取决于边界定义得是否清晰。开始事件和结束事件是任何流程图的锚点，它们标记了业务活动的开始和结束。错误使用这些元素会导致对流程实际启动时间以及何时被认为完成产生混淆。
本指南探讨了正确使用开始和结束事件以明确流程触发的方法。我们将分析这些事件的语义、其视觉表现形式，以及适用于不同场景的具体类型。正确的建模能够确保利益相关者清晰理解流程实例的生命周期，避免歧义。
🌱 开始事件的作用
开始事件代表流程启动的点。它是创建流程新实例的触发条件。在视觉上，它表现为一个边框较细的圆圈，内部通常为白色，表示在触发条件发生之前不会有任何动作。与参与者执行的操作（即任务）不同，开始事件是一种必须满足才能开始工作的条件。
定义触发条件
每个开始事件都需要一个特定的触发条件。如果没有触发条件，流程将无法启动。触发条件的类型决定了流程的性质。以下是BPMN中常用的开始事件类型：
-
无： 这是默认类型。它表示流程在人工或系统手动启动时开始，无需特定的外部信号。通常用于内部流程。
-
消息： 当从外部参与者或系统接收到特定消息时，流程开始。这在B2B交互或客户服务流程中很常见。
-
定时器： 流程根据时间计划启动。例如，月度报告可能在每月第一天自动开始。
-
信号： 流程由广播给多个监听者的信号触发。这使得多个流程可以同时响应一个事件而启动。
-
条件： 当特定条件变为真时，流程开始。虽然这在第一个事件中不常见，但在特定建模场景中可以使用。
选择正确的开始事件类型对于清晰表达至关重要。如果一个流程依赖于客户邮件，使用“无”开始事件可能暗示需要手动启动，而使用“消息”开始事件则能准确反映该邮件的自动接收。无开始事件可能暗示需要手动启动，而使用消息开始事件则能准确反映该邮件的自动接收。
🛑 结束事件的作用
相反，结束事件标志着流程的终止。它表示业务活动已成功完成，或因异常而终止。在视觉上，它也是一个圆圈，但边框较粗，内部通常为白色，与开始事件类似。
正如流程需要一个明确的开始一样，也需要一个明确的结束。一个模糊的结束事件会让利益相关者不确定任务是否仍在进行中，还是工作流已经完成。结束事件还充当流程实例的终止者，释放与该实例相关的资源。
结束事件的类型
不同的场景需要不同类型的结束事件。选择合适的类型可以清晰地传达流程的结果：
-
终止： 此事件立即结束流程。通常在满足关键条件（如取消请求）时使用。
-
消息： 该流程在向外部参与者发送特定消息后结束。这证实了工作流已完成了其通信循环。
-
错误： 这表示流程因错误而结束。这对于追踪失败的流程以及理解业务活动为何未能成功至关重要。
-
升级： 当流程因问题被升级至更高管理层而结束时使用。
-
补偿： 如果活动需要撤销，则会触发补偿流程。它用于长时间运行的事务中。
-
信号： 与开始事件类似，此事件在完成时广播一个信号，使其他流程能够对完成状态作出响应。
-
多种： 这使得流程可以根据所采取的路径以多种方式结束。
使用一个 终止 事件与一个 消息 事件不同。终止 会立即停止所有内容。消息 会在停止前发送通知。理解这一区别可以避免对系统是否仍在运行产生混淆。
📊 开始与结束事件类型的比较
为了帮助直观理解差异，请参考以下对比常见开始与结束事件类型的表格。这种结构有助于为您的特定业务场景选择合适的元素。
|
事件类型 |
视觉指示符 |
主要使用场景 |
方向 |
|---|---|---|---|
|
消息 |
信封图标 |
外部通信 |
开始与结束 |
|
计时器 |
时钟图标 |
计划执行 |
开始和结束 |
|
错误 |
感叹号图标 |
异常处理 |
仅结束 |
|
终止 |
红色X图标 |
立即停止 |
仅结束 |
|
信号 |
闪电图标 |
全局广播 |
开始和结束 |
|
无 |
空白圆圈 |
手动启动 |
仅开始 |
请注意，某些事件（如错误和终止）通常是结束事件，而其他事件（如无）通常是开始事件。混合使用这些事件可能导致建模错误。
🔍 明确流程触发器
术语“触发器”指的是促使流程向前推进的事件。在BPMN中，开始事件是主要的触发器。然而，触发器也可以存在于流程内部，通常作为中间事件。本指南的重点是边界。
正确识别触发器可确保流程能够响应业务需求。如果一个流程仅在收到付款时才启动，那么开始事件必须是代表该付款的消息事件。如果将其建模为计时器事件，系统可能会等待某个日期，完全忽略付款状态。
常见触发场景
-
客户咨询： 处理客户投诉的流程应以代表收到的电子邮件或工单的消息事件开始。
-
月度对账： 财务流程应以设置在每月最后一天的计时器事件开始。
-
系统关机： 维护流程可能由基础设施团队广播一个信号事件来启动。
-
手动入职： 招聘流程可能以一个无事件开始，等待招聘人员手动点击按钮以启动。
每个场景都需要采用不同的建模方法。开始事件是业务与系统之间的契约，它定义了工作开始的承诺。
⚠️ 常见的建模错误
即使经验丰富的建模人员在定义开始和结束事件时也可能出错。这些错误可能导致难以执行或监控的流程。以下是需要避免的一些常见陷阱。
1. 无网关的多个开始事件
单个流程定义通常应只有一个开始事件。如果你发现自己需要多个开始事件，应考虑使用流程子过程或网关。拥有两个开始事件会使执行引擎难以判断应创建哪个实例。
2. 缺少结束事件
流程中的每条路径都必须通向一个结束事件。如果某条路径在没有终止点的任务或网关处结束，流程实例将挂起，消耗资源却无法完成。务必确保每个分支都连接到一个结束事件。
3. 使用任务代替事件
不要使用任务来表示流程的开始。任务意味着工作正在立即执行。开始事件意味着某个条件正在等待满足。使用任务作为触发器可能会导致对工作是否可选或必须的混淆。
4. 结束状态不明确
不要对所有结果都使用通用的结束事件。如果流程因支付失败而结束，应使用错误结束事件；如果因成功完成而结束，应使用消息结束事件或无事件结束。区分成功与失败对于报告至关重要。
🛠 提高清晰度的最佳实践
为确保您的流程图清晰且有效，请在使用开始和结束事件时遵循以下最佳实践。
-
命名一致性：清晰地标记您的事件。不要只使用“开始”，而应使用“开始：订单已接收”。不要只使用“结束”，而应使用“结束：订单已发货”。这样可以在不增加额外文字的情况下提供上下文。
-
视觉层级： 确保开始事件位于左上角，结束事件位于右下角。这符合自然的阅读方向，减少认知负担。
-
边界检查： 定期审查您的图表，确保没有孤立的路径。每个序列流最终都必须到达一个结束事件。
-
范围定义： 明确界定流程实例涵盖的范围。如果流程涉及多个部门，确保开始事件反映的是整个组织的入口点，而不仅仅是某个部门。
-
文档说明： 为复杂的开始和结束事件添加文档说明。如果仅靠图标不足以说明，应在备注部分解释具体的触发条件。
🔗 子流程与事件处理
在建模复杂系统时，您经常会遇到子流程。子流程是包含在另一个流程中的流程。子流程的开始和结束事件对于定义父流程与子流程之间的交互至关重要。
嵌入式子流程
在嵌入式子流程中，开始事件被隐藏在边界内部。父流程看不到内部的开始事件，它只看到进入子流程的入口。这有助于隐藏复杂性。
事件子流程
事件子流程允许流程在主流程运行时对事件作出响应。它们在边界内拥有自己的开始事件，且可独立于主流程触发。这一功能强大，可在不中断主工作流的情况下处理中断。
使用事件子流程时，请确保开始事件清晰标注，应明确指出触发子流程的事件。例如：“错误处理程序：超时启动”。
⚙️ 错误处理与结束事件
错误处理是流程建模中的关键环节。当流程遇到错误时，必须知道如何响应。结束事件在此发挥作用，但通常使用中间事件来捕获错误。
然而，最终的结束事件必须反映实际结果。如果流程失败且无法恢复，应以错误结束事件结束。这向监控系统表明该流程实例处于失败状态。
补偿流程
在长时间运行的流程中，可能需要撤销已完成的工作。如果流程提前终止，可能需要触发补偿流程。这通常与补偿结束事件相关联，以确保即使流程提前停止，财务或数据完整性仍能得到维护。
🔄 生命周期与状态管理
理解流程实例的生命周期是管理开始和结束事件的关键。生命周期从开始事件被触发的那一刻起开始，到结束事件被触发时结束。
-
创建： 开始事件创建实例。
-
执行： 任务和网关被执行。
-
终止： 结束事件关闭实例。
如果流程未到达结束事件，它将保持运行状态。这会消耗系统内存和数据库空间。定期审计流程有助于识别卡住的实例，需要人工干预。
📝 最终考虑
建模开始和结束事件不仅仅是画圆圈。它关乎定义您业务的逻辑。这些事件充当人类世界与数字工作流之间的接口。正确使用时，它们能清晰地表明工作何时开始、何时结束。
通过避免常见错误并遵循最佳实践，您可以创建易于理解与执行的图表。请记住，为特定触发条件选择合适的事件类型。使用粗边框表示终止，细边框表示启动。确保每条路径都导向明确的结论。
BPMN的目标是沟通。清晰的开始和结束事件有助于利益相关者、开发人员和业务用户之间更好地沟通。它们减少了歧义，确保所有人对流程边界有相同的理解。
花时间审查您的图表。问问自己，开始事件是否真正反映了业务触发条件。问问自己，结束事件是否准确反映了业务结果。对这些元素进行微小调整，可显著提升流程模型的质量。
