Harmon on BPM: What is Case Management?

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.

Figure 1. A process complexity/dynamics continuum


Figure 1. A process complexity/dynamics continuum

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:

  1. 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.
  2. 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.)
  3. 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.

Paul Harmon

Paul Harmon

Executive Editor and Founder, Business Process Trends In addition to his role as Executive Editor and Founder of Business Process Trends, Paul Harmon is Chief Consultant and Founder of Enterprise Alignment, a professional services company providing educational and consulting services to managers interested in understanding and implementing business process change. Paul is a noted consultant, author and analyst concerned with applying new technologies to real-world business problems. He is the author of Business Process Change: A Manager's Guide to Improving, Redesigning, and Automating Processes (2003). He has previously co-authored Developing E-business Systems and Architectures (2001), Understanding UML (1998), and Intelligent Software Systems Development (1993). Mr. Harmon has served as a senior consultant and head of Cutter Consortium's Distributed Architecture practice. Between 1985 and 2000 Mr. Harmon wrote Cutter newsletters, including Expert Systems Strategies, CASE Strategies, and Component Development Strategies. Paul has worked on major process redesign projects with Bank of America, Wells Fargo, Security Pacific, Prudential, and Citibank, among others. He is a member of ISPI and a Certified Performance Technologist. Paul is a widely respected keynote speaker and has developed and delivered workshops and seminars on a wide variety of topics to conferences and major corporations through out the world. Paul lives in San Francisco. Paul can be reached at pharmon@bptrends.com
FacebookTwitterGoogle+Share

Comments

  1. Mike Prentice says:

    Hi Paul… While I have never posted before to your posts, I have been reading them for the past few years. I would like to discuss one part of the explanation that you posted that I feel is missing that will create a divergence in your 3rd to the last paragraph. You mention that the hype around Case Management is “major alternative to conventional process work”. I would not say that is hype but what makes a case management solution different from a BPM solution. In my conversations the difference lies in the point\focus\goal of the solution. Is it the case or the business processes? I can appreciate that this might seem fuzzy but it really makes the difference. In talking to BPM guys and Case guys the way the solution is approached and created are vastly different. (Yes, this is a technology delivered solution I am referring to).

    A case management solution could very easily contain structured and defined processes within the scope of it. These processes could be needed to achieve the goal, to get the outcome of the case. The understanding of what is needed for the solution will change the focus of questions that are asked and changes the interactions that are needed. The simple focus around case vs process will lead you down different paths. And yes there is a seemly high level flow as you mentioned early on and yes it is basically of little to no value because it is too abstract. Case Management is more than an exception process that it tied into this high level processing occurring. I have heard this mentioned in other conversations.

    There are some case management solutions that contain many well defined processes and in fact they overall follow a distinct and specific overall flow. I contribute that more to those that created and designed the solution are more process focused individuals and\or the business themselves are trying to enforce rules. This in despite the true business being executed without them or in more dynamic means than what are prescribed. Before Case Management was what it is and I was creating BPM solution, I ran into this issue and created a Case type solution without really knowing it was that then. The management was trying to state that the process should work this way but in real terms it was not because in order to get the customer what they needed all kinds of other “stuff” was needed to be done and going around the structured process. In the end the structured process was complete, but how it was completed was not as described. I also think that it might be difficult to think and take advance of a solution focus that is truly adaptive and let the workers have such autonomy.

    In the end, I do not see these as competing platforms, despite the fact it seems to happen. At an enterprise level, they work really well together. You as an organization, and you stated this, will have a need for both and it depends on the focus for that particular business problem or objective or action to use the best approach.

    I do find these conversations interesting and I know at this point in time highly debatable. This conversation gets even more interesting when you have theoretical\religious debates tied into how to make them real within an organization. And the years and vastness of experience on this will create very different opinions.

    I appreciate you time reading this.

Speak Your Mind

*