Here are the reasons why Business Process Management (BPM) and Adaptive Case Management (ACM) should be considered the same.

1. Case/process interoperability

Structured and well-defined processes and "unwinding" ad-hoc cases are mixed and intertwined.

• Processes may call cases as sub-processes. An example, support ticked may be (and often is) presented as a process yet when it comes to action items (fixing the problem) it isn't predictable, really so it should be better treated as case.
• Cases may call processes as sub-cases: a patient's clinical record is a case while medical procedures and tests are well-defined processes.

2. Case/process migration

This one is a little bit trickier. Cases may mutate into processes over time.

• Use case #1: "From System of Innovation to System of Differentiation". The use case name refers to Gartner's classification: the system of innovation supports organization's crusade to new markets, new products etc. while the system of differentiation technologizes the business recipe found at the innovation phase; the former is naturally associated with ACM and the latter with BPM.

This division isn't static: what has been a fresh business idea once now became a routine and business as usual. In other words, cases are redesigned as processes.

• Use case #2: "Fast Forward to the Case". Let's assume that we are dealing with quite predicted sequence of work that may very well be presented as a BPMN process. Yet it would take time - not as much as it'd take to cast the process into the concrete of ERP software but anyway a BPMS implementation of a process would take from week to quarter.

Sometimes it's too much. And if it is, we may decide to treat the work as a case despite it's in fact a well-predictable process and put it into production in a day, not in weeks. We'll do the process work yet later, hence the migration.

This approach would save both time and efforts - migrating a case to a process is much easier than developing the same process from scratch because we may utilize process mining to get the reliable data about the process "as really is". The process model draft may be automatically generated from the case instances and constituting tasks and then adjusted manually. This approach guarantees that no business exception would be missed - which is a typical headache during the process design.

3. Unified tasks management

Processes and cases are not that different as they may seem. In fact, the only difference is how tasks are instantiated: from a process template or on ad hoc basis (with some constraints and/or heuristic).

Similarities are many:

• Tasks have essentially the same attributes (assignee, deadline, description). We all are under a increasing pressure of multi-tasking: a need to switch from one task to another hundreds of times during a day. The trouble doubles when the tasks come from different tools: tasks from Outlook, tasks from CRM, tasks from BPMS, tasks from ACM...

• Case/process measures and metrics are basically the same. So here comes #4 -

4. Unified monitoring, measurement, control and reporting

From the overall performance point of view it doesn't matter whether the result is achieved in the process or case paradigm: time to resolution average and standard deviation, percentage of tasks completed in time by performers etc.

5. Holistic resources management

Most of us don't enjoy the luxury to be involved only in routine or only in knowledge work, typically we switch from one to another all the time. And it often becomes a headache for managers: "Why is there no input from you on this case?” With the response, “Because I'm too busy on that process!” Some people become overloaded while others evade from both routine and knowledge work. Let's eliminate this separation of work.

6. Single social collaboration environment

Social collaboration is one of main digital drivers so people are pretty anxious about it. Now what? Should we add social functionality to every piece of enterprise software?

No, it hardly works this way because size matters. This is why internet-wide Wiki is a major breakthrough while many corporate-wide intranet wikis do not take off - they simply don't get the viable number of active writers.

Getting back to #social, by splitting the social collaboration between media we decrease the chances for them to thieve. Getting the processes and cases social collaboration together benefits both types of work.

7. Consistent business architecture

Looking at the business from architect's perspective, we don't care about processes and cases - it's business capabilities what counts. Whether we are capable of doing something or not - this what counts; how we achieve it - by process or case work - is the secondary issue. We should be able to:

1. Depict capabilities hierarchy from the top level of enterprise-wide value chains to atomic capabilities
2. Map the atomic capability to a specific process or case template.

The above principles of a single process/case work environment are fully implemented in the Comindware platform.

About the Author: 

Anatoly Belaychuk has over 20 years of professional and managerial experience in software and consulting industry. He is acknowledged BPM (Business Process Management) expert, writer, key speaker at BPM conferences, blogger and trainer. His current position is as a BPM Evangelist at Comindware.