什么是案例管理模型和符号 (CMMN) - IT 观察者随笔

Table of Contents hide

1 临时流程

2 BPMN 与 CMMN

3 结构化流程 vs 案例 vs 临时流程

组织一直在寻求改进他们的工作方式，以提高效率并减少错误。这需要对其工作方法进行分析和持续改进，其中可能包括在 可预测情况下非常结构化的工作流程，以及在无法规定固定流程的情况下应对动态情况的协议。

CMMN 是一种图形符号，用于捕获工作方法，这些工作方法基于处理需要各种活动的案例，这些活动可能会以 不可预测的顺序执行以响应不断变化的情况。使用以事件为中心的方法和案例文件的概念，CMMN 扩展了可以使用 BPMN建模的范围，包括较少结构化的工作工作和由知识工作者驱动的工作。结合使用 BPMN 和 CMMN，用户可以覆盖更广泛的工作方法。

以下是我们在 BPMN 之外还需要 CMMN 的一些原因：

传统上，业务信息系统的研究和实践侧重于结构良好的业务流程。然而，许多业务流程难以建模。
对于事件管理、咨询或销售等知识密集型任务尤其如此。事实上，许多活动都是以临时方式开始和进行的，而不是提前计划好的。
对于知识密集型或基于项目的活动尤其如此，它们通常代表组织的核心竞争力。

临时流程

Ad-hoc 流程是一组业务活动和相应的工件（例如信息、决策和产品），它们只能在高级别聚合中进行标准化。实际的活动种类及其顺序因情况而异。

以下是 Ad-hoc Process 的特点：

虽然可以预测某些活动，但大部分过程不能在一开始就完全指定，因为它需要的信息只能以某种方式进入项目。
如果我们假设在 ad-hoc 流程的上下文中永远不会确定下一步，那么它们的执行就无法由经典的基于流程的信息系统控制，在大多数情况下，知识工作者控制着流程。
似乎不可能在设计时考虑到 ad-hoc 流程的所有可能性，这样的流程模型将变得复杂且难以管理

BPMN 与 CMMN

近几十年来，人们一直关注对结构良好的常规流程进行建模和自动化。BPMN 最适用于结构良好且高度可预测的工作，其中知识工作者主要执行任务，而 CMMN 涵盖了不太可预测的流程部分，知识工作者在运行时积极参与决策和规划

案例管理 (CM) 由 van der Aalst 在 2005 年作为知识工作者的工具引入。2014 年 5 月，OMG 发布了案例管理标准，称为案例管理模型和符号 (CMMN)。它的重点是支持不可预测的、知识密集型和结构薄弱的流程。案例管理是一种不使用控制流来描述流程的业务流程技术。

案例管理是通过为知识工作者提供访问与案例相关的所有信息的权限，并赋予他们对案例发展的自由裁量权和控制权来赋予他们权力。案例管理与流程无关，与工人有关。与经典流程相比，某个目标和提供选择的可能性比实现目标的方式本身更重要。

这里列出了BPMN和CMMN之间的区别：

声明式表示法 不尝试对问题的流程进行建模；他们建立期望的结果，即指定他们想要发生的事情，而不是应该如何发生。SQL 是声明式编程的一个示例，因为它不尝试控制程序的流程；它只是说明了它想要显示的内容，但没有说明它是如何完成的。

另一方面，命令式表示法确实尝试对问题的流程进行建模；例如，Java 或 C++ 等命令式编程语言，它们建立的命令将告诉编译器他们希望代码如何运行，但没有明确地告诉编译器他们想要发生什么。

结构化流程 vs 案例 vs 临时流程

设计时间与运行时间

CMMN 中没有序列流模型。任务的执行取决于称为哨兵的事件和条件哨兵捕获特定事件的发生或案例中满足的条件。哨兵用作进入和退出标准。请注意，黑色和白色菱形代表标准。

案例有两个不同的阶段，即设计时和运行时，如下所述：

设计时间

在设可根据他/她的判断选择性地应用。

运行

在运行时阶段，案例工作人员通过按计划执行任务来执行计划，并可选择在运行时将自主任务添加到案例计划实例。

CMMN 图一览

这个例子说明了用 CMMN 建模的论文写作过程。假设论文写作是一项密集的知识工作，并且可以以不同的方式处理。让我们进一步研究这个例子，如下所示：

流程有两个必须达到的里程碑：

草稿完成
文件完成

几个任务（例如 Create TOC）由作者自行决定。
编写文本 和 集成图形任务的准备草稿 阶段是强制性的。
这个阶段定义了重复规则，用重复装饰器（即 hash）表示。
虽然 研究主题 是一项强制性任务，但任务 组织参考 是在运行时决定的。它类似于 创建图形 和 生成图形列表。
当文档创建 或 截止日期到达时，流程将完成。

* 摘自 OMG 案例管理模型和符号规范

笔记

使用“文件夹”形状描绘案例计划模型
案例的名称可以包含在左上角的矩形中。
案例计划模型的各种元素被描绘在案例计划模型形状的边界内。
该图显示了案例计划模型的示例。

CMMN的基本概念

案例的完整行为模型被捕获在 案例计划模型中。对于特定的案例模型，案例计划模型包含代表案例初始计划的所有元素，以及通过案例工作者的运行时计划支持计划进一步发展的所有元素。有四种类型的计划项目：

任务

任务是一个工作单元。有以下三种类型的任务：

任务（全权委托）

任务始终是案例模型中预定义段的一部分。除了任务之外，案例工作者还可以使用酌情任务，可根据他/她的酌情权选择应用。全权委托任务由带有虚线和圆角的矩形表示/注意，任何任务类型都可以是全权委托的：

事件监听器

事件是在案例过程中发生的事情。例如，阶段和任务的启用、激活和终止，或里程碑的实现。

里程碑

里程碑代表可实现的目标，定义为能够评估案例的进展。没有工作与里程碑直接相关，但完成一组任务或关键可交付成果（案例文件中的信息）的可用性通常会导致实现里程碑。里程碑可能有零个或多个条目标准，这些标准定义了达到里程碑时的条件。

例如，我们在合规流程中有一个服务级别协议 (SLA)，可以使用计时器事件侦听器和里程碑进行建模，如下所示。

阶段和全权阶段

阶段可以被认为是一个案例中的一个“阶段”，通常将许多任务分组。
它是一个包含元素的容器，案例计划从中构建并可以进一步发展。
阶段可能被认为是案例的“情节”。它们可以被视为子案例（类似于 BPMN 中的子流程），它们也可以并行运行。
舞台由带角的矩形和底部中心的小方框中的“-”符号形式的标记描绘（“-”表示扩展的舞台）。
用户可以自行决定将任意阶段添加到计划中“可选”、“临时”。

下图显示了一个扩展的 Stage，其中包含一个子 Stage 和三个 Task。

标准

标准允许我们描述任务、阶段或里程碑何时应可用于执行（进入标准），或案例（案例计划）、阶段或任务何时应异常终止（退出标准）。Criteria 有以下两个可选部分：

一个或多个触发事件（称为 onParts）。这些事件将满足进入标准或退出标准的评估

我们可以认为形成句子的标准如下，

([ on < Event 1 >[, on < Event 2 >[, . . .]] ]) AND ([ if < Boolean condition > ])

注意：

其中方括号 ([ ]) 表示句子的可选部分，尖括号 (< >) 是要替换的占位符。
onPart 和 ifPart 在句子中都是可选的，但要使其有意义，至少其中一个必须存在。

进入标准

进入标准描述了阶段、任务或里程碑必须满足的条件才能执行。没有进入标准的阶段、任务或里程碑将在创建后立即可供执行。进入标准可以放置在阶段、任务或里程碑边界的任何位置。

例子

在下面的示例中，产品投诉和服务投诉两个阶段都需要一个条目标准，因为它们只有在投诉属于它们的类型时才能执行。在大多数情况下，只会执行两个阶段中的一个，尽管在某些情况下，投诉可能涉及两个阶段。

退出标准

退出标准类似于进入标准，但它用于在满足时停止在阶段、任务或案例（案例计划）上的工作。在投诉过程中，我们会为案件添加退出标准。在客户致电并取消投诉的情况下，我们需要停止处理此案。我们通过取消案例文件项来模拟这种情况，这可能是客户电话的录音或客户的来信。

案例档案

在 CMMN 中，每个案例实例都包含一个 案例文件 （也称为 案例文件夹，或简称为案例），案例工作者可以访问该案例文件中的所有数据。案例工作者可以添加、删除和修改案例文件中的数据，即使他们没有执行案例中的任何任务，只要具有足够的权限即可。案例文件中的数据称为案例文件项。

所有数据和数据结构都称为 案例文件项。所有案例文件项目都存储在案例文件中。案例文件项用于表示各种数据，包括数据库中的数据值、数据库中的一行、文档、电子表格、图片、视频、录音等。除了基础数据， case 文件项也可以表示容器，包括目录、文件夹、集合、堆栈、列表等。

例子

计划表

一个阶段或一个人工任务可以有一个计划表，指示可自由支配的项目是可视化的 (-) 还是不可视化的 (+)。当用户“扩展”计划表时，其包含的任意项在阶段内或人工任务外变得可见。对于与人工任务关联的任意项目，计划仅在任务的活动状态下可用。