我正在记录用户工作流程，其中部分流程由系统自动化（例如，如果订单数量小于10，则立即批准订单而不是将其发送给员工进行审核）。
我有游泳道，从人到人，但不知道我在哪里可以适应这个系统任务/决策路径。什么是最佳做法？可能是一个愚蠢的想法，但我倾向于创建一个新的泳道，称之为＆＃34;系统＆＃34;。
有什么想法吗？
答案 0 :(得分：1)
有一种通过专用参与者/通道表达系统任务/决策的技术。然后，所有系统任务都在系统通道上并置。
答案 1 :(得分：1)
系统任务（BPMN中的服务任务）通常代表一个演员完成，所以在我看来，将它们放在该演员的车道上是有用的。
通常这样的设计也有助于通过限制用户和＃34;之间的转换次数来使图表易于阅读。车道和＆＃34;系统＆＃34;车道。
答案 2 :(得分：0)
将系统任务分离到单独的通道的方法很可能，因为BPMN 2.0规范没有明确指定通道的含义并且说出类似的内容：
Lanes用于组织和分类池中的活动。 车道的意义取决于建模者。 BPMN没有指定 车道的使用。车道通常用于内部 角色（例如，经理，员工），系统（例如，企业） 申请），内部部门（如航运，财务）等。
所以你可以完全自由地用你想要的东西填充它们。
但是，你的情况非常明显，根本不需要这种分离。根据您的描述，我们有典型的条件活动，可以通过服务任务或子流程表达。这是两种不同的方法，它们具有不同的语义。
根据BPMN规范服务任务 是一项使用某种服务的任务，可以是Web服务或自动化应用程序。即它是通常在建模者不想分解某个流程时使用，并且将外包通常用于某些外部工具或代理。
另一杯茶是子流程，通常在您使用时使用 希望包装一些复杂的工作流程以供重用或者如果那样 工作流可以分解为子元素。
在您的用例中，子流程是一个选择。它高度可调，透明且可维护。例如，在子流程内，您可以使用业务规则引擎作为条件参数（订单数量），并在运行中灵活调整其值。 更详细地说，您可以从this blog了解这些方法的不同之处。