I am just now getting around to a post by Alxander Samarin called “Let us architect the use of existing technologies instead of blaming them for bringing complexity/inflexibility/etc. in enterprises.” This post starts with a well-reasoned overview of the situation, which is accurate and understandable. I highly recommend this post. However, while I don’t want to, I must disagree his conclusion.
Here are some things that he gets right:
- BPM is a management discipline, and we should not get this mixed up with the technology and/or tools
- His description of the difficulties of unpredictable work is accurate
- human-being’s knowledge, creativity and abilities are the critical success factor
- The word “automate” has to be clarified, and he does.
- case management shouldn’t try to replace a human, but assist him/her
- data capture / handling is an important part of this
- coordination is key, between individuals and groups, and involves patterns
- The aim is to provide an “actionable work execution coaching/guidance” for the business.
He understands the situation clearly, but how then can he come to the conclusion that “the BPM discipline is rather applicable for managing of cases“. There is a flaw in the logic that leads up to this, but it is not obvious.
He defines BPM: “to model, automate, execute, control, measure, and optimize the flow of business activities”. He refers to these as the 6 BPM functions. He says that there are many choices that you can make, and he outlines three example variations:
- one process definition (prepared in advance) for many instance (1-to-N)
- one process definition (prepared in advance) for each instance (1-to-1)
- No process definition in advance. (the zero case)
This gives you the feeling that there is a nice spread of possibilities over a range with no discontinuities, and therefor inclusive. But zero, is a very special case, not like the others.
BPM as a management discipline is based on Scientific Management. Central to this is the concept that the way of doing something, is separate from the doing of it. BPM is called “Business Process Management” and the word “process” within the title is not there by accident. BPM the discipline is based on the view that work (within an organization) is best thought of as a process. It is described as a process. The process is abstracted away from the workers, with the explicit understanding that one is trying to find the “best” process to use for all workers. But without a process, you don’t have BPM.
You can have parents with one child, parents with two children, parents with any number of children, but not zero. A couple with no children are not parents. Children are essential to the concept of parenthood.
The concept of a process is essential to BPM. Case management, on the other hand, might have a process, but it might not. Many cases have no process at all.
Example of case without process
I was challenged recently to give an example, so I have one: recently a group of us completed the “Mastering the Unpredictable” book project. I created a space to track this project: all of the initial concept documents were placed there, all the guidelines, the subject outline, the assignments of subjects to people, the rough drafts, and the final proof copies. I had never run a project like this before, so I had no process to run. Instead, when I needed to communicate I sent email to everyone (a capability of the system). The project space kept a history of everything that was done, and controlled access appropriately, but there was simply no process.
We had a goal to accomplish, and we coordinated work across three continents, but we had no predefined process, nor did we at any time engage in anything that might be construed as process modeling. In fact, given the 6 BPM functions, at no time did we model, automate, execute, control, measure, OR optimize the flow of business activities. A case management tool can support this kind of case. However, using the definition that Alexander supplied, we did not use not do the practice of BPM.
This is not a word trick
I am not playing a shallow game saying that since process is the “P”, if there is no process it can’t be BPM. The problem runs much deeper.
BPM is fundamentally about process. BPM practitioners views the world as a set of processes. Everything is a process, and we accomplish things by examining those processes, modeling processes, automating processes, executing processes, measuring processes, controlling process, and optimizing processes. The process is an abstraction of the way that work gets done, and the practice of BPM is to make it explicit. But case management does NOT have to do this.
I am sympathetic to the idea that a case manager is just a process designer who does the designing while doing the work — but this is a misleading concept. Thus, a doctor will design the treatment plan for a patient while the patient is being treated. A judge will design the course of action for a case while presiding over a court. An executive will design the action plan while running the board meeting. At a very abstract level, you could say that these are process modeling activities — but in reality these are done in a starkly different way that bears no resemblance to anything we know of as process modeling in BPM. It is not just a technical difference, but the people themselves do not approach the subject as anything like process modeling.
Dan Pink write long and eloquently in “A Whole New Mind” about how the world will be run in the future by “right brained” people. These are people who don’t view all activity as being composed of discrete processes, but in fact there are certain problems that are solved in a holistic way using native intellectual capabilities of intuition and understanding. Left brained thinking was very important since the industrial revolution, during the mass production of work, but it takes us just so far. Knowledge workers engage in a different form of work which is hard to describe in terms of a process.
Simply put: the practice of case management is not just BPM “done on the fly”. A case manager is not primarily concerned with modeling, automating, executing, controlling, measuring, and optimizing the flow of business activities. A case manager, instead, wants to get things done. Case management is concerned with representations of goals, and sub-goals (which looks like tasks so some, but are different), while in BPM the goals drive the design of the process, but are not made explicit. In in the practice of BPM, you want to perfect the processes to be repeatable thousands of times, but case management is not about mass production, but about making a one-off custom solution for this one situation that will probably never happen again, so extra effort o make the case repeatable is wasted. Case management is centered on business entities, not processes. These all may seem like small changes, but the whole adds up to enough difference that justifies a fresh re-design.
This requires a Whole New Technical Suite?
Not necessarily. The underlying capabilities between Adaptive Case Management (ACM) and BPM are very similar, and I think this is where Alexander was coming from. When you need process analytics, you probably can use the same analytics engine. When you do need data connections to retrieve from a web service, those connectors might be the same. If you need a stimulator, then the simulator might be the same. Many of the technologies you need are the same.
But don’t fall into the reductionist trap. Reductionists think that if you need capability X, Y, and Z, then any system with capabilities X, Y, and Z will do.
Let me argue by analogy: imagine a company that builds farm tractors. A customer comes to them and proposes that they build a race car. The critical components needed for a race car are: an engine, a transmission, four wheels, and a control system for the driver. Tractors have an engine, they have a transmission, they have four wheels, and they have a control system. Therefor, we can use a tractor as a race car.
Like all analogies this is stretched, but it is equivalently outrageous to say: “Case managers need a process modeler, and a BPM system has a process modeler, therefor a case manager can use a BPM system.” This suffers from the same reductionist fallacy.
I don’t mean to say that the tractor company can’t build a race car. To be sure, their knowledge of engine design, transmission design, etc. could be leveraged to build an appropriate race car engine, transmission, etc. Their experience is valuable. However, I don’t think it is fair to say that they would start with the design of a tractor and re-architect it to being a race car. The purpose of a tractor, and the purpose of a race car, are so different, that it requires taking a fresh approach. Leveraging their experience with the technology, they would start with a clean design aimed at the purpose of supporting the needs of a race car. Many of the technologies would be substantially similar to tractor, but the focus on meeting the special requirements of a race car would drive the entire design at all levels.
The same is true with ACM. Many of the technical components are similar to BPM. Many of the players who build BPM systems will probably come out with ACM systems. But do not assume that a system designed to support the practice of BPM, will be necessarily useful for the support of case management. Due to the dramatically different approaches of these two disciplines, one centered on process, and the other centered on business entities, it will take more than a simple re-architecting of the current BPM technology, in order to give us ACM technology. It will require a fresh approach.