For the vast majority, process improvement is the wrong focus…

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…), 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…


5 thoughts on “For the vast majority, process improvement is the wrong focus…

  1. Took me sometimes to read some the comments, however I no ifs ands or buts enjoyed the post. It proved to be pretty useful to me and I am certain to all the commenters right here! It’s always good when you can not only be informed, but also entertained!

  2. Mark, in fact if businesses drift back to the ‘old way of doing a process’ then this process is the right one! Not the one some completely disconnected process consultant consured up in some cost-cutting illusion. Standardization is fine for manufacturing, but you can’t standardize people and how they interact. A real-world process management solution MUST ALLOW the business to run the ‘same’ process in 30 different variants without having to design all of them or having to enforce a ONE-SIZE-FITS-ALL process.

    Additionally, all process versions will continue to evolve and they won’t evolve the same way. If all processes are made transparent by the process infrastructure then these units can even learn from each other and improvements might travel faster. BPM pundits think in enforcement when what a moden business needs is EMPOWERMENT!

    Let’s face it: BPM as a cost-cutting tool may have its place here and there but it is in the end doing more damage than good in the long run. I am in total agreement on ERP doing no more than 20% of precesses. I propose that’s all the standardization that a business can survive …

    1. Max, I think we’re going to have to agree to disagree here! (However as a clarification, the standardised processes shouldn’t be built by some faceless consultant, they should be built and agreed by the business, probably with just facilitation from an external or internal consultant. There is little point imposing on people.) Our fundamental difference of opinion (and it is fundamental) is based from my side on real-world examples rather than theory. I’ve seen literally hundreds of examples where lack of standardization causes huge inefficiencies and also risk/compliance problems. In any process architecture you clearly need to balance the need for standardization with necessary variance for local differences, and also ensure that you leave enough scope for innovation in areas that it is useful. Max, I’m not sure we’ve ever met in a client situation, should be interesting as and when!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s