My position paper for the Adaptive Case Management Workshop was to propose that “BPMN is incompatible with ACM.” I got a lot of flack from the hard core BPM disciples In spite of clearly stating that ACM is designed for knowledge workers to create their own process plans, many many still believe that there will be a process professional creating plans for others. I sometimes feel as if I am having the following conversation:
(Clarification: while there are serious discussions about the nature of ACM, I have included here ONLY the comments and arguments made that ignore the definition of ACM. In other words: they didn’t read the homework.)
Me: BPMN is not a good language for describing a plan for a knowledge worker, because it requires a skill beyond their profession. Most professionals are very busy keeping at the top of their field, and needing to learn a special language for expressing their plans becomes a barrier in getting their daily work done.
Doubting Thomas: That is OK, because the knowledge worker won’t be the one making the solution. Instead, you can have a trained process analyst do that. For them, the power and expressibility of BPMN is what they need.
Me: But you can’t have a process analyst doing this, because ACM is a technique to handle unpredictable work patterns. The knowledge worker does not know what the process is going to be, until the work is already started.
Doubting Thomas: “You can’t really be talking about unpredictable things. You must be talking about regular old routine processes, but just saying it this way to make it sound fancy.”
Me: No really, we are talking about knowledge workers, and a way that each knowledge worker can specify their own pattern of goals, adding and removing goals as they need it.
Doubting Thomas: “You can’t really be talking about knowledge workers doing this, you must really mean programmers and system designers. They are the only ones who draw BPMN diagrams.”
Me: Actually this is not about routine processes. It is about work situations that are different every time, and for which the knowledge worker brings unique knowledge to. Think about a doctor who creates a treatment plan for a patient. That plan may be different for every patient the doctor has. Can you imagine a doctor using BPMN to describe a treatment plan?
Doubting Thomas: “Of course not! Why are you talking about a doctor? We are talking about a business process here. Everyone knows that doctors don’t design business processes. Who ever got the idea that this was about doctors?”
Me: The doctor is the knowledge worker. ACM is defined as that technology for knowledge workers to plan and complete their work. Thus a doctor is a perfect example of a knowledge worker, and a perfect example of the kind of person who needs to be able to make a process plan.
Doubting Thomas: “You can’t be really talking about work where the process is different every time. You should be talking about repeatable, routine processes, which can be diagrammed with a prescriptive language, and are done over and over again the same way.”
Me: That is just it: the name of the book is “Mastering the Unpredictable”. We did not call it “Mastering the Predictable” or “Mastering the Routine”. Traditional BPM is for predictable processes — and it works quite well for this. Adaptive Case Management is for a different situation entirely.
Doubting Thomas: “There you go again, saying that ACM is not BPM. We all know that ACM is just another kind of BPM, and it is about business processes, but you just keep on confusing us by this ‘marketing stunt’ of pretending that it is about something else.”
Me: But we said at the very beginning, even in the title of the book, that it is about work patterns that don’t repeat. We said that traditional approaches of pre-defining the process map will not work, and that is the reason we need to look for an approach that has different design criteria.
Doubting Thomas: “It’s all about executing a process to reach a result. Only processes might differ in characteristics and might be managed in different ways to get there. Therefor you are really just talking about BPM and giving it another trumped-up name.”
Me: We called the book “Mastering the Unpredictable” because it really really is about work situations that are unique, and don’t repeat. I don’t care what you call the technology that achieves this, but we must be clear that it must support processes that are unique and non-repeating.
Doubting Thomas: “That is just silly. All work repeats. No one ever does anything new. We come to work and we do exactly the same thing all day long. Process designers just need to write down the process and it will all be automated.”
Me: What you say is not true for knowledge workers. They think for a living. They figure out by themselves what the right thing to do next. Consider Dr. House (the fictional TV character) who has to come up with innovative treatments and often changes the treatments mid-way through.
Doubting Thomas: “If all we are talking about is people winging it on the fly. Why are we even talking about it? We should be talking about repeatable, predictable processes that have logic and fixed procedures. ACM should really be about the repeatable (and yes, extensible) logic, not just the ad hoc.”
Me: You are welcome to talk about routine, predictable processes all you want. But ACM is about unpredictable processes that can not be (fully) defined in advanced. ACM is about “Mastering the Unpredictable” when you don’t have the luxury of a repeating process. What do you do then?
Doubting Thomas: “That’s just ad hoc, a checklist made up on the fly. And even with less ingenious practitioners we have it already: it’s called the patient chart. We don’t need anything new for this.”
Me: Many people do this today with paper and pencil, but the vision with ACM is that there is a better way. Paper does not communicate over long distances and to large groups of people when needed. Paper does not allow for aggregate analysis across many cases to see what approaches are working. Paper does not inform remote people of things that need to be done, and remind them as deadlines approach. In many ways, ACM will need to act like that paper patient chart, and it may even look like a paper chart to the doctor, but it has some nice characteristics beyond just paper.
Doubting Thomas: “But you said this was about work, and work is organized, done the same way every time. I really want to talk about repeatable work processes. Why do you get off on ‘slapping down’ BPMN anyway?”
Me: You are welcome to talk about BPM and repeatable processes all you want. However, ACM is about unpredictable processes, ones that are not routine, and are performed differently every time. I don’t have anything against BPMN if you have repeatable processes. My point was to show that it is unsuitable for knowledge workers who have to change the process all the time.
Doubting Thomas: “whether we execute work in a BPMS or with an ACMS, or any other kind of computer system, we are doing just that designing and developing a software system, and to do so requires a more detailed level of procedure to be described. Again an ACM just like any other system needs that level of detail. So no real difference here then.”
Me: From the beginning, I have said that knowledge workers have to specify their own goals, their own procedures, their own sequences of tasks. They can’t do this “up front” and that the definition of the process (the set of goals) emerges out of the working activity. I am not just making this up. The situation is defined as this one where you can’t define the exact sequence up front in ANY level of detail. This seems to imply to me that we are not just “designing and developing a software system.” If you can achieve the goal of handling unpredictable processes that way, then I am all ears. But so far, instead of talking about how to support unpredictable processes, people keep telling me that we should focus on predictable, routine processes.
Doubting Thomas: “I don’t think companies care if their process is ACM or ‘normal bpm’. They just want it to work for their situation.”
Me: Well, yes, they don’t care as long as it works. The point is that there is a situation of unpredictable processes. How does that get supported? Unpredictable situations cannot be supported with an approach that requires the process to be designed in advance.
Doubting Thomas: “Bottom line, BPMN is one way to represent a process and as long as that representation is accurate, the semantics from others on slicing and dicing to the nth degree is moot.”
Me: The critical issue is not accuracy. A BPMN diagram in place of a grocery list is overkill and unjustified. Before the next time you go to the grocery store, draw a BPMN diagram of everything you are going to do. Do it in advance, or do it while you shop, but do only what is on the diagram. I can safely say that nobody will do this, because it is ridiculous amount of overhead.
The BPMN diagram could be accurate. It could be complete. It would truly represent the shopping process. Why then, you must ask, don’t people use BPMN diagrams to plan their visits to the grocery store? Wouldn’t it be better to be more accurate?
Doubting Thomas: “That is completely unfair. Shopping isn’t work! Work is stuff that is repeatable, regular, and done the same way every time. Shopping is all messy and complicated. I am getting different things every time. Sometimes I need a few special ingredients for something I am planning to cook. Other times I have to replace staples normally well stocked but eventually ran out. Sometimes I even figure out what I am going to cook based on what I see in the store. This is just not at all a description of a business process because it is so unpredictable.”
Me: That is the point. Many of the things that knowledge workers do is like shopping. You have a shopping list of goals to be completed, and the goals can even change while you work, but you just figure out while you are there exactly what to do. This is what we mean by an emergent process.
Doubting Thomas: “The argument as to whether business people would be able to construct BPMN diagrams is moot, intelligent people can learn to do almost anything. ”
Me: Of course, an intelligent person can create a BPMN diagram in advance of grocery shopping, but they WON’T, and the reason is fairly obvious.
Doubting Thomas: “But then you don’t need a BPM system at all. You need a shopping list. BPMN would be complete overkill.”
Me: That is my conclusion as well. BPMN is incompatible with what knowledge workers, the users of an ACM system, will need to do. The benefit of an ACMS comes not from the complete and accurate specification of the process plan. It comes instead from the communications and coordination that it affords. There is a huge difference between a BPMS and and ACMS for this reason alone.
Doubting Thomas: “OK, but some programmer might use BPMN inside the system, and completely hide it so that the knowledge worker does not even know they are using it. The end-users will never touch BPMN any more than they would have to in a BPMS deployment.”
Me: Yes, that is true. The system might be built using BPMN internally, or Java, or C++. But remember the processes plan can not be specified in advance and so the plan can not be expressed in BPMN, Java, or C++. Instead, knowledge worker must create the goals/steps as they work. That list of goals, or steps to achieve them, is the real process plan in the work case. It is that process that drives the case forward, and it is that process that can not be specified in BPMN. If you are talking about pre-defined processes embedded in the system, then that is a BPM system, and certainly case managers, knowledge workers will also use BPM systems. But don’t get confused: those pre-defined processes don’t address the problem of “Mastering the Unpredictable”.
Doubting Thomas: “But talking about confusing. Why make ACM so special (people have been doing their jobs acm style for ages) and place it against ‘normal bpm’.”
Me: We have never claimed that ACM is BPM. Others have claimed that ACM is just BPM, but those same people generally do not care about knowledge workers or emergent, unpredictable processes.
The title of the book was “Mastering the Unpredictable”. How could we have made this more clear? Some don’t believe that there is any such thing as an unpredictable process. Some people think this is a marketing stunt.
However, I urge those who are interested to consider: what does it really mean to support work that is different every time? Different like the way that you visit a grocery store is different every time. You might say: “Yeah, but I wouldn’t use BPM for that!” I agree.
It is strange, because nothing was more strongly emphasized than how the knowledge worker has to be in complete control of how the process emerges from the unpredictable situation.
Adaptive Case Management really is about the working and planning of the knowledge work, by the knowledge worker, for the knowledge worker. -Keith Swenson
In a learning organization, people are continually learning how to learn together -Peter Senge
Note: most of the “Doubting Thomas” statements are taken from actual statements, either spoken to me, or written in exchanges, and I have used them here, if not word-for-word identically, at least representing the sentiment accurately as it was meant. I did not identify or reference the individual, not wanting to put anyone on the spot, but I remain indebted to these individuals for their contribution to this blog post.
Keith, I don’t think anyone is going to find it too convincing to set up these straw men so you can have an argument from both sides. It is a bit like playing checkers with yourself and winning 🙂
I can’t say that I agree you’ve captured the sentiment of the folks you argue with. You’ve captured the sentiment as you see it, rather than as they would see it. There’s a bit of a difference, I think.
Out of curiosity, what software language would you propose that the authors of ACM software use? Since you said up above that it can’t be: C++, Java, or BPMN? Or am I misunderstanding your argument on that point? (I’ll just assume that any misunderstanding is my fault 🙂
Scott, I am grateful for your persistence in expressing your point of view. The point of this message is not a thorough refutation of all arguments, but instead to show the needlessly illogical argument and circular reasoning which is behind MANY of the comments I get. The very definition of ACM is to handle unpredictable work. It is then strange when people tell me that is shouldn’t be for handling unpredictable work. Also, many of the arguments about the form that the technology should take, make assumptions contrary to the stated requirements. People will then buttress their position by including details from existing systems that don’t meet the stated requirements. Often there is a claim to “common sense” based on experience, but without any experience of the actual required environment.
It is as if Frank sets out to design a boat, and Mark say “you should be designing a car”. Then Mark points out all the great features of cars. Frank points out that cars don’t go on water, and Mark responds with: “you don’t want to go on water.” Frank assured Mark that he does, but Frank is wondering why Mark didn’t listen in the first place. It gets very surreal when Alice then says “you are really just designing a kind of car”. The more subtle arguments say “What you want is exactly like a car, except one that goes on water” which is usually followed by a list of features that cars have that are incompatible with going on water. In some sense Frank feels sorry for Mark and Alice because they have never seen a boat or experienced a boat, so all they can think of are cars, but the stated requirement (that it goes on water) should be clear.
In this case, the stated axiomatic requirement is for ACM to support working patterns which can not be known in advance. There are many derived requirements that flow from there.
It seems you are still unclear about the implementation language. The knowledge worker has to express the process plans. The knowledge worker has to know the language that the plan are expressed in. The knowledge worker does not know Java, C++, or BPMN. Therefor, the process plans can not be expressed in Java, C++, or BPMN. That is what I mean, when I say that the process plans can not be expressed in a something like BPMN. When you say that a “system implements BPMN” or “uses BPMN”, most people would assume that the process plans would be expressed in BPMN. That is stated purpose of BPMN. We have had this discussion before, and I have agreed that a programmer might us BPMN the same way that they use Java or C++ to implement the system. (Actually I believe most programmers would find Java or C++ or C# far superior for implementing the system, but I agree it is POSSIBLE to implement in BPMN.) However, if you say that BPMN “is being used” to support the process plans, you would be misleading people into thinking that the process plans were expressed in BPMN. You see: when you implement a system in Java, the user never actually sees any Java code. If you mean only that the underlying system is implemented in BPMN, but this is never seen by the knowledge worker, then I agree that BPMN could be used. But most people would be confused by this: why use BPMN when nobody can see it? And the BPMN would not have the process plans in it, since those plans are created by the knwoledge worker. It is not clear to me why you would want to say that the system uses BPMN, when you never use it to express the process plans. But if you want to implement this way you can. My point is clear: the process plans can not be expressed in a something like BPMN. I think it is misleading if you say you are going to include BPMN, but not for process plans. However if that is what you mean, I conceded the point.
It isn’t that “i’m unclear” it is that “i’m unclear about what you meant” and asked for clarification. i think your statements that BPMN is incompatible with ACM are more confusing than the argument that it can be used behind the scenes (as it is with BPM, or any other language/implementation area). I think it may only be confusing to someone who is only thinking process plans and not about how the software behind “process plans” would be implemented, and whether that requires new software category or software that process professionals are already quite comfortable and familiar with.
Now that we’re in agreement on that minor conceded point (misleading or not, it wasn’t intended to be), I can go back to implementing stuff you would call ACM in my little BPM/BPMN world 😉 Despite the fact that they’re apparently completely different and unrelated.
I think the differences are more like stick shift or automatic, rather than boat and car. Stick shift- you’re going to have to change gears on your own and tell the car what you want it to do. Automatic : someone has to build in the gear shifting apparatus for you ahead of time. You just hit the gas and it picks the gear for you.
But hey, analogies are always fun.
Why would you use BPMN when you don’t express the business processes in BPMN? That has never been clear to me. Someone else did this recently, and if I get the chance I will write a post on that. But somehow, it seems like inappropriate technology. Why not use a real programming language like Java or C++?
For a process guy, BPMN is a real programming “language” – just like UML and other techniques are. If it expresses the solution to the problem efficiently, and doesn’t have any major drawbacks then why not?
The obvious answer as to “why” is that you may be dealing with these self-directed/defined processes alongside more defined process. In those situations, makes sense to leverage the infrastructure, analytics, etc. (all invisible to the end-user-as-process-designer).
Obviously it needs the hammer/nail test, but it isn’t just the language, it is how much infrastructure do you have to create (or conversely, how much unused infrastructure can you jettison), and weighing those tradeoffs.
Interestingly though, it means BPMN can be as relevant for ACM as it is for BPM (to the “developer”- in quotes because i use that term loosely). Quite amusing when you think about it.
Pingback: Two Languages Divide but don’t Conquer | Collaborative Planning & Social Business
Scott’s longer response is at:
And – I might add – this is only the beginning of the exciting journey that we started with Adaptive Case Management and Adaptive Process Management in general. Even the first step already yields substantial benefit, but there is so much more to explore and to exploit for the benefit of the organization that starts the journey of Adaptive Process Management. In the first time in history it is possible to manage processes of knowledge workers with similar – but not the same -methods and tools like it is already possible in classical Business Process Management.