CMMN与BPM的区别

  5.1 CMMN与BPM的区别

      BPMN一直在迅速传播，大部分企业已经采用了数量惊人的流程，其中许多流程已作为工作流自动化。 总有一个激动人心的时刻，那就是每个人最终都清楚必须严格执行任务的顺序。 对于刚接触BPMN的人来说，这一结果乍一看并不明显。 即便如此，仍然存在一类问题，这些问题并不需要严格的排序，因为在此过程中，有一个人必须根据条件来决定某事，而他或她希望保持一切可能的自由。 对于这种情况，BPMN提供以下方法：

1、动态子流程：特设子流程中包含的所有任务都可以选择以任意给定顺序执行。 并行化在这里也是可能的。目前盘古BPM工作流已经实现该功能，即任意加签、任意跳转。

2、不间断的附加事件：如果我们希望表明某人可以在执行某项任务期间开始其他活动，则如图5.1所示的不间断的附加事件可以提供良好的服务。

3、基于事件的子流程：如果在整个流程阶段都可以进行活动，则可以使用事件子流程。

 

                            图5.1：可以在用户任务期间使用BPMN启动其他任务，但是它很快会造成混乱。

      BPMN中的这些方法不一定易于理解。 例如，当知识工作者在案件处理过程中似乎拥有很多自由，但是这些自由受到规则的约束时，他们也很快达到了极限。

       这就是OMG创建案例管理模型和表示法Case Management Model and Notation（CMMN）的原因。 OMG在2016年向BPMN发布了标准的CMMN1.1版。目前盘古BPM工作流已经完全支持CMMN。

       CMMN具有与BPMN不同的基本范例。 CMMN没有顺序的流程。相反，它以某种状态对案例建模。根据状态，视情况而定，有些事情可能会处理，而有些事情可能不会。控制主要由人来执行。 CMMN是声明性的，该模型说明了要应用的内容，但没有说明如何实现它。相反，BPMN强制性地规定了流程中某些步骤必须进行的工作。对于大多数人而言，声明性建模更为复杂且较不直观。结果，CMMN模型更加难以理解。您不能简单地用手指追踪路径！

         CMMN对可能的活动和活动限制进行建模。它对活动何时发生，何时必须发生以及何时不应该发生进行建模。 CMMN同样限制了流程中人员可以使用的操作范围。事例模型必须事先经过仔细考虑。重要的是要提出这一点，以应对人们经常误解的事实，即人们在案件管理方面可以做他们想做的任何事情。

         当前，对于企业和最终用户的CMMN标记的可读性存在很多争议。 您应该对此发表自己的看法，但是我们知道没有更好的表示法。 同样，让我们不要忘记CMMN就像BPMN，因为它精确地定义了引擎的工作方式。

5.1.1 CMMN或BPMN？

CMMN和BPMN都描述了业务流程中的活动。 这些标准之间的主要区别是：

1、BPMN采用绑定方法。 它提供了活动的确切顺序。 提供自由度比较困难。比如加个节点、任意跳转就很麻烦。

2、CMMN采用非约束性方法，然后增加了限制。 建立排序比较困难。

 

换句话说，原则上您可以用任何一种表示法表达大多数问题。 但是，根据问题的类型，建模将在BPMN或CMMN中更好地工作，并且这些标准之一更可能产生整洁有效的模型。

 

使用CMMN的指标包括：

1、无需序列：如果序列无关紧要，并且可以按任何顺序执行任务，则这将在BPMN中产生过多的连接-临时建模。 也许使用临时子流程可以避免混乱。

2、活动取决于条件：定义条件是CMMN的强项。 可以定义许多任务，但是它们只能在某些情况下起作用。 例如，这种情况可能是订单超过一定数量或客户具有VIP身份； 其他已完成的任务也会影响条件。 可选因素和数据相关因素的这种组合不能在BPMN中反映出来。

3、专用计划阶段：由于能够处理任意任务，CMMN可以适应一个计划阶段，在该阶段中，一个工人计划一个案例并启用任务。 其他工人将不得不遵守计划。 BPMN不能做任何事情。

      如果您认为自己已达到BPMN的极限，那么可能值得研究CMMN。我们知道的许多项目都是按照以下原则进行操作的：“我们将尽可能地使用BPMN，因为我们知道并理解它。一旦我们注意到使用BPMN只能表现得很差或根本无法表达的情况，我们就会将CMMN从工具箱中拉出来，取而代之。”

      （CMMN中的）非结构化业务流程比（BPMN中的）结构化流程更难扩展。因此，您应始终问自己，是否要求引擎灵活性是在规避某些问题。也许组织无法就结构化流程达成共识。您可以应用CMMN，但是从长远来看，您是在牺牲潜在的改进或效率吗？也许您可以将CMMN用作迈向可以在BPMN中建模的更多结构的第一步。至少您可以记录活动并介绍BPM环境。

      您会看到，即使我们很高兴将CMMN添加到我们的工具包中，我们（盘古BPM工作流）仍然仍然是BPMN的忠实拥护者。在我们的项目中，我们的座右铭是：尽可能多的BPMN和尽可能多的CMMN。

5.1.2介绍示例

      让我们使用引言中的保险示例。 那就是涉及您的汽车保险申请和知识工作者的知识，他们必须决定批准它。

图5.2：CMMN中的案例示例：评估新应用程序。

在CMMN中，这可能如图5.2所示。 注意：

1、案例，以文件夹表示。

2、多项任务。 就像BPMN中一样，这里正在发生事情。

3、阶段，在案件中提供额外的结构。

4、以中间形状表示的可达到的里程碑，以实现最终结果。

5、以钻石为代表的几个哨兵。 这些决定了达到哪些里程碑，但它们还控制何时需要其他批准步骤。

在继续深入研究此示例之前，我们必须列出一些基础知识并解释CMMN的生命周期。

 

5.1.3 CMMN的生命周期

 

与BPMN不同，CMMN没有令牌概念。 相反，所有元素都遵循生命周期。 理解这一点对于正确使用CMMN至关重要。

图5.3：CMMN中任务的生命周期。

 

 

在图5.3中，我们显示了一个任务生命周期的示例。 由于情况也可以暂停，因此简化了操作。 生成新案例时，通常会发生以下情况：

1. 直接创建案例中包含的所有任务或阶段，这意味着它们可用。 尚未开始的阶段任务无法创建，因此不可用。

2. 检查所有可用任务，看其前提条件是否满足，前提条件用代表哨兵的小菱形表示。 如果满足条件，则该任务将变为启用状态或直接处于活动状态。

3. 通过激活规则定义此启用或激活。 活动任务最终出现在任务列表中。 启用的任务需要案例管理员声明他或她希望进行手动启动。

4. 任务可以完成（如果您过早退出案例处理，则可以终止任务）。

 

在图5.2中，应用程序决策阶段和应用程序任务决策自动启动。 那些没有哨兵但具有手动激活规则（请注意播放符号）的任务将被启用。 案例生成后各个元素所处的状态如图5.4所示。

图5.4：创建新案例后各个元素的状态。

 

一旦决定应用程序任务完成，状态就会发生变化，如图5.5所示。 这是因为应用程序决策阶段由于退出条件而终止。 我们将在以下各节中确切解释其工作原理。

图5.5：完成应用程序决策任务后各个元素的状态。

 

5.1.4案件管理系统的用户界面

 

CMMN模型及其生命周期可能很难理解。 根据我们的经验，可以将CMMN视为控制案件处理的软件。 在实际项目中，我们会尽早创建可点击的原型，以运行CMMN模型并验证某些情况。

图5.6：案例管理的可能界面。

 

图5.6显示了我们想象的软件的用户界面示意图。 我们已经在现实生活中的项目中看到了类似的界面。 屏幕分为以下主要元素：

l 任务区：如果用户正在执行用户任务，则他或她可能需要一张表格，例如，记录有关潜在客户的申请的决定以及作出该决定的原因。

l 上下文：为了做出合理的决定，用户需要访问尽可能多的有关客户的信息，客户的等级和历史记录，有关汽车的信息，区域统计信息，文档等。

l 案例状态：用户可以看到当前情况下已经发生的情况，以及将来可能发生的情况。 首先，用户需要具有启动已启用任务的能力。

 

如果您使用的是与CMMN兼容的引擎，则可以从引擎中加载大多数信息并显示在界面中。 在此过程中，CMMN生命周期发挥着核心作用。 图5.7显示了特定状态下的任务显示。 当然，技术可能性取决于实际用户在实际情况下的需求和可能性。

 

图1.7还显示了在盘古BPM平台上的简单实现的示例。 作为示例，可以在Internet上免费获得此版本。

 

图5.7：界面根据任务的生命周期状况显示任务。