Over the years the concept of business process analysis has been buffeted around by fads and enthusiasms. In the 1930s, it was often spoken of as “work simplification” or as “industrial engineering.” In the 19802 it was often termed “Performance Improvement” or “Six Sigma.” In the Nineties it was “Business Process Reengineering,” then “workflow” and, since 2000, it has often been referred to as “Lean” or as “Business Process Management.” In the last few years many people have begun to suggest a new term, “Case Management” (or Intelligent BPM).
This isn't the place to go into the subtle and not so subtle differences in emphasis that have accompanied each name change. Suffice to say that through all the changes, there have been two different perspectives as to the exact use of each term. Business managers have primarily approached any process initiative as an effort to improve the way the organization does business. For these people, a process is just another name for a system. When speaking very broadly, they usually speak of an organization as a system that takes inputs and transforms them into outputs.
The other perspective has usually been taken by more technical practitioners. THey usually emphasize the techniques required to change specific processes. For Six Sigma, the practitioner emphasis has often been on the details of statistical measurement and for workflow practitioners the emphasis has been on designing software applications. In all cases, those who focus on technique tend to focus on more specific processes and seek to improve the specific process.
No matter the particular name or the perspective, business process change has almost always involved the development of some kind of process flow diagrams. The diagrams may be as simple as a high level systems diagram with inputs, a box, and outputs, or as complex as a very detailed network of BPMN symbols that can be used to generate software code for a given sequence of activities.
Over the last two decades I have worked to develop a comprehensive approach to business process change, based on core concepts that are rich enough to accommodate all of the various specific approached and perspectives I have mentioned. I have wanted to create a body of knowledge that can grow and improve, a body of knowledge that can form the basis of a profession and systematic practice. In this spirit, I have resisted calls to abandon one approach and embrace another, changing names and perspectives. Instead, I have emphasized how new ideas can be accommodated within a framework that is already serving us well.
I was pleased when the OMG developed a Decision Management specification that defined how processes and business rules fit together. I was upset that the OMG decided to develop as separate its new Case Management specification from BPMN. I am convinced that it would be better to accommodate Case ideas into the broader BPMN framework.
To my mind, BPMN, with all its flaws – and I have enumerated what I believe to be several flaws over the course of the past decade – is one of the major business process achievements of the past ten years. It has a core set of symbols that business people can use to describe very generic processes and it provides detailed extensions that allow business analysts and IT developers to extend a generic description to the point at which the model can generate software code. Technicians, working with different implementations of BPMN have demonstrated that one can transform a BPMN diagram from one tool to another and generate code – which assures that BPMN is going to have a very important future rule to play in process work.
I also feel very comfortable with the Case Management approach. I spent the Eighties writing and consulting with organizations about expert systems. At the time the ideas being introduced from Artificial Intelligence laboratories often seemed strange to programmers. Programmers were familiar with procedural concepts and languages like COBOL and C that were written and then complied. AI developers were using declarative concepts and interpreted languages like LISP and C++ to create much more flexible software applications. The heart of the expert systems approach was a set of business rules and an “inference engine” (an interpreter) that could link rules into inferential sequences, at runtime, and reach decisions.
Case Management, as the term is being used today, relies on the same AI concepts that we used when we developed expert systems in the Eighties. Today, however, they are being executed by computers that are vastly faster and more powerful than the computers available in the Eighties. (I don't want to oversimplify the differences – today's Case Management systems often rely on deep knowledge captured in neural networks, on data mining and on large databases that are searched for patterns that humans, on their own, might never find. At the design level, however, today's overall approach is surprisingly similar to the approach used in the Eighties.
The question I want to address in this Column, however, is how one approaches the design of a new business process application. Put in a slightly different way, one might ask if one needs different design techniques when designing a Case Management application. My answer, in a nutshell is “yes and no.” Much of what has served us well over the last two decades, especially when working with business managers, will continue to serve us well. At a more detailed level, however, as we drill down, we will need to add some new techniques to incorporate Case Management where it will be useful.
Let's consider a specific example. This is the classic definition of Case Management – a patient shows up at a hospital with a problem – say a pain in his or her chest. What happens? At this high level, when we sit down with hospital managers to plan an approach, we use a traditional approach. What happens in what order? We end up with a set of boxes: Admit Patient, Examine Patient, Conduct Tests, Diagnose Patient, Prescribe Treatment, Apply Treatment, Test Outcome…
At the level we are discussing, a BPMN core diagram with boxes and arrows works just fine. If you want to be a little more detailed, you might do a swimlane diagram that shows how the patient and various hospital departments are involved in processing the subprocesses described in the preceding paragraph. Using other conventional techniques we might determine how long various subprocesses typically took and how much they cost as a way of determining where we might want to focus if we wanted to save money or improve the speed with which we processed patients.
The key point, however, is that we don't need any of the newer Case Management techniques when we undertake this initial, high level, analysis of our hospital emergency process.
When we start to drill down into the activities within the subprocesses, however, things become more complex. Consider just one subprocess: Diagnose Patient. Given chest pains, we could be looking at indigestion or a heart attack. Time is of the essence, so someone needs to run some tests and then quickly interpret the test results and decide on an approach. This is not a situation that readily yields itself to a conventional BPMN diagram. The branching required to consider all the possibilities expands rapidly into a very complex tree. Moreover, there may be branches that can't be navigated with precision – we may find ourselves dealing in probabilities. This is precisely the type of problem that is best approached with Case Management techniques. We should not expect to have a single flowchart, established in advance. Instead, we may find that we need to develop a flowplan, dynamically, as we gather information and eliminate options or decide to expand our search to consider new options. Again, this is what Case Management is designed to do.
In effect, in a Case Management system, activities have triggers. If a test result indicates that we need more information about Y, then that triggers one or more activities that help provide information about Y. Those activities, in turn, may trigger still other activities. If you think of each activity as a set of tests or rules that are executed to add information that can be used in making a decision, you have a good idea of how the Case Management approach is structured. The key feature to note is the flexibility – activities are only added to the work flow as they are triggered. This means that, during the analysis phase, the process team needs to consider and develop a very large number of activities that might be used in one scenario or another. When we execute an actual instance of a case, however, the triggering mechanism assures that only those activities that are actually pertinent to the specific case are actually evoked.
Stepping back, when we consider a major business process, and discuss it with business people, we use a conventional (BPMN) approach to define the large-scale process. When we seek to refine a large-scale process, we may well determine that there are subprocesses or sub-subprocesses that require a more flexible approach and decide to use Case Management diagrams and techniques to define those specific activities.
A good process methodology will increasingly use one approach at the high level and multiple approaches at the more detailed level. Some specific sets of activities may require special techniques related to software development, or human performance improvement. Some may require specific techniques used in defining how decisions will be managed, and still others may require the specific techniques used to define Case Management problems.
Obviously, some will prefer to ignore context and the larger picture and focus only on the specific activities that will yield to Case Management techniques. This has already occurred often enough when IT groups have focused on only problems that require software automation, or when Lean groups have focused only on streamlining workflows. Those of us who believe in a top-down approach that begins with a clear understanding of what the value chain is trying to accomplish, and then drills down to specific problems, however, will use Case Management as a set of tools to be brought out only when certain specific subprocesses demand such an approach. And, obviously, those of us who take this perspective, will need both conventional BPMN diagrams for high level diagramming and Case Management diagrams for those specific cases when greater flexibility is required.
Some will write new books to describe a unique Case Management approach to process redesign. Some will write articles to suggest that process analysis and redesign is dead and to explain why it is being replaced by Case Management analysis. Most of this will be nonsense. Wiser practitioners will continue to analyze high level processes as they have in the past, and supplement their work, as they drill down into specific sub-problems, with Case Management techniques. Done with some finesse, this will result in a more comprehensive and integrated approach to business process management.
Paul Harmon
Latest posts by Paul Harmon (see all)
- Harmon on BPM: A General Management Model - July 4, 2022
- Processes and Capabilities - July 4, 2022
- Harmon on BPM: The Scope of Management - June 6, 2022
- Should Every Manager Be a Process Manager? - June 6, 2022
- Harmon on BPM: Management Processes - May 2, 2022
You must embrass all which do the process life in a bpm mapping work. To this, make a bpm with levelling, one level for information channelization, one for KPOs and KPIs, one for persons managing methods, one for decision making, one for tasks / work process with used procedures references (and mayby theirs computer links). Not only the subprocess sum diagram.
Paul,
+1 from me on that statement:
“Those of us who believe in a top-down approach that begins with a clear understanding of what the value chain is trying to accomplish, and then drills down to specific problems, however, will use Case Management as a set of tools to be brought out only when certain specific subprocesses demand such an approach. And, obviously, those of us who take this perspective, will need both conventional BPMN diagrams for high level diagramming and Case Management diagrams for those specific cases when greater flexibility is required.”
In fact, BPMN + CMMN + DMN, provide distinctive perspectives on “how things get done” in an organization. When used effectively together, they can yield tremendous insight and foresight for operational improvement or simply standardizing the way value is created by an organization.