Intelligent Enterprise

The vote on BPMN 2.0 is not the only thing on the agenda at this week's Object Management Group (OMG) meeting in Costa Rica. There is also the release of an RFP for a new Case Management standard, authored by Henk de Man of Cordys.

The RFP asserts that BPMN is inadequate for case management but that case management should leverage BPMN for the "process" part, and I agree with that. It also seeks to tie in to OMG government task force efforts on records management for the case folder part. That might be useful as an option, but I hope it's not a requirement.

Of course, a major problem with case management is that there is no common definition for what it is. I would assert you could say the same thing about BPM until BPMN provided a standard vocabulary. Not everyone agrees with BPMN's conceptualization of process as a centrally-controlled orchestration (the rules guys, the choreography guys...), but for most of us it works, whether you are modeling automated processes or just describing manual ones.

Here is how I see the differences between case management and conventional BPM as described by BPMN 2.0:

• A "case" (instance of a case management process) does not progress from start to completion by following paths on a control-flow diagram like BPMN. The case as a whole has milestones or states, so progress to completion is more like a state diagram than activity flow. But we know that UML state charts are not "business-friendly," so perhaps that piece needs a makeover like BPMN did for UML activity diagrams.
  
• Much work on the case is driven by external events, not control flow. Those events, in combination with human activity responding to those events, determine the tasks and conventional processes that need to be completed. So there is an ad-hoc nature to case management processes, in which activities are added to the case at runtime. Usually these activities are not conceived on the fly, but predefined and selected from a menu or catalog.
  
• In conventional BPM, a task performer is not usually presented with every bit of detail about the instance, just enough to perform the task. In case management, performers interact with a shared case folder containing all the artifacts related to the case… data, documents, tasks, processes, their assignees and deadlines, etc. The notion that such a folder should be managed as a record, while obviously true, seems no more true than for the artifacts of ordinary process instances. Yes you need records management for both, but that is independent of the process aspect.

I think these differences from conventional BPM are not so great that case management needs to start over. An extension to BPMN to handle the case state progression model, in combination with a better solution for the ad-hoc/dynamic activity initiation part -- let's face it, today's Ad-Hoc Subprocess notation is lame -- is not beyond the range of possibility. Because a case will inevitably contain conventional processes modeled in BPMN, a strong connection between the case modeling notation and BPMN would be extremely valuable.

E-MAIL | FOLLOW US