benefit from all our premium research
get premium membership now!
tell me more
related research from the MWD library
most recent posts
Thursday, March 3, 2011 by Neil Ward-Dutton
A few weeks ago I was talking to an experienced journalist about BPM – and he was pretty ticked off with the topic. He was complaining that he felt he’d been tricked by vendors and analysts into writing pieces about how the “year of BPM” was upon us a number of times, and he just hadn’t seen it come to pass. I can’t remember his exact words but he did say something like “this BPM stuff is dead, anyway, right?”
Then a few days ago I came across Mike Gammage’s post Why is BPM Delivering So Little? It’s an attention-grabbing title for a piece which actually argues the opposite.
I have to say I’m with Mike (though I’m not sure about his position on Lean and Six Sigma): I’ve personally seen dozens of companies, from midsized to multinationals, get very significant results indeed from implementing BPM concepts, practices and tools. I’ve seen efficiency gains of 40%, capacity gains of 30% and ROI in 6 months.
I’m also coming across quite a few people who are sceptical about BPM. They’re not seeing a flood of completed ‘BPM projects’ being talked about in public forums (including in the press), and so they’re concluding that BPM is a bust.
I think BPM technology tools – the things that have ironically created so much value in those organisations I’ve talked briefly about above – are partly to blame: or put more accurately, the way that those tools have been promoted.
BPM technology tools are often promoted to the market in a way that makes the technology indistinguishable from the practice. However in an awful lot of cases, although BPM technology tools get used to great effect, no-one in the customer’s business knows of the project as a ‘BPM project’. It’s a customer service improvement project; a complaints management project; an order management transformation project; an employee onboarding project; an integrated billing project; a case management project; and so on. BPM techniques and tools are used to facilitate the improvement or transformation, but the term ‘BPM’ isn’t explicitly used by any of the people who really matter – that’s the people with the wallets (the project sponsors) or the people who will be affected by the changes (the call centre staff, HR staff, customer support agents, and so on).
There’s something else to consider, too, and that’s that in almost every case, a ‘BPM project’ isn’t a case of installing a software product and doing some development and configuration. It’s a particular approach to delivering a business change project that is likely (these days) to involve use of some specialised software tools – but which can be applied in many different contexts.
This difference is crucial if you think about comparing BPM to ERP as a wave of IT-enabled business change. Looking at the two, ERP has had a big advantage: it was, by and large, focused on addressing a clearly bounded and understood set of business activities and processes in a consistent way. Even if individual implementations of ERP applications differ quite a lot, the concept of ‘ERP’ is quite well-defined, and COOs and CEOs (and the consultants they work with) were able to quickly spread ideas and aspirations accordingly. BPM, on the other hand, is a set of techniques and tools that can be applied to a great many areas of business, with different goals (efficiency, time to market, scalability, innovation, and so on).
These are just two of the reasons why we haven’t yet seen an obvious “year of BPM” – and they’re not about to change any time soon. So when the next BPM doubter asks me “Are we there yet? Are we there yet?” I’ll say “No, we’ll be driving for a while yet. Be quiet and enjoy the scenery.”