任务分配职责

阅读过程就像读书。它遵循特定方向，从左到右和从上到下读取。学习 BPMN 就像学习一种语言。所有 BPMN 元素都具有特定的含义，就像单词一样。努力是值得的, 正如你可以说话, 甚至思考, 在一个进程的语言.

假设我们很饿，让我们使用基本的 BPMN 元素创建一个流程，描述我们必须做些什么才能达到满足饥饿的目标。

• 描述触发我们流程的内容的开始事件。
• 顺序流，指导我们完成流程和任务。
• 描述我们必须做什么的任务。
• 结束事件，描述流程结束时达到的状态。

假设您的业务流程是大理石跑步。

在一个过程中，有大理石必须遵循的流量。唯一可以阻止我们的大理石经过的过程是任务。在此，大理石必须等到应用任务。最后，我们必须确保所有流量都到达结束事件，以便大理石始终可以每次跨越终点线。如果大理石没有到达，我们知道有什么问题，流在某个地方被中断。

大理石示例是一个简单的方法来思考"令牌"的 BPMN 概念。在 BPMN 中，我们的大理石正式称为令牌。令牌概念解释了业务流程的执行行为，无论它们有多复杂。

掌握此想法后，确实有助于了解业务流程流，尤其是在检查流程执行行为时出现错误消息。

如果你认为这些"技术检查"并不重要，因为你的模型不是由系统执行的，我们会告诉你，这些检查很重要。

相同的概念适用于：

• BPMN 语法检查（在保存图表时适用）。
• 流程模拟（甚至可以显示令牌）。

如果正确应用令牌概念，则可以了解任何 BPMN 流程模型，无论复杂程度如何。

每当公司中的多人参与流程建模时，必须确保您与命名保持一致。幸运的是，任务和事件存在命名规则，以确保所有 BPMN 流程都遵循相同的通用样式，以便在全球范围内了解它们。

请记住，任务和事件的命名规则基于 BPMN 的最佳实践，因此不会被视为严格的策略或规则。如果它是合理的、有意义的，并且可供建模者理解，则可以偏离它。

那么，如何才能正确、一致地命名活动？存在可帮助您识别 IS 状态的约定。实际上，命名事件的潜在信号词为：

• [需求]。
• [订单] 已接收。
• [服务] 可用。
• [发票] 已创建。
• ...

您不需要使用术语"是"，但它有助于确保您实际描述 IS 状态。

业务任务由资源执行 - 手动或技术。

在现实世界中，BPMN 使用另一个易于记住的概念进行建模，称为池和通道。此概念用于对业务流程中的职责进行建模。可以将车道作为泳道与游泳池进行比较 - 就像它们实际看起来一样。

池和通道概念允许您将任务分配到责任，而不是相反。这更有意义，因为每个任务都由某人执行，并且每次将同一人分配到多个任务非常繁琐（例如 EPC 等表示法中就是这种情况）。

池通常表示流程发生的整个组织。

区域代表应用任务的实际职责，可以是角色、部门、职位，甚至是指定人员（不推荐）。

通常，池的每个通道都负责应用所有分配的任务。由于序列流连接任务，因此通道交叉也可以视为信息和执行职责的移交。因此，参与者必须相互互动和沟通。

池和车道的使用通过下面的一个故事解释，Tim 和 Robert，两人共用一个住宿。

Tim 在互联网上找到了新的配方。但是，Tim 不能很好地烹饪。幸运的是，他的平面搭档罗伯特很喜欢做饭，很乐意尝试新配方。然而，在烹饪完美味的晚餐后，罗伯特很饿，以至于再也等不到蒂姆（与妈咪打个电话）。所以,他开始独自吃晚餐。

Tim（通道）：

• 购买杂货

罗伯特（莱恩）

• 准备晚餐
• 吃晚餐（不涉及 Tim）

虽然罗伯特已经在吃饭，但蒂姆在打电话时已经闻到晚餐，去厨房 ―― 刚好时间！现在，他们都可以 一起吃饭。

罗伯特（莱恩）

• 准备晚餐
• 吃晚餐

Tim（额外流程参与者）

• 也参与到"吃晚餐"任务中，

让我们总结一下我们在晚餐示例中所观察到的内容：

• 职责（通道）属于一个组织（池），在我们的示例中：共享住宿
• 任务的职责可以在流程模型中可视化：
  • 运输线路。
  • 通过额外的流程参与者来完成。

尽管将更多参与者分配到了任务，但必须有一个主要责任负责此任务。您可以考虑确保所有其他已分配参与者聚集在一起的人员。

以下是泳道命名规则的可能性。此图片中使用的所有命名样式均正确，也可以组合使用，即使必须尽可能避免"人员"样式。