OK, this is a long post, tea and biscuits needed…
Reading Brad Power’s article, (what a name!!! Brad, you missed your calling, you should be a film star…) http://blogs.hbr.org/cs/2011/03/uniting_the_religions_of_proce.html, and I can’t help thinking there’s some key understanding that’s missing here, which, not incidentally, is also missing from virtually every other ‘expert’ that bangs on about process improvement.
‘Walk before you can run’ is a logical refrain and yet reading this piece on process improvement (yet another) it seems as though we are exhorting people to do exactly the opposite.
Standardization is the key word: If you have a workforce of, say, 10,000 people how do you know what processes they are actually executing today? I can virtually guarantee if you talk to any random employee in, to take Brad’s example Shell, and ask what they do they will be able to describe the processes they are involved in. Then ask them to show where it’s written down and they’ll struggle to find the documentation. When they eventually find it, the documentation will say something different from what they actually do. Oh and by the way let’s go and ask another employee who does the same job in a different location and you’ll get another answer again… and again… and again.
If you don’t believe me ask Carphone Warehouse; during their keynote presented at Nimbus’ IP09 event, they showed how big this problem was for them: they asked 20 of their branch managers each with more than 5 years experience how to reconcile sales contracts – each had a different answer!
This is a massive, apparently undiscovered issue for so many businesses, and impacts critical functions within businesses (covered in a future post, however here we’ll stay with Brad’s process improvement focus).
The ‘running’ referred to earlier is the process improvement, the ‘walking’ is standardization.
Given that we can’t get people to work the way we want them to now, what is the point in trying to improve what are patently non-standard processes today? Which one of the many (unwanted) variations are we going to improve? Or are we simply going to think big thoughts in small groups and do our cool analysis and then abdicate responsibility for actually deploying the processes and then ensuring that people actually do them?
BTW you would be amazed (or quite possibly shocked, horrified, reduced to fits of giggles – take your pick) if you knew what we have actually heard time and again in global companies; i.e. process practioners, BPM ‘experts’, who do not believe that it is their job to deploy, and then sustain process changes. This is core reason why companies are disbanding their BPA practices, referred to in an earlier post.
Let me spell it out: there is no point in trying to improve process unless you standardize first. In order to standardize you must have a process platform to allow you to do that. It needs to make working through process part of people’s day jobs otherwise the standardization you want won’t happen. And I don’t mean the output from a technical BPA tool or Powerpoint exported to your intranet; we all know that doesn’t work.
In doing the process discovery and making the decisions on to which existing process to standardize, you will make improvements simply by reducing huge inefficiencies of lots of people doing the same thing in different ways. Best Buy Europe saw a 5% improvement simply from this standardization.
Clearly you could use some improvement techniques during this process, fine, but you must have some way to deploy and embed the changes made.
I had a surreal experience a few years ago at a conference in Philadelphia. A fantastic presentation from the head of internal consulting at Coca-Cola, which, in my eyes rapidly degenerated into farce at the end: When asked what the key KPI was for her consulting group she said (I’m not kidding),
“how quickly we can fix a process issue that we’ve already fixed before”.
Asked for clarification she said that her team would use PI techniques in a certain part of the operation, improve things and then move on. Over time the ‘improved’ part of the business would drift back to old ways and they would be called in to fix it again. This was such standard practice that the time taken to re-fix was her core KPI…
The utterly frightening thing was her calm, normal demeanor and the fact that everyone nodded sagely as though this was OK. I was frankly astounded, even more so when I to spoke to her afterwards and couldn’t get her to see that this acceptance of the status quo was complete madness; “insanity is doing the same thing time and time again and expecting a different result”.
One other point Brad makes (although in fairness he may simply be repeating what he thinks the BPM religion believe) is
“Shell Oil’s downstream (refining and retail) businesses have rolled out a global implementation of enterprise software SAP with standard global processes”.
Let’s be clear: deploying ERP does not standardize business processes. In most organizations no more than about 20% of activities are automated in ERP and process automation software, and given that the vast majority of processes require both manual (no transactional system involvement) and automated activities, ERP/BPMS software can only automate a small fraction of the whole. Anybody who tells you otherwise is either sadly misguided or a SAP salesman…