In April, Michael Poulin made a proposal for something he calls “Purpose Case Management“. While I am not convinced that this idea represents a new category of technology, the discussion and analysis of the problem is well worth the read.
It starts with an extensive summary of the transition from process thinking to realization that not all things are a process, and the effect this has on technology to support work. He suggests there are four types: BPM, Social BPM, Unstructured BPM, and ACM. Purpose Case Management is then a hybrid which allows you to choose which of these you want to use at the appropriate time.
Why we do and how we manage: this section talks about management and the codification of it, and points out many limitations of thinking of everything as a strict process. That is indeed what we are up against. Life is full of surprises; how do we handle them? First thing we need to do is get over the idea that the perfect organization is in a steady state. I love this quote:
“When the rate of change outside exceeds the rate of change inside – the end is in sight”, – Jack Welch, the legendary CEO of General Electric.
Flexible & Unstructured: he points out the irony that BPM proponents must hype their ability to be flexible. He comes to the conclusion that flexible process is an illusion: usually people talk about being flexible about connecting to things outside the process, but the process itself is not flexible. Flexibility is not the same thing as being able to change the process when you create new versions.
Defining Flexibility: He gives a way to define and measure flexibility. One must remember that before BPM, people coded applications using a 3GL. If you needed five people to do things, this often meant essentially 5 different applications that passed data around. A change to the process meant deep recoding of these applications on variables that indicated state, which might not be consistent across all of them. Simple workflow / BPM allowed you to expose the process in a consistent way across all the steps, so that if you had to change the process, it was all there in a single place, and all the steps could be changed at once. While workflow/BPM measure low on the flexibility scale, they are far more flexible than what existed before.
Unstructured Process: He points out that the difference between a process and a set of actions, is that the process has logic to sequence the action. Without that logic, the set of actions is not a process. I agree, the term “Unstructured Process” is an oxymoron, and we should avoid it. The hype is an attempt for BPM vendors to convince customers they can have cake and eat it too. Everyone wants structure when it does not exist.
Social BPM: I am not sure he got the right concept here. He quotes Wainewright & Hinchcliffe that social business is an effort to “design enterprise systems around the people that use them.” This is misleading. For 30 years computer systems have been designed for the people who use them, with varying degrees of success. Social business is not simply about doing a better job of this.
Later he says “The notion of ‘social’ includes spontaneous, emotional and unpredictable human behaviour.” I suppose it does, but ALL work, possibly all human behavior, involves this as well. The point of social in not to make applications that are more human oriented.
I really think the key provision of Social BPM is to allow people to leverage their personal, self managed network connections in assigning tasks in a process. Network connections are like “roles” but goes one better because everyone can manage their own network connections, and this makes the BPM more powerful. Poulin never touches on this point.
Adaptive Case Management: Poulin’s discussion of ACM it pretty much on target. He ends by concluding that it is not scalable, not controlable, and so it needs a container….
Proposal: He proposes a new category “Purpose Case Management” which is a hybrid. You break goals in to subgoals, and apply one of these to each subgoal as needed. It is important to keep in mind that things will morph over time from one type to another, so you can’t predetermine which type a particular goal will need. A routine patient visit to a doctor might suddenly turn into a life threatening emergency. It includes the idea that you break your goals (purpose) into subgoals (purposes) which are then implemented on or the other approach. There is a provision to change approach if the existing one is not fitting the purpose because the situation has changed.
Michael Poulin wrote this about the same time that I was writing my post on “Seven Categories to Replace BPM” including my concept of “Production Case Management (PCM).” Someone pointed out that I should include Purpose Case Management in the mix. It argues well that a mix of approaches should be used, which I agree with, but I decided to leave it out because I don’t think it defines a fundamental new pattern. I agree with the idea that there needs to be a mix of capabilities that work well together, but the following issues need to be addressed:
The Predefinition Problem: Having parts of the work predefined to be structured, and parts to be ACM, is a non starter because unpredictable work is unpredictable. Michael has provided for this because you can start working in one mode, and then switch to another when you discover that you need it.
The Switching Problem: switching modes from structured to ACM, or from ACM to structured, may not be very smooth. It may not be possible for a non-programmer to accomplish this switch. The reason is simply that taking a structured approach drives design decisions at a very detailed level. For example, the variables that hold the information about a case might be appropriate for a structured case, and inappropriate for an unstructured case. Programmers learn to unfold the logic for automation and the result is not very natural for non programmers. Conversely, information collected for human consumption is not always useful for automation. While it is all theoretically possible, I question whether this is something a typical knowledge worker will be able to accomplish.
The Nesting Problem: It is tempting to to break work into parts (e.g. main process which calls sub-processes, which in turn call sub-sub-processes) and then assume that we will want to change the approach at a given nesting level. Poulin suggests this, and if you look on the web you will find hundreds of examples like this. The problem is that work is broken down different ways by different participants. The best way to illustrate this is to think about a partner exchange between two businesses (e.g. Amazon.com and a Joe-The-Book-Publisher). The process on one side of this exchange may be highly structured and automated, while the process on the other side is completely ad-hoc. We may not be able to represent all the work on one side as a sub-process of the other side, if there are multiple exchanges between them. This sort of thing happens within organizations all the time, where some of the people want strong automation, while others want maximum flexibility, and they are not separate nested parts of the overall work. The “work breakdown chart” is an illusion because it is not universal: it is common in multi-party collaborations for one person to break the work down one way which is natural from their viewpoint, while another participant would break it down completely differently.
The above are hard problems, and nobody has a good answer for them yet. Overall the article includes good analysis of the need for flexibility, and how existing solutions don’t meet this need, and there are good points in his proposal for Purpose Case Management.