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:
|Most of BPMN Notations
|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.
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:
A Task is a unit of work. There are three types of tasks:
|Task (planned Item)
Human Task - a Task that is performed by a Case worker, they can be:
- Blocking: Task is waiting until the work associated with the Task is completed
- Non-Blocking: the Task is not waiting for the work to complete and completes immediately, upon instantiation
Process Task - can be used in the Case to call a Business Process
Case Tasks - can be used to call another Case
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:
|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.
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.
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.
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 > ])
- 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.
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.