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:
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:
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:
Most of BPMN Notations | CMMN Notation |
---|---|
Imperative | Declarative |
Process centric | Data centric |
Arcs describe the sequence | No predefined sequence |
Guided work (head down workers) | Enables workers (knowledge workers) |
Everything is modeled | Not everything is modeled |
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 | Case | Ad-hoc Process |
---|---|---|
|
|
|
Can be Modeled | Can be Modeled | Cannot be Modeled |
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:
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.
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.
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:
* Extracted from OMG Case Management Model and Notation specification
Note
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:
A Task is a unit of work. There are three types of tasks:
Task (planned Item) | Graphical Notation |
---|---|
Human Task - a Task that is performed by a Case worker, they can be:
|
|
Process Task - can be used in the Case to call a Business Process |
|
Case Tasks - can be used to call another Case |
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:
Discretionary Task | Graphical Notation (Discretionary task on right) |
---|---|
Discretionary Human Task |
|
Discretionary Human Task (Non-blocking) |
|
Discretionary Process Task |
|
Discretionary Case Task |
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.
Event Listener | Notation |
---|---|
A Timer Event Listener is used to catch predefined elapses of time. |
|
A User Event Listener is used to catch events that are raised by a user. In this way, a user enables direct interaction with the case proceeding, instead of indirectly via impacting information in the Case File trough executing Tasks. |
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.
The figure below shows an expanded Stage with one sub Stage and three Tasks.
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:
We can think of the criteria forming a sentence as follows,
([ on < Event 1 >[, on < Event 2 >[, . . .]] ]) AND ([ if < Boolean condition > ])
Note That:
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.
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.
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.
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.
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.