The vote on BPMN 2.0 is not the only thing on the agenda at next week’s 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. Response to the announcement of same on OMG’s BMI mailing list has been sometimes thoughtful but mostly the kind of doubting, naysaying, and non-sequiturs you often get on that list. I once learned the hard way the danger of hitting Reply All to a BMI discussion thread, so I choose to post my thoughts here instead.
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 effors 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.
Hey Bruce,
I couldn’t agree with you more about the lame support for ad-hoc activities in the current BPMN spec. I think having processes that combine both ad-hoc activities with sequenced activities is much more powerful. As you have also noted, with case management it is important to also look at the relationship of data and process. I have always seen case management processes to be more data centric where processes simply manipulate the data of the case in either sequenced or ad-hoc events. There could be several processes interacting with the same data for a case occuring asynchronously.
Look forward to seeing what recommendations you would offer around case management.
Malcolm Ross
Director Product Management
Appian
Good summary. Perhaps this post contains a hint as to why my style of drawing a process diagram represent a “state” which remains static until acted upon by people or other external events. The activities don’t “execute” to completion, but rather are flags that indicate to everyone that the execution is going on, but actually simply wait for the signal that execution is complete. That makes a kind of equivalence between “control flow” and human/external events. Interstage BPM has always offering a continuum of possibilities between completely pre-determined processes and completely dynamic add-each-step-as-you-get-to-it style processes. I am overjoyed to see people discussing the importance of case management. While it is clear that BPMN would need extensions, it remains to be seen if OMG is the place for this discussion.
There are a number of articles on Case Management in the new 2009 Workflow Handbook, especially in regard to use in government.
Keith,
I think it should be possible to extend BPMN to better model case management, but I agree with you that OMG is an unlikely source of progress in this area, as the bmi thread clearly indicates. I think we could get further by convening an informal group of interested parties to play around with some ideas around scenarios and notation. I’ll count you in, maybe get Malcolm Ross (Appian) and Paul Tazbaz (Wells Fargo) to contribute as well. All BPMN people. And I’ll trade you a copy of my book for a copy of the 2009 Workflow Handbook.
–Bruce
I have been working on a Case Management application for a client of mine in the Canadian Federal Government. I have a BPMN background (I have taken one of your courses at a BMPI event, Bruce) so I was keen to model the process using BMPN. As I did, I came upon the limitations of the notation as described above.
I decided to differentiate between “Process Tasks” and “Case Tasks”. Process tasks are, as you would guess, those that involve workflow that either assign the case to various workers or move the case from one phase/state to another. Case tasks are those that involve a single case and can be assigned to and completed by the case team members. They represent the tasks required to complete the case (lamely, are essentially ad-hoc activities).
This architecture was heavily influenced by the fact that my client is developing in an MS Sharepoint environment. Each case will have its own ‘workspace’ with its own list of tasks etc.. but there is no ‘workflow’ at the case level. However Sharepoint provides the possibility for the creation of workflow at the case level as well..
I will have to pick up the 2009 workflow handbook to see how others are tackling this issue.
Dan