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:
- 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.
- ACM and BPM "methodologies" can both be accomplished with the same tool sets (software packages), even if you accept that the methodologies are distinct.
- 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.