Many organizations want to harness the power of IT to improve existing processes or to solve vexing business problems. In this article, I will outline 10 items you should consider as you undertake business process improvement (BPI) projects in your own company.
1: Start at the top with executive support and good governance
Although organizations might begin a BPI initiative with the intent to correct a single issue, these initiatives can quickly take on a life of their own. Further, because change can be difficult for some, it is in the organization's best interests to ensure that BPI projects be chartered and blessed by its senior leadership. With this kind of visibility, there may still be angst, but the improvement group will have the authority it needs to make changes to the business.
2: Identify the problem(s)
When beginning a BPI project, don't just attack something that looks wrong. Carefully analyze the organization's current pain points — perhaps sales are down, customer satisfaction with support is poor, or costs to handle a certain function have skyrocketed — and then determine which problems deserve the most immediate attention.
3: Don't forget how processes interact — think global while acting local
While many processes stand alone, the chances are good that every process is a part of a bigger whole. As your team begins to consider the process at hand, don't lose sight of how that process integrates with everything else. Plan for it. Make sure that you're not making something else worse in an effort to solve a different problem. This may mean attacking multiple processes at once in some cases. As you plan for improvements, step back and from a high level, try to determine what will happen once proposed changes are made.
4: Look for immediate time savings
In one BPI project I led, in our very first meeting, we did a quick, high-level process mapping to ensure that we have all of the process stakeholders in the room. During that meeting, we discovered that one of the process owners was spending about two days per month creating reports for the next process owner in the chain and had been doing so for years. The catch? The reports were never used. The person received them and simply discarded them. Without a second thought, we nixed that step of the process before we made any other changes. So there was an immediate, tangible benefit resulting from the time we spent simply talking about the process.
This brings up a related point: You might not have to be too formal in your efforts. Sometimes, just a bit of communication can yield huge time savings.
5: Make sure the right people are involved
This is a step that I can't stress enough: Make sure you include everyone who has a stake in the process. If you don't, your efforts will fail. Those excluded will know they've been excluded and will resist any proposed changes. Further, your efforts won't be as complete as they otherwise could be.
Again, another related point: Just because someone is involved doesn't mean that that person will cooperate. I've been involved in BPI efforts with people who were less than cooperative, and it really affects the possible outcomes. In every organization, I believe that people have a responsibility for improving the workplace, which should be included in annual performance reviews. If someone is truly combative just to resist the change, it should be reflected there. That said, if people have valid points and you simply don't agree, don't punish them! The goal here is inclusiveness, not divisiveness.
6: Formally map processes under review
This is another step I consider essential. A visual representation of a process helps everyone understand exactly how the process operates, who operates it at particular points along the line, and where that process intersects with other processes and services.
Visio has great templates for process mapping, but there are also excellent stand-alone tools designed for just this purpose, which may be better for particularly complex or involved processes.
With the process map, it becomes easier to make decisions with everyone on the same page.
7: Spend time on what-if scenarios
Don't just come up with a new process and lock it in. Consider every what-if scenario you can think of to try to break the process. Just like software testing, the goal here is to identify weaknesses so that you can shore things up. The more time you spend testing processes, the better the outcome will be.
8: Figure out your measuring stick
If you can't measure it, you can't fix it. You must identify the metrics by which you will gauge BPI project success. The "pain" metric was probably determined when you figured out which processes to attack first, but the success metric should also be targeted. For example, are you trying to reduce customer on-hold time for support to two minutes or less? Whatever your metric is, define it and measure success against it.
9: Don't assume automation
When people hear "business process improvement," they often just assume that is code for "IT is going to automate the process." That's certainly not always the case, although IT systems will often play a large role in these efforts. It's just as likely that non-IT-focused efforts will play as big a role as — or a bigger role than — IT-based systems.
I include this step so that you don't limit yourself. Think outside the system!
10: Look for common chokepoints between disparate processes
As processes intersect, look for places where many processes tend to break down. This is related to "thinking global" and requires people who can look at the organization from a very high level while at the same time, deep-dive into its guts to see how it ticks.
Posts
