Frank Michael Kraft’s post on Taylorism is interesting, in that it is a response to Jakob Freund’s post on the same subject, but with a different perspective, and a pretty balanced view.

Since I mostly agree with his post I’ll just focus on a few of my nitpicks:

“We cannot conclude that if a management style is good for physical production that it is good for brain work as well.”  We also can’t conclude that if a management style is good for physical production it is NOT good for brain work as well.  Or vice versa.  That requires more data and analysis than has been discussed on the blog posts linked above.

Kraft goes on to say that we should use “the right type of tool for the right type of work.”  To my mind, BPM has always been about that.  In my experience it includes mind maps, BPMN, BPEL, interaction diagrams, Failure Mode Effects Analysis, and other tools of the trade.  Not to mention the data analysis, simulation, optimization side of things.   Most of what I hear about ACM sounds like tools of the trade people have been using in BPM projects for quite some time (which is why, to me, they aren’t that differentiated).

He also has a nifty graphic:

And he’s right, when he makes the point that the arguments about BPM and ACM often sound like mutual exclusivity – only one can be right.  But I think the argument between these advocates is more along these lines:

• ACM proponents: ACM is different and separable from BPM as a method, and (less consensus) a tool set. Corollary: the language used often implies it is just better and more important than BPM.
• BPM proponents:  ACM is fine. But it is clearly one of the tools in your BPM tool belt, rather than its own distinct and separate market (tooling), and methodology.

It is easy to mistake the first group’s arguments as saying BPM doesn’t matter, or that ACM is “the only thing”.  Clearly it does matter, and the staunchest proponents of ACM will also say and write that.  It is easy to read the second group’s arguments as saying “BPM is the only thing.”  But the argument is a bit more subtle, it is just that BPM is the umbrella in these advocates minds.  Maybe this is consistent with “BPM is the only thing” – but only because the BPM proponents likely have a more flexible notion of “what is BPM” than the ACM group.

Finally, we see this from Kraft:

And – what we need is a “process funnel” – as I tried to depict in the diagram. That is – a process that today is a completely unmanaged process (only by email) should become an ACM managed process. After a while – if it is a mature process – it can become a BPM managed process (for example by exporting it from an ACM system and importing it into a BPM system). After a while – if the process has further matured – it may become part of an ERP system.

I think Mr. Kraft is essentially correct, and most people would benefit from adopting some kind of funnel, just as he describes.  However, there are two small issues, which don’t detract from the main point he’s making – but the inconsistencies between these layers may not be obvious in a casual read, while they do affect how you approach the funnel:

1. ERP is a tooling (or software package), without a methodology.  In essence, the “methodology” is to standardize on a big software package.  That may also include giving up on differentiation, but it doesn’t have to.
2. ACM and BPM “methodologies” can both be accomplished with the same tool sets (software packages), even if you accept that the methodologies are distinct.
3. As a result, the transitions from one layer to the next have different degrees of friction with your IT and Business groups.

The funnel itself makes perfect sense.  In fact some of the customers and IT staff we’ve worked with prioritize their process work this way: by forcing new project ideas to go into the funnel starting with a fairly loose “ad-hoc” definition, and only with volume does it move into the more structured definitions more commonly considered “BPM”.

As usual, a strong contribution to the body of thought from Mr. Kraft, around ACM, BPM, and Taylorism.

Frank Michael Kraft has written a series of good reads on Knowledge Work, and this one is no exception.  In this post, he finds patterns of knowledge work:

This – in my opinion – is one pattern of knowledge work: the repackaging of parts of cases into a new case. But as I think I found out there are more.  [...] How did I find them? I did not do a scientific analysis, I admit. [... ] I had three sources for it:

1.  Managing my own knowledge work. As I wrote my own Adaptive Case Management system for my own knowledge work, I was able to organize my own work. As the number of cases increase – 3000 now including sub-cases – I become aware of patterns.
2.  Feedback from my first pilot. This was very interesting, because the main focus for my pilot is usability. Usability is strongly interwoven with these patterns of knowledge work.
3.  The things I always wanted to model, but never was able to. I governed the modeling of thousands of models of structured processes from all areas of business processes. But because the modeling language was only able to model predictable processes, I never was able to model unpredictable processes.

So when does a pattern start to look like a process?

Frank Michael Kraft has a good writeup of ACM questions and answers, that speaks well to people familiar with BPM :

Q: What is a specific example of the kind of knowledge work that might be supported?
A specific example is described in my chapter “Improving Knowledge Work” in the book “Mastering the Unpredictable”. There is Leona who works for a telecommunications company as an engineer and she needs to do phone support. The work she does in the support area is described with examples, as customer complaints need to be solved. Some tests need to be executed and some countermeasures need to be taken. The work is unpredictable, because the tests and the countermeasures depend on the situation. However the work can still be supported with Adaptive Case Management.

What I like best about his writeup is that he doesn’t set out to bash BPM before making his case in favor of ACM by first describing the problem, then describing the solution (ACM). He has a series of posts on the subject, all worth reading.

However, if I may be so bold, let’s look at the last statement.  “… However, the work an still be supported with [software package or knowledge work management approach]“  The part in brackets, Frank has filled in with the words “Adaptive Case Management.”  But the important thing isn’t the three letter acronym (or three word phrase) that describes the space.  If you are actually implementing your knowledge work emergent processes, the important thing is what the capabilities of that software (or management approach) are – and how well it supports your work.

Max J Pucher in a comment on Keith Swenson’s blog said that he didn’t care what label was applied to Papyrus by the industry or analysts – it solved problems and created real value for clients.  I guess I feel the same way.  If software that supports the use cases that Keith Swenson and Frank Kraft are describing ends up being called ACM, I guess I shouldn’t worry about it too much.  But I think some of the negative things said about BPM software packages reflect specific experience with specific software packages.  Another package that carries the same name (BPM) may have quite different capabilities (though quite a bit of overlap as well).

Pega, IBM, Oracle, and others are going to position hard that they handle Case Management (and ACM) – and if the vendors and thought leaders pushing the ACM label want to keep it differentiated they’ll have to get into the technical details as well as the philosophical (panned versus unplanned, is a philosophical distinction more than a technical one), to illustrate why customers should choose one product over another for the particular challenges they’re facing.