Business process reengineering isn’t useless jargon or management gone mad – it’s a vital aspect of any business that wants to adapt, improve and survive.
Whether you’ve discovered a new tool that revolutionizes the way your processes work or you’ve realized that a process is being ignored to the point of being useless, this is the perfect way to get your team back on track and performing at their best.
Read on to find out:
- What business process reengineering is
- Why (and when) you should bother with BPR
- How to use BPR (with detailed instructions)
- How famous brands have used BPR to radically improve their processes
Still with me? Great. Just for that, how about a full template which you can use to perform BPR (if you’re already familiar with the topic, that is)?
Let’s dive in.
What is business process reengineering?
Like most buzzwords, business process reengineering (BPR) is a dull way to describe an interesting topic. Put simply, it’s the act of rethinking the way you do the important things in your business. It’s when you say “this is so inefficient it’s killing us”, and sit down to strategize how you can improve your processes in a radical and fundamental way.
In this article, I’m going to run through some case studies and explain how Taco Bell, Ford, and Google have reengineered their business processes to create change for the better in their businesses and save them from death by inefficient process. And so can you.
You need to cut out the work that doesn’t add value, but where do you even start when cutting down on the number of processes you execute in your business? Let’s look a little deeper into the aims of BPR.
Why (and when) should you bother with BPR?
Your company is never too small to consider business process reengineering. At its heart, BPR is something enterprises do. When an uptick of just 2% efficiency could mean a few million in extra profit next year, you better give that thing a title and formalize it as a field of study!
With startups, however, it’s not so drastic. It might even be funny to call it BPR when it’s probably just a few people sitting in the same room agreeing to change the way they do things because they’re all sick of the extra work.
No matter what the company size, though, it’s never too early to start doubting the efficiency of the way you do things. Bad processes create problems that wear people down, and in small businesses you don’t have employees you can afford to be worn down — you don’t have the numbers.
In short, start now. Examine the way you do what you do, and start cutting out the work that doesn’t add value.
Start with a process if:
- the process is important
- the process is fundamentally broken
- the process can be feasibly changed
In fact, now is a perfect time to jump into exactly how to carry out a business process reengineering project.
How to use business process reengineering
You know why it’s important, and you know that something in your organization isn’t working. You may have tried improving your current processes but something isn’t quite right – information could be missing, shortcuts might be being taken or a tool adopted without the process being updated.
In any case, an update isn’t going to cut it. You need to start from the ground-up.
You need business process reengineering.
So, let’s dive into how to do just that. Here I’ll guide you through the stages of business process reengineering, including:
- Identify the process that needs reengineering
- Assign the task to key team members
- Read current process documents and identify KPIs
- Create a current process map
- Draft a new process map and SOP
- Test and deploy the process
Let’s get started.
Identify the process that needs reengineering
You don’t need me to tell you that it’s important to create a process for everything you do more than once. Unfortunately, while vital, this can leave you with a mass of processes that are difficult to prise apart and inspect as individual items.
That’s why you first need to identify the process which you’re going to re-engineer. As mentioned above, this should ideally be one which is important, fundamentally broken, and can feasibly be changed.
This won’t always be possible. Thankfully, these aren’t rules – they’re recommendations.
One way to start analyzing your processes for candidates is to check for the areas where the most waste is being generated. This usually means employing techniques like value stream mapping or business process mapping, as they inherently display which processes (or sections of your company) are the most inefficient.
If you haven’t already analyzed for waste and inefficiency in your processes, don’t worry!
Instead, make a list of the various processes your business carries out and order them by importance, value, and the frequency with which they’re performed. Then work your way down the list until you find a process which you know to be outdated or performing badly.
Assign the task to key team members
Once you’ve selected the process to reengineer you need to assign the task of doing so to key team members. These should be people who are experienced with the process and understand the importance of it.
You don’t have to be a manager to reengineer a process – you just need to understand and be familiar with how the process is currently being carried out in its entirety.
To assist the main team member(s) you’ll also need to assign any managers who have the authority to review, approve, and/or reject any changes that are made.
Read current process documents and identify KPIs
Now we’re getting into the meat of the issue. Once the team is assigned they need to read through your process documentation and make sure they understand what it was meant to achieve, and how each step contributed to this.
The process won’t be perfect (no process truly is) but that’s what we’ll solve shortly. The most important thing for now is to make sure that you’re looking at the most recent documentation. After all, there’s no point in reengineering a process if it’s already been improved upon.
This is also the stage where you should be either searching for records of the relevant KPIs for your process or (if it hasn’t been tracked or analyzed before) figuring out which metrics to use and benchmarking your current process to compare to the one you’ll shortly create.
Create a current process map
Next you need to put your resources together and create a map for the process you’re looking at. We’ve covered this in detail in our process mapping post but I’ll go over the basics here too.
To create a process map you need to meet with the team that regularly performs the process and get them to run through the span of the process with you. Use your existing process documents as a base and get input from the team to see where natural deviations from the process have occurred.
Once you’ve got an accurate idea of how the current process is performed, you can then map out the flow using a whiteboard, piece of paper, or a dedicated piece of process mapping software. You don’t have to use any fancy business apps but they will, generally, save you a lot of time here. Use symbols to denote different kinds of tasks and steps in the process.
This process map should further demonstrate which sections of the process are failing and thus need to be focused on when reengineering the process from scratch.
Draft a new process map and SOP
It’s finally time to draft the new process and SOP template. Here’s where your creativity needs to come into play.
Start by thinking about precisely what the old process was designed to do or achieve and where it went wrong. Ask yourself questions to figure out how the new process needs to fundamentally differ in order to improve on the KPI results of the old process. Questions such as:
- Why was the old process inefficient?
- Did the team take shortcuts? If so, why?
- How can we make sure that no shortcuts are needed for the new process?
- How can we simplify the process without sacrificing results?
- How can we make sure that everyone understands why the change was important?
This last point is often the most difficult, as you can’t just tell the team who’ll be using the process that “we’re doing this now because it’s better”. They need to truly understand and appreciate why the old process wasn’t cutting it and what the changes they need to make will achieve.
Thankfully, you’ve already primed them by talking to them earlier when making your current process map. Including them there helps to give a sense of ownership over the process, and getting them to lay out their shortcuts is a great way to show how the old system was flawed at the same time.
Of course, if you’ve already got a solid change management model in place, you shouldn’t need to worry too much about your team adopting the process correctly.
So, once you’ve created your new process map (created from your own knowledge and their previous feedback) you should once again bring in the people who’ll be using the process and go through it with them. Give them a chance to tear it apart and give feedback.
You don’t have to do everything they suggest. The important thing here is to make sure that they know their voices are being heard and to make them comfortable with why every step in the new process is vital, thus helping to avoid shortcuts being taken in the future.
Only after all of the feedback has been considered and applied should you make a new process document for your team to follow, taking care to make clear what the changes are and how to carry them out.
After all, you can’t expect someone to perform a task differently if you don’t tell them how to do it.
You could use this template below as a base from which to build your standard operating procedures:
Test and deploy the process
Now all that’s left to do is to test your new process before deploying it. While fairly self-explanatory, there are a few common trip-up points that can make all your efforts next to useless, so it truly does pay to be careful here.
The main thing to worry about is testing the process in as close to a live environment as possible. You need to be able to use the KPIs you identified towards the beginning of the business reengineering process to measure the relative success of your changes, without compromising your existing processes.
In other words, look before you leap.
Even isolating and testing single segments of your process at a time is preferable to completely overwriting your existing setup before you know for sure that the changes will lead to a better result. Not to mention that your tests should get your team more familiar with the new process before it’s fully in action, and the results of your tests will help to show them why the changes are for the better.
If your KPIs drop compared to your old process during the tests, it’s time to go back to the drawing board with your team. Otherwise, it’s time to deploy the new process!
There’s not too much to say here, other than that you need to check that everyone has access to the new process, knows exactly what they need to be doing, has access to any resources they might need, and is trained with any techniques or technology new to the process.
Famous BPR Examples (And How They Did or Didn’t Work)
Now that you know how to carry out business process reengineering, let’s take a look at three famous examples of it in action and the effect that it had on:
- Taco Bell
Google redesigned its hiring process in the early days after a study revealed it was — to put it bluntly — utter garbage. In a 2013 interview with The New York Times, Laszlo Bock (SVP of people operations), said:
“We looked at tens of thousands of interviews, and everyone who had done the interviews and what they scored the candidate, and how that person ultimately performed in their job. We found zero relationship. It’s a complete random mess”
What do you do when something like this happens? For a tech company like Google, the obvious choice is: turn to data.
After finding the famous “how many golf balls can you fit in Seattle’s sewer network?”-type questions to be nothing more than a way to make interviewers feel clever and superior, they moved away from random questioning and towards a structured, process-driven approach involving behavioral interviewing with fixed questions like “give me an example of a time when you solved an analytically difficult problem”.
By reengineering the hiring process, Google has become known as one of the most effective companies in the world at judging the right people to hire. It’s synonymous with finding great talent, not asking useless fluff questions.
In 1983, Taco Bell was teetering on the verge of outright failure. As a $500m Mexican regional chain, it returned -16% annually before making a huge change to the way it did business.
Instead of preparing everything on-site from fresh, it implemented the sci-fi sounding K-Minus Program. What that actually meant, was that Taco Bell removed the kitchen from their restaurants. Hammer and Champy’s book on BPR details the process:
“In the new process, meat, beans, corn shells, lettuce, tomatoes and cheese for their products are prepared outside of the restaurant in central commissaries. At the Taco Bell restaurants, the food ingredients are prepared when ordered for customer consumption.”
What happened as a result of this change?
Well, that was back in the early ’80s when Taco Bell was an ailing chain confined to Mexico. Now, it’s doing $1.98b in annual revenue and serves 2 billion customers annually from 6,407 restaurants worldwide, according to Wikipedia.
Michael Hammer, co-author of Reengineering the Corporation, suggested to Ford a radical way to cut down on wasteful work: destroy all invoices.
“In the new situation the buyer registers an order in an online database. The buyer no longer sends a copy of the purchasing order form to the creditor administration. When the goods arrive at the store, the storekeeper checks in the database whether the received goods correspond to the purchasing order form (nb: previously the employee did not receive a copy of the purchasing order form). If these correspond, the storekeeper accepts the goods and registers the reception of the goods in the computer system. If the storekeeper cannot find data of the supply in the database, goods are simply sent back.”
The results of moving from paper invoicing to storing data in a central system were pretty staggering: a 75% decrease in accounts payable staff. These 75% were early victims of computers destroying jobs, but also representative of the salary money that can be saved with drastic BPR.
BPR best practices from the expert
American engineer, author, and computer science professor Michael Hammer pioneered business process reengineering in the 1990s with his HBR article Reengineering Work: Don’t Automate, Obliterate. The article was a rallying cry for businesses who were finding little help from traditional process rationalization and automation. The general message? You’re not going to get anywhere with small changes. Rip it up and start again.
His changes in just two example companies rendered the work of hundreds of customer-facing employees useless and made dramatic changes in the efficiency of the business.
If anyone’s the father of BPR, it’s Hammer. A few years later, however, it was formalized by another American academic — Tom Davenport. Davenport laid the groundwork for a proper process which companies can follow to reengineer their business processes:
- When identifying the process to be reengineered, pick the most important processes, or those that cause most conflict with business objectives. It’s less common for businesses to catalog all of their processes and reengineer every one.
- Before you start, understand and measure the existing processes using a method like business process mapping. This way, you won’t repeat your mistakes when drawing up a new process.
- Always think in terms of technology. As we’ve seen, Ford saved a ton of money by using a computer database instead of paper invoices.
- See the new process as a prototype, not a final copy. Adhere to agile methodology to get a draft out and iterate on it.
Perfect processes don’t exist
Business process reengineering might not be a fool-proof way to improve your processes to the point where you never have to touch them again. However, nothing truly is.
There will always be new and better techniques and tools to try, and ways to improve your processes no matter how much you iterate. Yet after a couple of rounds of changes it’s easy to get lost in the additions and alterations.
Just because a process is functional doesn’t mean it’s not a possible candidate for reengineering. If your major waste points have been fixed and you’re looking for your next project, try tackling a process which your team finds confusing and see if there’s a way to simplify the whole thing while getting the same (or better) results!
Have any BPR tips of your own? I’d love to hear them in the comments below.