#BPM2012: ACM Rears its Head
- September 4, 2012
- 7 Comments
I haven’t spent as much time this year as in previous years discussing ACM because for the most part, ACM advocates have stopped spending all their time trying to prove that BPM “can’t do” ACM.
Sandy Kemsley, however, attended the ACM Workshop at BPM 2012, and took a few notes and blogged about her conclusions. She called it “BPMN Smackdown by @swensonkeith” – But I believe his title was the more modest “BPMN is incompatible with ACM”.
It sounds like Keith makes a few arguments that we’ve heard before:
[..] in which he posits that BPMN is incompatible with ACM. He starts by saying that it’s not a critique of BPMN in particular, but of any two-dimensional flow diagram notation. He also makes a distinction between production case management and adaptive case management – a distinction that I find to be a bit artificial since I don’t think that there’s a hard line between them – where PCM systems have developers creating systems for people to use, whereas ACM has people doing the work themselves.
This has been one of the defining problems of ACM – defining itself by what it isn’t. Conceptually it just isn’t working very well, in my estimation, as a name that means something separate from amorphous names like CM and BPM.
But Sandy goes on to point out an additional problem:
The distinction between PCM and ACM has created a thin, rarified slice of what remains defined as ACM: doctors and lawyers are favorite examples, and it is self-evident that you’re not going to get either doctors or lawyers to draw event-driven BPMN models with the full set of 100+ elements for their processes, or to follow rigidly defined processes in order to accomplish their daily tasks. Instead, their “processes” should be represented as checklists, so that users can completely understand all of the tasks, and can easily modify the process as required.
Yep. Outside of these doctors and lawyers (and musicians), the examples start to run thin. Because even processes that are run off of checklists on an individual scale will benefit from a supporting structural framework (for which BPMN is a good fit) when we look at them in aggregate (macro scale). We’ve blogged about this before in the healthcare space.
Sandy lays out Keith’s argument:
Taking all of that together, you can see where he’s coming from, even if you disagree: if a system uses BPMN to model processes, most people will not understand how BPMN models work [if they are drawn in full complexity by developers, I would add], therefore won’t modify them; if all users can’t modify the process, then it’s not ACM. Furthermore, creating a flow model with temporal dependencies where no such dependencies exist in reality hinders adaptability, since people will be forced to follow the flow even if there is another way to accomplish their goals that might be more appropriate in a particular context.
Keith’s general approach is to lay out small points that you’ll agree with in isolation, to build a case toward a larger point that you would disagree with if he started with it. But there’s a challenge in this kind of debating / reasoning technique. I call it question bias, but it might better be called framing bias. If you frame the debate or question the right way, there is only one “right” answer, and the sum of these questions leads you to a dead end where you have to agree with the larger conclusion.
An example of this is the famous line “are you better off today than you were four years ago?” – tough question to say yes to when the economy is hurting. But similar questions might elicit dramatically different (and more important) results: “are you more optimistic about the future today than you were four years ago?” “are things better today than you imagined they would be four years ago?” Are examples.
In the case of BPMN and ACM, Keith discards the idea that you might build an “ACM-style system” (as he’s defined it) out of a BPMN suite. Meaning, users never have to see BPMN, but the modifications they request to their checklist are already captured by a model that can accommodate dynamic additions, deletions, changes, etc.
Since, at BP3, we already know it is possible to use BPMN to build such an ACM system, we’ve never been comfortable with the statements that ACM is somehow different than BPM. It is just a specific kind of process with a specific set of user requirements. Some BPMS tools won’t accommodate those user requirements. But some will.
Sandy makes a similar point, more eloquently:
You can create a BPMN diagram that is a collection of ad hoc tasks that don’t have temporal dependencies, which is semantically identical to a checklist. You can create alternative views, so that a model may be viewed in different forms by different audiences. In other words, just like Jessica Rabbit, BPMN isn’t bad, it’s just drawn that way.
Looking forward to seeing more of Sandy’s updates from BPM2012!