Case Management (aka iBPMS, eBPMS, Adaptive Case Management, Dynamic Processes, etc.) is getting a lot of attention. The attention isn't a result of the fact that companies are doing a lot of Case Management – in fact, as far as we can tell, most companies are still working on traditional BPM. The attention results from 1) the leading edge thinkers who are talking about it, 2) vendors who are trying to extend or simply reposition their BPMS offerings to embrace what seems to be the next hot thing in BPM software, 3) the well-publicized fact that the OMG is working on a Case Management notation (which they term Case Management Model and Notation – CMMN), and 4) the conferences and resulting books being published by Keith Swenson, Nathaniel Palmer, and Layna Fischer and others associated with the Workflow Management Coalition (WfMC).
Different groups have used different terms, but everyone seems to agree that there is a continuum that runs from conventional, procedural, routine processes to knowledge-based or completely unique tasks. I've pictured my version of the continuum in Figure 1.
When you look at the range of activities performed in any large organization you run from the completely routine activities that are done the same way every time to those like designing a new advertising campaign, developing a major new software application, hiring a new CEO, or determining corporate strategy, that are totally unique and totally dependent on unique human decisions. In essence, a large organization pays big money to hire a given CEO in hopes that that individual will provide the organization with unique leadership insights, a new company strategy, etc. No process person in his or her right mind is going to propose analyzing or modeling the work of the organization's CEO.
What is being proposed is that we can model, or at least informally capture information about tasks from the middle of the continuum that will help knowledge workers do their jobs more effectively. It is, of course, the growing importance of knowledge work in modern organizations that is both frustrating those using traditional process analysis techniques, and driving those who propose newer approaches for capturing case management processes.
At this point, let's take a brief pause and talk about the term “Case Management” since that will help understand what is being talked about. The term originated, as far as we can tell, from the healthcare industry, and refers to the fact that patients are thought of as “cases.” In effect, a customer shows up at a hospital emergency ward and complains of severe stomach pain. At this point no one knows what is wrong with the customer/patient, or what range of activities will be called for. It could be something the patient ate, appendicitis, or intestinal cancer. The hospital simply admits the patient and starts gathering information. And they create a “case file” for the patient into which they assign documents – medical history, reports from the patient, and data from lab tests. After a round of exams by physicians at the emergency ward, tests are likely to be prescribed. After the specific tests are undertaken, and the data placed in the case file, the physicians meet and discuss what might be wrong with the patient and what they should do next.
This brief description highlights some key features of a Case Management process. First, the process is not made up of a pre-determined set of activities. It's unique and tailored to the specific customer. (We might argue that the process has a very abstract set of steps. You can imagine a high-level flow diagram with the subprocesses: Admit patient, Diagnose Patient, Conduct Lab Tests… but these subprocesses are so abstract as to be nearly useless in predicting what activities will be used in any given instance.)
Second, the knowledge workers involved in the specific instance of the process determine (plan) the sequence of activities as they proceed.
A third feature is the importance of data in determining the flow of each process instance. Decisions or judgments are key elements in Case Management, and they, in turn, depend on data which is accumulated as the specific instance is executed, and used in the decision-making process.
There seems to be broad agreement on the points we have made, up to this point. As we proceed, however, descriptions of Case Management tend to vary quite a bit, depending on the types of instances the individual writer or speaker is focused on. At this point, we tend to lump the major differences into three types of Case Management that differ as follows:
- Case Management instances that focus on judgments or decisions. In this approach, the emphasis makes the problem sound rather like a rule-based problem. A complex decision needs to be made. Data must be gathered – in the most interesting case, from a Business Analytics application of some kind – and rules are applied to arrive at a course of action. The more you read about this approach the more it sounds like developing an expert system, as we did in the Eighties. And, in fact, many of the vendors who are supporting this approach are former expert system tool vendors who have repositioned their products for process work. This approach emphasized formalizing knowledge of the problem, developing rules and having a software tool that can process rules to arrive at conclusions.
- Goal Driven instances that involve planning and re-planning. In this second approach the emphasis is on achieving a set of milestones that eventually lead to a goal. Imagine a military team that is asked to rescue a hostage in foreign territory. The ultimately goal is to return the hostage safely to his or her own country. Milestones might include An Approved Plan, Finishing Preparations, Getting into the country, Rescuing the hostage, and Extracting the hostage. (Note that the emphasis in this approach is on milestones or events that betoken that a subprocess is complete, and not on the execution of the process as such.) One can easily imagine a team sitting down to plan such an operation (process). Will they drop from a plane at night, or swim in from a submarine? Will they steal a car to move toward the hostage location, or hike to it? The team develops a plan, but they also develop lots of alternative plans. As the action unfolds, one plan, focused on achieving one milestone, is abandoned and another initiated. The milestones and the ultimate goal remain unchanged, but everything in between changes as necessity or opportunity dictates. This approach emphasizes team planning, goals, the development of a variety of alternative scenarios, and flexibility. It also tends to place considerable value on preparing by practicing alternative activities so that switching from one to another will not disrupt the ultimate execution of the process. (In passing, note how this approach fits well with a “capabilities” view of process – an emphasis on alternative actions that may or may not be used when the process is actually executed.)
- Team Efforts that rely heavily on social media. This approach is often talked about but we have seen few concrete examples as to how one might actually analyze or support it. The essence of the instances, in this approach, are tasks or decisions that need to be made by groups that are geographically distributed and who communicate via email, and other social media. Clearly such interaction can be very dynamic. It's probably no more dynamic than a military team trying to decide on the best way to achieve their next milestone in a combat situation, but we have yet to hear anyone suggest how it might be formalized to make it easier for the participants.
Obviously, as practitioners work with Case Management concepts they are going to encounter problems that involve all three of these approaches, mixed together. At this point, however, we are not dealing with many real examples, but are, instead, mostly discussing thought experiments, as one always is when one is discussing the evolution of a new technology.
There is a strong tendency, at this point, for those advocating Case Management approaches to hype them, and speak as if Case Management is a major alternative to conventional process work. When one examines concrete examples, however, its exactly the opposite. One begins with a process that is largely routine. Then one finds, within the context of the routine process specific activities that are not routine. We are confident that, in most cases, Case Management, as we understand it better, will be seen as a set of techniques to use in dealing with specific activities within more conventional processes.
Consider our hostage rescue example, which sounds about as completely Case Management as one is likely to find. Most days, Special Forces follow routines. They practice particular activities, whether swimming ashore, or breaking into a hotel, over and over again, following set procedures. It is only on rare occasions, when a situation arises that calls for a team to design a unique process, assembled from routine activities, to deal with an actual rescue. Obviously the team will mutate the routine activities as the execute the actual mission, but it will all take place within a context of executing well practiced skills and using knowledge honed by repeated simulations.
Clearly business is faced with a growing number of situations that need to be specifically tailored for individual customers. Clearly this can only be accomplished by empowering teams of knowledge workers to assemble unique processes and to execute them in ways that will alter and evolve during execution. The question for process practitioners is how we can help organizations perform these cases in a more efficient and effective manner.