As I prepare to update my BPMS Report series, task number one is taking a fresh look at the process types or “use cases” that guide the evaluation analysis. One in particular, called case management, has spawned some interesting discussion on my BPMS Watch blog. I position case management (sometimes called case handling) as a particular type of BPM application, while others describe it as essentially different from BPM. After blogging about some published papers on the subject and integrating a range of reader comments, I think I can finally draw a box around this use case, which most BPMS vendors have ignored.
What is case management, and in particular, how does it differ from conventional BPM? A case, like a conventional business process, involves a collection of activities or tasks. However, unlike BPM, the process from initiation to completion of the case is not easily constrained to a process diagram, certainly not one based on a single end-to-end orchestration, even with complex nesting and chaining logic. Which activities need to be performed in order to complete the case depends on the details of each instance. Typically the case manager, or perhaps any performer of a task in the case, makes these decisions. The “rules,” so to speak, are inside users’ heads, not codified in explicit business rules.
Moreover, users can add new tasks, data objects, documents – even new processes – to the case at runtime. The “model” defined by the case designer cannot anticipate all of these in advance. Case management inherently carries with it some fluidity of structure or ad hoc-ness. This is the part that many BPM suites have a hard time with: New tasks, processes, and data can be added on the fly, but you still want the process engine to execute those processes, track deadlines for those tasks, monitor case status end-to-end, and even measure performance. It’s not easy.
What are some examples of case management? Opening a new account at a financial institution, provisioning telecommunications services, IT services provisioning, mortgage loan origination, even something as reputedly cut-and-dried as employee onboarding… All of these, in the real world, find conventional BPM process diagrams constraining. They need the flexibility of case management.
A common artifact in systems that provide case management is the electronic case folder. It acts as a single container for all of the processes, tasks, data, and documents for the case. Unlike conventional workflow, where such an object might be routed sequentially to task performers, the case folder is shared by multiple users. These users can complete tasks or declare certain case milestones reached – or add new tasks, processes, or data – at any time. All aspects of the case are visible; their work is not compartmentalized into predefined bits. The notion of a shared case folder, as opposed to a routed process instance, gives case management the flavor of team collaboration as well.
Some vendors take a content-centric view of case management, viewing it as a sort of fusion between BPM and ECM. It is often true that the data objects added at runtime to the case folder may be document attachments, and the tasks and processes added relate to the revision, approval, or processing of those documents. But this is just one style of case management. There are others that are more data-centric.
I’ve tried to imagine how these ideas might be modeled and implemented in BPM. From a modeling perspective using BPMN, a case could be represented by a number of independent orchestrations interconnected by message flows. In BPMN (or BPEL) terms, these are all separate processes, but part of a single end-to-end business process diagram representing the case.
Such a model does not require all of those processes to complete in order to complete the case. The logic that chains and nests them in the end-to-end process is governed by the events generated by the process, task participant, or external case manager. I have seen a number of BPMN diagrams for ITIL processes, such as change management, for example, that fit this paradigm.
Events from these processes are also used to signal case status (milestones) and performance data to the performance monitoring component. A BAM component designed to operate independently of a conventional BPM process engine, such as Lombardi, Global 360, or webMethods, would probably work best.
This assumes that all of the processes or tasks that might be added at runtime could be modeled, at least in a generic way, in advance. I think that is probably true in most cases, but obviously not in all cases. Also, BPMN provides nothing in the way of a case folder, as described above. BPMN doesn’t deal seriously with data (or documents) anyway. This would be up to a BPMS designed to do case management.
