I often find myself in violent agreement with Peter Evans-Greenwood in discussions of business and technology, so it was with a little surprise that I found myself disagreeing with his recent post about Business Process Management.
In fairness, I think the disagreement is semantic rather then substantive … I certainly have sympathy with the thought that BPM has been oversold and under-delivered, but not for the same reason; and I certainly have a similar antipathy to Taylorism. I think where the difference lies is in the expectations that we have about BPM. PEG makes the valid point that increasingly, the value generated from business is in the way we handle exceptions, rather than the relatively seamless and hassle-free execution of our standard business processes. However, his expectation seems to be that these exceptions are what BPM is about – I don’t agree. I think that BPM is most useful for automating the easily-repeatable transactions, using a technology that is more amenable to change than previous iterations of software development. Note – I don’t think it has necessarily delivered on that, but that’s where I see its application. And while I see a growing number of businesses (particularly in the digital and “knowledge” arena) whose core business is handling exceptions, most organisations still depend on the majority of their transactions being repeatable and automated. The promise of BPM seems to me to lie in the potential for incremental improvement in repeatable processes, and allowing that improvement to be actioned by the people on the ground, with a reduced reliance on some coding resource in the back office (or overseas) to change the way the software works.
Is this Taylorism? Perhaps … that might be an argument for another day 🙂 But the promise of BPM is that when you find a better way of doing things, the (automated) process is more easily changed – not that it enshrines the “one best way” of doing things. I suspect that one reason why BPM has under-delivered on this promise is more due to Taylorist principles still holding sway in management, rather than it being cemented into the software (I’ve had a rant about the “best practice” myth before).
I think Sig Rinde draws a useful distinction between the “easily-repeatable” and the “barely-repeatable” process, and I think this is where PEG is heading when he mentions Adaptive Case Management – and I definitely agree that something beyond BPM is required there (and that’s where Sig and Thingamy are playing).
The need for automated, easily-repeatable processes will not disappear – and here I believe (in hope!) that BPM can ultimately deliver on its promise. What I think PEG is saying is that these things are becoming table stakes, and if you want to thrive, and differentiate yourself in your chosen market, you will have to have a really good way of handling the “problems” … and I don’t think BPM was ever intended for that.
You nail my view in the last paragraph: linear, repeatable processes are no more than table stakes in this modern age. More so, companies are increasingly looking to partners, suppliers and on-demand services (bureau, SaaS…) to provide these linear processes, moving their attentions to the more interesting problems of selecting the most appropriate instances of a linear process in each instance and exception management. “Best practice” processes are something you buy when you need them, allowing you to devote your energies to more valuable problems.
We can sometimes overlook the “easily-repeatable” processes as the price of entry, but that alone makes them critical. We still NEED to have them happening; we just don’t want to spend a lot of time making them happen. There are still a lot of businesses spending too much time, money and effort on the table stakes, so they won’t advance until they are automated (via whatever is the best mechanism for them at the time – BPM or BPO 🙂 ) … this is where BPM still has plenty to offer.
Just imagine the cognitive capabilities we could unleash on the “wicked” problems if we moved along this continuum a bit faster …
It’s the eternal problem of getting the basics right while not getting distracted by the shiny new toy. We have the same problem with SaaS, and I keep on explaining to IT folk that even though you have someone looking after the technology stake, you’re still accountable for business continuity reliability.