Anyone even tangentially involved with the process improvement world has heard how Business Process Re-engineering went from the darling of the 90′s to the joke of the new millennium. But, do we really understand why? Here is one take on why this all went very, very wrong and with it, a prescription for making it work out much better. I’m not a business process historian or researcher but there are some classic scenarios that we hear over and over again.
I’ve touched on motivation and measures in a previous piece so I will skip that and go right to the next story. The problem begins when we fail to identify the true, end-to-end business processes. There seems to be a lot of confusion about what a process really is. As a result, we end up trying to fix a small part of the overall process, or we focus on a process area (comprised of many processes). Either way, our scope is either too big or the scope is too small. I’m going to focus on small today because we can walk away from an improvement effort thinking we’ve succeeded; only to be surprised when outcomes really don’t improve.
Don’t let talk of placing small bets obfuscate the facts: an end-to-end-process is a small bet. If you’re approach to improving it works, you can then scale similar efforts across more end-to-end-processes. What we tend to see, however, is departments placing large bets on process fragments that happen to flow through their department or functional area. They optimize this process from trigger/input to result/output; without much regard to their dependence on suppliers, or their customers. As a result, they also put measures in place to motivate participants to perform in a way that optimizes the local process.
I’m going to summarize a case presented in Workflow Modeling: Tools for Process Improvement and Application Development (2nd Edition) that focuses on an unnamed Telco company in order to make this point. This company went to its federal regulator to ask for permission to raise rates. At the time they asked, they were declined because, as it turns out, the regulator perceived that they were receiving too many complaints from the service provisioning processes. In other words, it was taking too long for them to respond to three types of service requests:
- In: the connection of a new telephone service
- Out: the disconnection of telephone service
- Move: the relocation of telephone service
One team was tasked to identify the processes involved in service provisioning. They came up with the five following processes:
Another team analyzed approaches for improvement within each of the five processes and had a great deal of success! In the Facilities Management process the engineers were responsible for handling the entire infrastructure required to deliver service to a customer. They performed detailed task analysis; including time and motion studies. What they found was that network engineers spent a considerable amount of time retrieving and manually updating large neighborhood-based network maps from storage cabinets. Each order was a completely separate cycle and due to the randomness of service requests, each cycle would most likely be for a completely different neighborhood. This cycle typically took 10 minutes to complete.
The solution was very simple, the service orders were sorted by neighborhood, and within each neighborhood they were sorted by outs, ins and then moves. Outs were handled first because it freed up facilities; Ins were next because new customers were a priority, and then moves. Each neighborhood was handled about once per week. They were able to reduce time-per-order (their local metric) from 10 minutes all the way down to 1-2 minutes! Everyone was very happy.
The Installation process consisted of installers driving from location to location to install equipment and complete wiring. There was a lot of wasted time driving around so a new route scheduling system was implemented so the installer was sent to the next closest customer premises. This raised performance along the measure of visits-per-day but didn’t necessarily mean they arrived when the customer expected them.
Doesn’t this look like success to you? It certainly did to this Telco; until the regulator denied their subsequent request to raise rates. It turns out, it now took longer to complete service orders and complaints were on the rise.
Let’s take a look at the diagnosis presented in this case study. Three basic errors were identified that led to this surprising outcome for the Telco:
- The processes weren’t named properly. A business process has a discrete countable result and if you take a look at Facilities Management you can see that it uses the word management; which is not identifiable or countable. Assign Network Facilities is much more specific and can be counted as a part of a specific order
- They confused process with functional organizations. They identified the work provided by a single functional area. This served to focus on the needs of the department instead of the needs of the customer
- They focused on achieving (local) task-based efficiency rather than on delivering an outcome the customer expected.
Remember the line about handling a neighborhood once per week? What that meant was that a customer’s request to move from one neighborhood to another wouldn’t be handled for about a week. But once it was handled, it would be handled very efficiently! Customers don’t really care how efficient an engineer is in performing a particular task; they only care how quickly they get their desired outcome or how reliable that outcome is.
To start, you need to focus on the result the customer is asking for and not on functional efficiencies. In the case of the customer that wants to move a more appropriate process name would be Move Telephone Service. It’s discrete and countable (telephone service is moved). A process is a chain of events that spans numerous functional areas and should be viewed in its entirety. Each of these events will be a sub-process associated with a functional area; but it’s not something that can be optimized on its own. There is interdependence between them since the customer is the focal point (both internal and external)
When end-to-end business processes are not properly identified, and when the focus is not on improving the ultimate result of the true process, you will almost always make a process worse, by improving it.
This post was written as part of the IBM for Midsize Business program, which provides midsize businesses with the tools, expertise and solutions they need to become engines of a smarter planet. I’ve been compensated to contribute to this program, but the opinions expressed in this post are my own and don’t necessarily represent IBM’s positions, strategies or opinions.
