Incremental process improvements are better than an overhaul. Is that true? I saw this strapline in an interesting blog I read recently, an excellent blog with which I agreed totally – except for this one statement. And I think I know what the writer meant, and understand his motivation for writing it – but I’ve been unable to let it go without comment.
First, they’re not competitors. At least, not if you understand the reasons for even thinking about changing a business process. They will, however, always be alternatives, and which one you choose depends on the situation you’re in.
They’re quite different animals.
- Continuous (or continual) process improvement is the incremental optimisation of a process through a series of small changes to parts of the process, rather than to the whole process. It is based on the current process, and goes from now to the future. It is concerned with finding places where today’s process could be improved, where marginal gains can be made. So we might change how an application form is approved ; we might switch a task from a senior person to a more junior one (without really changing the task itself); we might put this manual data store into Excel (no, really) – small changes to a discrete part of the process, that improves that part alone. It is the accumulation of small changes and their benefits that starts to make difference to overall process performance.
- Process transformation or re-engineering is the total redesign and re-implementation of a business process in its entirety. It starts with a blank sheet of paper, and begins somewhere in the future. Eventually, it heads back to the present to see if there is any possible migration from the current process to the future one (by, for example, using a process wrapper) – often, there isn’t – it’s a total rewrite. So we only do this when we’re making a large change, typically as part of a transformation programme, or as part of a complete technology upgrade. So here we might be developing an online-suite of services that ends up moving some of today’s batch processes to becoming online and on-request; here we’re rebuilding a process to give the customer a different (and better) experience than she has today. The total change in the process is designed to produce a step-change in its performance.
So, obviously, you do the transformations far less frequently than the improvements. Between transformations, continuous improvement should be just that. I think what my friend the blog writer was saying was essentially this – overhauls are rare, and should only be attempted when absolutely necessary or merited – most of what we do with processes will be incremental improvement. The progress of a particular process’s evolution will look something like this:
You’ll only know by looking at the problem and/or the opportunity (rather than the process itself) – that alone will tell you whether you should be making an improvement to a small piece of the process, or whether you need to overhaul the whole thing. And if you’re going to overhaul the whole thing, the decision to do it will be made and funded further up the organisation than the process analyst.
Second, there’s a case for having them done by different groups of people. The biggest impediment to success for re-engineering practitioners is knowledge of the current process. All you need to know is the desired output, the desired outcome and the name/role of the customer. (I leave out the input deliberately – in my experience, the start point for a re-engineered process can often be interestingly up for grabs.) Often, knowing the current process can get in the way of imagining a brand-new version of the same thing.
Third, many of the process skills you need will be broadly similar, but the approach and attitude will be different. Re-engineering is unavoidably a top-down activity, seeking to build processes that fit a changing strategy and a new enterprise architecture. Continuous improvement is bottom-up, and often opportunistic.
It’s always important to size the prize. This is often harder in continuous improvement than it is in re-engineering. While we can learn from Sir David Brailsford’s marginal gains at Sky Cycling, it’s important to remember that his accumulation of those small gains was focused on what he needed to win a cycling competition, rather than come second. That sort of all-or-nothing prize is not normally what we’re playing for with business processes, where the calculations are much more absolute than relative, so the effort to find (say) five 1% gains in a business process we run 5 times a day at a unit cost of £68 needs to be proportionate to the potential saving (in this case, about £4,400 per annum), and with realistic expectations about how the benefits of such small improvements are realised in business – often, they’re not, they’re merely banked by the process operators.
The danger of re-engineering when you should just be improving is that if you get to the end (which is unlikely) you will have spent a lot of money for a product that was not needed and therefore you have a small payback, if you have one at all.
The danger of doing continuous improvement when you should be re-engineering is that you will create an illusion of progress – in fact, the process will be even further away from what is required, and the inevitable future re-engineering will be made just a little bit harder.
So, look carefully at each situation, work out where the drive for change is coming from, and choose your toolkit and approach accordingly.
