Find the Fault
There is no doubt that we live in interesting times. In many industries, the business environment is changing, with customers expecting increasingly quick, transparent and excellent service. I’m sure many readers (myself included) can remember a time, not so long ago, when “28 days delivery” was common when placing a catalogue order. Today, delivery within a couple of days is the norm. In fact, in some cities there are services offering delivery of products within hours. Speed of delivery isn’t the only change, in many industries the cost and inconvenience of switching providers has reduced, with information on just about any type of product or service being available online. This technological and social shift gives customers more bargaining power and means that if we get things wrong, it is increasingly easy for them to vote with their feet.
In an environment like this, where there is an expectation of immediacy and transparency, any kind of process or business system failure becomes abundantly obvious. Customers, quite understandably, demand a consistently good experience every time they do business. Back when 28-day delivery was the expectation, the customer probably wouldn’t notice if a process failure led to a 2-day delay in delivery. With the promise of overnight delivery, a 2 day delay causes havoc. For extremely good reasons, we simply don’t have the ‘buffers’ built into our processes anymore, and failures becomes immediately obvious.
The danger of knee-jerk reactions
When faced with a problem in this environment, there is an understandable impetus to move fast. There are often tempting, shiny, seemingly simple solutions vying for our attention. Yet it is risky to unwittingly embark on any kind of major improvement initiative without a thorough and holistic understanding of the problem. If we don’t understand the underlying problem and process, how do we know a particular solution will help?
Let’s take a hypothetical and fictional example. Imagine that an insurance company has received a high number of complaints that important documents aren’t arriving by post. Checks are made, and it is proved that the documents were definitely sent. An assumption is made that the missing documents are simply getting lost en-route. After speaking to the postal service provider (who cannot explain the issue), the company takes the decision to change to an alternative national courier firm. This requires contract re-negotiation, and a plethora of other activities, but the insurance company feels it is necessary to maintain their high standards.
A month passes, and the problem has got steadily worse and not better! The management team is concerned and embark on a more holistic analysis of the situation, including an examination of the processes that generate the missing documents. Upon analyzing the insurance sign-up process, they make an enlightening discovery. It turns out that a few months ago, the “customer address” field was made optional at quote/enquiry stage – and (understandably) many customers prefer not to give these details out when making an initial enquiry. To achieve this change quickly, a technical workaround was agreed, where a ‘dummy’ address would be stored in cases where a genuine address wasn’t available. Trouble is, the process and procedural guides for the sales staff were never updated – so if a customer called to buy a policy they had previously received a quote for, the sales staff weren’t aware that they needed to check for a valid address. This resulted in a significant number of policies with a dummy address being saved to the system. When post was sent to this address, it was (eventually) returned to the sender—and a huge stack of these returned items were unprocessed in a postal backlog.
Follow the breadcrumbs, find the process
This is clearly a fictional example, but I suspect that many people reading this blog will have seen similar situations occur. These patterns occur where the perceived problem is different from the actual problem. Before jumping to a knee-jerk solution, it’s important that we encourage our stakeholders to examine the problem, process and business situation holistically. Process analysis is a key tool in our armory – asking what happens before the perceived problem occurs and after. Following the breadcrumbs may help us find constraints, bottlenecks will help nail down the root causes. Taking time to map out the end-to-end processes and activities can help our stakeholders to see the bigger picture, across departmental silos and teams. Modeling the process in a commonly understood notation is important, and storing it in a central and commonly accessible repository will ensure people can also refer to it in the future.
Conclusion
In conclusion, often there’s a sickly-sweet solution sitting temptingly in view. Yet without problem and process analysis, we’ll never know whether it’s right. A little resource spent up-front can save significant resource later.