Simplification seems to be a fairly universal goal these days. This is particularly so among traditional firms with legacy infrastructure and nervous executives carefully watching the encroaching tentacles of new technology start-ups.
The symptoms of a complexity problem will be familiar to many: exasperated customers bounced from department to department, improvement projects running late, over-budget and never really delivering what they promise, lengthy time to competency for new recruits as they master all of the process variants, high error rates, remediation programs, overwhelmed staff, lengthy backlogs of change requests with even longer lead times, multiple hand-offs, a high proportion of failure demand work requests, hollowed-out-but-still-there systems, to name just a few.
The consequences are serious:
- Disenfranchised customers, just one more error away from defecting to the competition;
- Great difficulty in finding and retaining talent;
- Struggling to keep pace with the tech start-ups;
- Knowing the potential cost savings are significant but all too elusive to realise.
What To Do?
A typical approach is to start simplifying processes. There are a whole range of tool kits and passionate professionals out there ready and willing to help but something frequently missing is a way to measure the complexity. As we know – “what gets measured gets done” and this can certainly help in the design stages of your simplification program. Failing to test your assumptions about the degree of simplification that is achievable, before getting too far down the path, may lead to disappointment.
How Do You Measure Process Complexity?
There are probably more technically correct definitions but I’ve found the following useful:
preceding one, or Chipotle with its almost infinite range of menu options but limited SKUs in the kitchen. However, if the organisation lacks a comprehensive, in-use process architecture, then it’s reasonably safe to assume that the organisation will be complex to navigate and suffer the symptoms highlighted in the introduction.
Following the above approach, reducing any of these factors will, intuitively, simplify the organisation, but clearly this is much harder to do than merely re-engineering a single process. Some of the factors may be locked in such as the markets served. The burden may fall on just one or two factors and, to have an impact, the reduction needs to be significant e.g. the Lego story of halving the number of parts.
What Are The Costs Of Process Proliferation?
Horrendous! Unfortunately, they are dispersed amongst the fog of organisational day-to-day operations. They are not all neatly held within a single cost centre called “Organisational Complexity” and trying to put a number on them can be like trying to catch smoke. But they are there. Every process needs to be documented, maintained, quality assured and controlled, audited, productionised, resourced, to have a developed business continuity plan, measured, reported on, enhanced, simplified, re-engineered and automated, to name but a few of the activities required to support a process. Multiply that by the number of processes and, when your bowl of process pasta runs into the tens of thousands of strands, you start to realise just how expensive the lack of a formal (and adhered to) process architecture can be.
What Is The Path To Simplification?
In many ways the path to improvement is a familiar one:
However, before stepping on the path, a more fundamental decision needs to be made – to adopt process thinking across the business, with all the trimmings. This means: a process architecture, process model, process engineers, process owners etc. Get this right and then follow the stairway to process heaven!