The questions of BPM vs Case Management, process vs case, and – almost too horrible for some Case people to contemplate – BPMN extensions for case management – are getting all frothy again.  Here is my take on the topic.

1.  The question is BPM part of case management, or is case management part of BPM? is a metaphysical one.  I think, however, it is a proxy for the real question, can a BPMS do a good job with case management, or do you need a special dedicated tool?  It’s obvious that if a single offering could provide both, users would prefer it over separate dedicated offerings.  And it’s equally obvious that it can be done, although it’s fair to say that the offerings may not be good enough yet.  Back in 2005, people said you needed separate BPM platforms for human workflow and integration processes.  It was just a matter of time, and not that long a time.

2. The question how is a case different from a process? is a more interesting one.  I am not sure there is a precise definition for a case, but there is one for a process, provided by the BPMN standard.  And a case, by any definition, is not the same thing.  A process is what BPMN calls an orchestration, meaning a sequence of activities, performed repeatedly in the course of business, with well-defined start and end, in which the activity flow logic is explicitly defined.  Each process activity is likewise a discrete action, performed repeatedly not continuously, each instance having a well-defined start and end.  Some in the case community have latched on to the term unpredictable to distinguish case from process, but I think this is off target.  The path any particular process instance will take is similarly unpredictable, since the internal logic of a  process task – an approval, for instance – may be completely arbitrary: a flip of a coin.  But the process logic – if approved do task B next, otherwise do task C next – is explicit and handles all possibilities.

A case is defined differently.  The fundamental unit of work is also an activity, which may or may not be identical to a BPMN activity, i.e. action performed repeatedly with a well defined start and end of each instance.  A case is a set of activities related to each other in some way, but the logic of the activity flow is not necessarily an orchestration:

a. It could be that a single case is composed of more than one orchestration, i.e. more than one process.  In fact, this is usually true.  Most of the case management offerings promoted by ECM vendors fall into this category.  It differs from ordinary BPM in superficial ways only.  For example, it requires a shared case folder that aggregates all the case artifacts – activities, processes, documents, and data – and manages the status of the case of the whole, in addition to the states of the processes and tasks.  This type of case management will surely be subsumed into regular BPM Suites.

b. The next activity may be determined by the performer at runtime on an “ad-hoc” basis.  And let’s distinguish two meanings here.

b1. If the next activity is selected from an enumerated menu or list, this is really orchestration, but one in which an orchestration diagram like BPMN would be visually confusing, too hard to construct, etc.

b2. If the performer at runtime can define some purely ad-hoc action and insert it as the next task to perform, this is something different than a process as defined in BPM.

To my way of thinking, b1 calls for a BPMN extension – a notational change more than a change to the metamodel.  I suspect this is the real need here, certainly more than b2.  There may be a need for b2, purely ad-hoc case management (beyond the ad-hoc task management Apple and Google will give you on your phone)… but I doubt it.

c. “Activities” in case management, or some of them, may not be what BPMN means by activity, i.e. having a well-defined start and end.  What case people call the “inflexibility” of BPMN is mostly due to the fact that when a BPMN activity is complete it is done, finished.  It cannot suddenly wake up again and say, Oh my God, I forgot something, or I found a problem in that document I approved earlier.  Those are real world things, and I would love BPMN to see them as further examples of b1 above, i.e.  bending but not breaking the BPMN metamodel, and calling for a notation extension that makes the behavior simpler to draw and understand.  This is possibly just one example of a broader definition of a case activity, which is more like a state than an action.  In fact, case logic is frequently better described by some kind of state diagram than an orchestration diagram like BPMN.

3. All of these examples (except for b2) could, I believe, be incorporated into an extension of BPMN.  One that possibly might require something fundamentally different is where the logic is goal-directed, similar to backward chaining in the rules world.  Some case management might fit this definition, but probably most of it does not.