What is Case Management Model and Notation (CMMN)

Organizations are always pursuing improvements in how they work in order to increase efficiency and reduce errors. This requires analysis and continuous improvement of their working methods, which may include very structured workflows in predictable situations, as well as protocols to respond to dynamic situations where it is impossible to prescribe a fixed process.

CMMN is a graphical notation used for capturing work methods that are based on the handling of cases requiring various activities that may be performed in an unpredictable order in response to evolving situations. Using an event-centered approach and the concept of a case file, CMMN expands the boundaries of what can be modeled with BPMN, including less structured work efforts and those driven by knowledge workers. Using a combination of BPMN and CMMN allows users to cover a much broader spectrum of work methods.

Here is some reasons why we need CMMN in additional to BPMN:

Traditionally, the research and practice of business information systems focuses on well-structured business processes. However, many business processes are difficult to model.
That is especially true for knowledge-intensive tasks such as incident management, consulting or sales. In fact, many activities are started and conducted in an ad-hoc way rather than being planned in advance.
This is especially the case for knowledge-intensive or project-based activities, which often represent the core competencies of an organization.

Ad-Hoc Process

Ad-hoc processes are sets of business activities and corresponding artifacts (e.g. information, decisions and products) that can only be standardized at a high level of aggregation. The actual kinds of activities and their ordering are different from case to case.

Here is the characteristics of the Ad-hoc Process:

While certain activities can be predicted, much of the process cannot be fully specified at the start, since it requires information that only becomes available some way into the project.
If we assume that in the context of ad-hoc processes the next step is never determined, their execution cannot be controlled by classical process-based information systems, in most cases, knowledge workers are in control of the process.
It seems impossible to think of all possibilities for an ad-hoc process by design time, such a process model would become complex and hard to manage

BPMN vs CMMN

In recent decades, there has been a focus on modeling and automating well-structured and routine processes. BPMN is best used for well-structure and highly predictable work where knowledge workers mainly execute tasks, while CMMN covers the section of less predictable processes with the active involvement of knowledge workers making decisions and planning during run-time

Case management (CM) was introduced as a tool for knowledge workers by van der Aalst in 2005. In May 2014, the OMG published a standard for case management called Case Management Model and Notation (CMMN). Its focus is on supporting unpredictable, knowledge-intensive and weakly-structured processes. Case management is a type of business process technology that does not use control flow to describe the process.

Case management is about empowering knowledge workers by providing them with access to all the information concerning the case and giving them discretion and control on how a case evolves. Case management it is not about the process, it is about the workers. In contrast to classic processes, a certain goal and providing possibilities to choose from is more important than the way to achieve the goal itself.

Here listed the differences between BPMN and CMMN:

Declarative Notation does not attempt to model the flow of a problem; they establish desired results i.e. specifying what they want to happen but not how it should happen. SQL is an example of declarative programming because it does not attempt to control the flow of a program; it simply states what it would like to appear but not how it is done.

Imperative Notation, on the other hand, do attempt to model the flow of a problem; for example, imperative programming languages such as Java or C++, they establish commands that will tell the compiler how they wish the code to run but not explicitly what they want to happen.

Structured Process vs Case vs Ad-Hoc Process

Design Time vs Run Time

There is no model of sequence flow in CMMN. Execution of a task depends on events and conditions called sentries A sentry captures the occurrence of a certain event occurring or a condition being fulfilled within a case. Sentries are used as entry and exit criteria. Note that the black and white diamonds represent the criteria.

A Case has two distinct phases which are design-time and run-time as described as follows:

Design Time

During the design-time phase, business analysts engage in modeling, which includes defining the Tasks (plan items) that are always part of pre-defined segments in the Case model, and the “discretionary” Tasks that are available to the Case worker that to be applied optionally based on to his/her discretion.

Run Time

In the run-time phase, Case workers execute the plan by performing Tasks as planned, and optionally adding discretionary Tasks to the Case plan instance in run-time.

CMMN Diagram at a Glance

This example illustrates process of paper writing modelled with CMMN. Suppose the paper writing is an intensive knowledge work and it can be handled in different ways. Let’s investigate this example a bit further as following:

Process has two milestones that have to be reached:

Draft completed
Document completed

Several tasks (e.g. Create TOC) are left to the discretion of the author.
Prepare Draft stage with Write text and Integrate Graphics task are mandatory.
This stage has defined repetition rule what is symbolized by repetition decorator (i.e. hash).
While research topic is a mandatory task, the task organize references is to be decided in runtime. It’s similar to create graphics and generate list of figures.
Process will be finished when document is created or the deadline is reached.

* Extracted from OMG Case Management Model and Notation specification

Note

A case Plan Model is depicted using a “Folder” shape
The name of the Case can be enclosed into the upper left rectangle.
The various elements of a case Plan Model are depicted within the boundary of the case Plan Model shape.
The diagram shows an example of a case Plan Model.

Basic Concepts of CMMN

The complete behavior model of a Case is captured in a case Plan Model. For a particular Case model, a case Plan model comprises of all elements that represent the initial plan of the case, and all elements that support the further evolution of the plan through run-time planning by case workers. There are four types of Plan Items:

Tasks

A Task is a unit of work. There are three types of tasks:

Tasks (Discretionary Task)

Tasks are always part of pre-defined segments in the Case model. In addition to tasks there are Discretionary Tasks which are available to the Case worker, to be applied optionally based on to his/her discretion. A discretionary Task is depicted by a rectangle shape with dashed lines and rounded corners/ Note that, any task type can be discretionary:

Event Listeners

An event is something that happens during the course of a Case. For example, the enabling, activation and termination of Stages and Tasks, or the achievement of Milestones.

Milestone

A Milestone represents an achievable target, defined to enable evaluation of progress of the case. No work is directly associated with a Milestone, but completion of a set of Tasks or the availability of key deliverables (information in the Case File) typically leads to achieving a Milestone. A Milestone may have zero or more entry criteria, which define the condition when a Milestone is reached.

For Example, we have a service level agreement (SLA) in the compliant process that can be modeled using a timer event listener and a milestone, as follows.

Stage and Discretionary Stage

Stage can be thought of a ‘phase’ in a case and typically groups a number of Tasks.
It is a container of elements from which the plan of the case is constructed and can further evolve.
Stages maybe considered “episodes” of a Case. They can be regarded as sub-cases (similar to sub-processes in BPMN) and they run in parallel as well.
Stage is depicted by a rectangle shape with angled corners and a marker in the form of a “-”sign in a small box at its bottom center (“-” designate expanded stages).
Discretionary stage can be added ‘optionally’, ‘ad-hoc’, to the plan at the user’s discretion.

The figure below shows an expanded Stage with one sub Stage and three Tasks.

Criteria

Criterion allow us to describe when a task, stage, or milestone should be available for execution (entry criteria), or when a case (case plan), stage, or task should terminate abnormally (exit criteria). Criteria has the following two optional parts:

One or more trigger events (called onParts). These are events that will satisfy the evaluation of the entry criteria or exit criteria

We can think of the criteria forming a sentence as follows,

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

Note That:

Where square brackets ([ ]) indicate optional parts of the sentence, and angled brackets (< >) are place holders to be replaced.
both the onPart and the ifPart are optional in the sentence, but for it to make sense at least one of them must be present.

Entry criteria

An entry criterion describes the condition that must be satisfied for the stage, task, or milestone to be available for execution. Stage, task, or milestones without entry criteria will be available for execution as soon as they are created. The entry criteria can be placed anywhere in the border of the stage, task, or milestone.

Example

In the example below, both stages product complaints and service complaints need an entry criteria, because they can only execute if the complaint is of their type. In most cases, only one of the two stages will execute, although in some situations the complaints may involve both stages.

Exit criterion

An exit criterion is similar to an entry criterion, but it is used to stop working on the stage, task, or case (case plan) when it is satisfied. In the complaints process, we will add an exit criterion for the case. In the situation the customer calls and cancels the complaint, so we need to stop working on the case. We model this scenario by having a cancel case file item, which could be a voice recording of a customer call or a letter from the customer.

Case file

In CMMN, each case instance contains a single case file (also called a case folder, or just the case), and case workers have access to all the data in that case file. Case workers can add, remove, and modify data in the case file even if they are not executing any task in the case, as long as have sufficient privileges. The data in the case file is called case file items.

All data and data structures are called case file items. All the case file items are stored in the case file. Case file items are used to represent all kinds of data, including a data value in a database, a row in a database, a document, a spreadsheet, a picture, a video, a voice recording, etc. In addition to basic data, case file items can also represent containers, including, a directory, a folder, a set, a stack, a list, etc.

Example

Planning table

A Stage or a Human Task can have a Planning Table indicating if the discretionary items are visualized (-) or not (+). When a user ‘expands’ a Planning Table, its contained discretionary items become visible within the Stage or outside the Human Task. For discretionary items associated with a Human Task, planning is only available in the active state of the Task.