Oracle and Adaptive Case Management: Part 1

In this blog posting I address four key concepts that are used in Oracle Adaptive Case Management, or ACM for short. This article is the first in a series on ACM.

Recently I was involved in an Oracle Adaptive Case Management (ACM) project. Although some people involved knew about case management in general, it turned out that not everyone immediately understood how case management works with Oracle ACM. As you may be one of them, I will walk you through some of the concepts, using a format that differs from what I have seen so far, and seemed to work well for my audience.

I will not discuss the more general concept of case management. There are sufficient other references that probably do a better job than I could (for example Case Management Model and Notation, or CMMN for short, as defined by the Object Management Group ). For this article I will restrict myself to explaining that, unlike a "normal" BPMN process, case management supports a much more flexible "flow" of a process, for example supporting paths (flows) that were not thought of before, activity types that were not identified before, as well as stakeholders that were not known yet during the initial design. The "A" of Adaptive in ACM refers to the fact that some of this behavior can be configured run-time (after the system is out of development).

A typical example used in the context of case management is a complaints management process. Depending on the nature of the complaint, such a process can go back and forth a couple of times when more information about the complaint becomes available, coming from the filer or after consultations of experts that were not yet recognized.

Case Life Cycle

The first concept to discuss is that of a Case Life Cycle. A case can have the state open, suspended and closed. Unlike a BPMN process, after being closed a case can be reopened again (if required).

Mile Stones

The second concept is that of Milestones. In real life, you probably are used to defining 1 single milestone for every phase or "stage" (as it is called in CMMN) of a case, marking a significant result reached at the end of the it. With case management there may be milestones that are not always applicable, and therefore one should be able to skip them, or even close them halfway. It may also be necessary to revoke a previously reached milestone.

For Oracle ACM it therefore typically works best to identify the beginning and end of a stage as a milestone. So instead of defining 1 milestone "Complaint Evaulated" you define 2 milestones "Complaint Evaluation Started" and "Complaint Evaluation Ended". With Oracle ACM one can flag a milestone as being reached at any point during the stage.

Especially unpredictable behavior concerning the way milestones are reaches, it something that is very hard to model in BPMN.

Activities

As a third concept there are the Activities to discuss. From the perspective of the case, an activity is an atomic step that happens within a stage (in CMMN this is called a "task"). Normally, during its execution the case manager is not interested in the way the activity is executed, only in the result. Think for example about the consultation of an external expert: the only thing the complaints manager should be interested in, is the expert's report.

Within a stage an activity can be mandatory (Activity 1), for example the Initial Complaints Assessment, or optional (Activity 5), for example Request Info from Filer. Some activities may happen more than once within a stage (Activity 4), for example Request Expert Input. An activity may also apply to more than one stage (Activity 3), for example Update Complaints Manager. Activities may be sequential (Activity 1 and 2) or parallel (Activity 3 is parallel with 1 and 2). There can also be ad-hoc activities, like for example notifying some external party that turns out to be a stakeholder of the complaint.

As I will explain in the next article, an activity can be anything from a simple human task to perform, to a complete and even complex business process of its own.

Stakeholders

The fourth and last concept that I would like to discuss in this article, is that of Stakeholders. In real life a stakeholder is anyone that has some interest in the case, but may not always be involved as a case worker (someone doing something for the case) or case reviewer.

In Oracle ACM however, you are only interested in stakeholders that are case workers or case reviewers (very similar to the CMMN notion of case workers, except for that CMMN does not recognize case reviewers). As I will explain later, with Oracle ACM there can still be people that play a part in case while not being defined as a stakeholder.