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.
My Analysis
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.
Thinking Matters 
HI Keith,
great post, summary and analysis. I see nothing that Michael Poulin has added to the idea of ACM. We made it very clear that one of the core aspects of ACM is the use of goal-orientation because there is no predetermined flow or logic. I also proposed that ACM includes BPM-like sub- processes and/or orchestration where necessary.
In ACM work can at any point in time become more or less structured as the goal fulfillment requires. You question if the switch from structured BPM to ACM processes might be too hard to handle for a normal user and I would answer that it purely depends on the kind of technology you use. In a BPM system you have just ad-hoc tasks. In many ACM systems you have templates that do not represent a predefined flow but rather a suggested work list. If the ACM system allows for ad-hoc creation of work sequences that achieve goals and recall structured process flows linked to goals then the transition is completely smooth and does not require any special skills.
So Purpose Case Management is just another name for ACM.
Good points, Max. What we need are more explicit use cases showing a case transition from structured to unstructured and back. I agree there is a lot of subtle dependency upon the way it is initially structured, and the right approach will make a lot of different. These difficulties are not obvious, and misconceptions abound. Thanks for the amazingly quick comment!
I agree for knowledge wokrer processes flexibility, tracking and participant empowerment replace predefined process structure and centralized control. For me that is the key differentiator between ACM and BPM. Jacob Ukelson CTO ActionBase
Jacob, a presence of a knowledge worker in the process is an indicator to me as well, replacing a predefined process is not a good thing in all cases. In some or many cases, particular knowledge of the knowledge worker may be incompatible with the knowledge (e.g. about mitigated risks) embedded in the process. Replacing a predefined process with an individual decision-maker should be taken very accurately to avoid “throw[ing] baby out with bathwater”.
Hi Keith,
it is good to read about the ongoing seek for (re-)integration of the various ‘x[CP]M” approaches!
> The above are hard problems, and nobody has a good answer for them yet
I would like to advocate the concept of a goal/purpose structure, which as far as I can see actually can give answers to these hard problems. Let me illustrate this with two remarks:
1. Tthere is no such thing as an ‘unstructured’ process (case, activity, …), since everytime people purposefully do something, the ‘purpose’ is already there, and it provides strcuture. It is important to emphasize that such structure does not imply at all *hierarchical* structure, so the mentioned breakdown is equally not a necessity (yet sometimes useful).
2. As for the matter of Amazon vs. Joe-The-Book the glue inbetween is the real-world entity named ‘contract’ – which is nothing else but a list of goals that each party has to reach/fulfil within a given frame. No matter *how* they reach it, they do have to, and obviously this provides exactly the structure that is inherent in the ongoing thing there (I sill prefer the term ‘process’ for such ongoing things, the connotation ‘fixed, token-based, unflexible’ etc. is not in my mind when I use the term, but of course I can accept that people have problems with these connotations and want to avoid the term (for some time)).
I’d like to mention the efforts of UBPML.org here, which is an attempt to formalize that goal/purpose concept into a unified framework. Yet I understand from previous discussions that people unfortunately ‘see’ in the concept just ‘old process thinking’ due to graphical similarities and admittedly due to the fact that the site is more a reference manual than a usage guide. 🙂 Nevertheless, I absolutely recommend it in the context of such discussions!
All best,
Andreas
Andreas,
I agree with (1) no such thing as unstructured process, but there are processes that are not structured “yet”. The question is: when does the structuring get done? Some people think all processes can be structured before hand, but they are simply being fooled by the “hindsight illusion” that makes everything seem clear AFTER they occur. It is not always so clear before hand. Should not call them “unstructured” but instead I call them “unplanned.” That is a different concept.
I also agree with (2) it is a contract. My point is that the process can not be separated into super- and sub-porocess fragments, but somehow must be sliced across a single level, where a fraction of the activities are planned, and another fraction at the same level need to be unplanned.
I will keep my eyes on UBPML.org, but I must ask the question: why do you think there could be, or should be, a single representation? One of the fallacies of BPM approach, and of scientific management in general, is thinking that there should be only one “right” way to do things.
Thanks for the comment,
Keith
I do largely and heartily agree to your points.
Regarding the “yet”, my picture is something of an “unfolding” structure, the good old term “develop” seems to have a very appropriate core (http://en.wiktionary.org/wiki/develop – de-“wrap, roll up, turn, wind”). The structure is emerging, not pre-existing, not even theoretically fixed in the beginning.
And I further much agree that all this kinds of simplified (!) structure is projected by us into things, it is a viewer-dependent simplification of the underlying many magnitudes more complex structure of life itself.
The core questions seems to me, why should we want to have such structure? Basically, the list of reasons is well-known: communication, coordination, externalisation of memory, ease of learning etc., which are all the same reasons that motivate the use of languages in general, be them human or machine oriented.
Certainly there is not “a single truth”, as we learned (after all and again) in the last century. Some tasks are solved best by simply doing them and talking with each other.
Nevertheless I think it is useful to watch out for stable, economic and appropriate representations. My point is: that (developing) goal structure (incomplete, graphlike-not-hierarchical) is the most basic and general approximation I can see so far, and it bears the potential of unification of the extremes and some further of the more complicated problems, which doubtlessly can be an asset.
I should add that the concept for sure would benefit from more work on it, with respect to user-friendlyness, completeness, standardisation and alike.
“Unfolding, emergent process” is exactly the right concept.
When exceptions demand that humans intervene and make decisions about how to address them, this can provide an opportunity for case management. Those decisions may call upon all the elements related to the case: information, process, and subject matter experts. This is why advanced case management augments BPM with advanced analytics, social software, decision management, collaboration and content management facilities in an integrated form. Further, these capabilities must be delivered in the context of a case to offer the case worker all pertinent elements required to make decisions affecting the outcome of the case. In this manner, we see how all the technologies associated with advanced case management work together to address exceptions and deliver appropriate outcomes.
Pingback: BPM Quotes of the week « Adam Deane
Hi Kieth,
I have not expected such detailed and constructive analysis of my article and grateful to you for it.
It seems that something about this publication escaped your attention and I’d like to address it briefly.
The article was published at InfoQ not because it relates to any technology but because it is in the realm of an enterprise architecture, more accurately, enterprise architecture implementation, which situate outside of IT. As I said, I is not about automation in BPM or ACM.
The article targets management models for structured and non-structured information processing. From a business organisation perspective, BPM and ACM are quite different ‘animals’ because, at least, they have different objectives (this is why I cannot agree with Max J. Pucher that “ACM includes BPM-like sub- processes”. Also, his statement “In a BPM system you have just ad-hoc tasks” totally mismatch my understanding of BPM). In particular, BPM has only one goal – deliver a particular result in an absolutely certain way because any other way may not guarantee particular quality of the outcome. ACM, in contrast, does not follow any prescribed actions/operations to resolve the Case. Moreover, BPM works against adaptation because (by definition) any variation in the process is a potential harm to the outcome.
This is why I keep BPM and ACM apart from each other. BTW, I had no intent to contribute anything neither into BPM not into ACM. However, I have noticed that a resolution of a Case via adaptive activities or strictly ordered activities target nothing more than the immediate goal or task. Also, these activities take some time to realise (even automation requires some time for development and testing). This may lead to accidental (or even intended) mismatch with the higher level needs or goals. An intended mismatch may be caused by political issues inside the company, for example. So, my idea of Purpose Case Management is (as you noticed it) a higher level container from both (or any) management models that focus on local/immediate tasks.
Just a recognition of such container changes peoples’ perception and allows to narrow BPM instead of making it Advanced (mercadeo). A business process may be correct or not, robust or not, but there is not justifiable difference between a primitive and advanced process (it is more likely that any ‘advanced’ process is not a process in the first place).
Thus, I would not call Purpose Case Management a hybrid between BPM and ACM; it is a higher level of management methodology that can include Dynamic Case Management, Social-BPM and others as well. Like in technology, we have a Web Container and EJB/BusinessLogic Container regardless if we use a Java JSP/Servlet or Microsoft ASP or .NET.ASP.
Anyway, thank you for the review. I am touched.
– Michael Poulin
Michael,
I think I don’t disagree with any of your points, but I want to clarify the terminology. Many people I talk to in the industry insist that BPM is a broad category that includes ALL different ways of supporting work. We don’t make up these terms, and we have to use the meanings that are most commonly understood. So many people have told me that ACM is a “kind” of BPM, that I have given in an accepted this. I don’t like it at all. Both you and I see a kind of BPM which is highly predefined and used for sequencing tasks through a bunch of people. We need a name for that, and I am calling it “Human Process Management.” I certainly agree that HPM and ACM are are quite different ‘animals’ as you say. The problem is only with the term “BPM” Replace HPM with BPM in your comment above and I think i agree with all of it.
I would like to see whether “Production Case Management” represents a new option in your model, or whether that is covered by your existing options.
So, I think this is quite interesting, and I am sure we will discuss more. Keep me up to date on where this goes. 🙂
Michael
I love the term purpose case management as it gives in itselves the explanation of adaptive case management. At the end it is describing the same, flexible and ad-hoc processes with the focus on the objective. I als agree that there is nothing like one solution, sometimes you need rigid process support sometimes you need flexible process support. In a knowledge environment is must be possible to leave the responsibility for achieving goals en organising work with the knowledge workers resulting in better en faster decisions.
Thanks for the comment. I certainly agree with the idea of “fit to purpose.” We should not be thinking in terms of a single technology to meet all needs, but rather matching specific approaches to specific needs.