Leadership

10 things to keep in mind when improving processes

Handled the right way, business process improvement can provide tremendous benefits to your organization. Here are 10 keys to success.

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.

About

Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive w...

3 comments
waltersokyrko
waltersokyrko

Point 9 (automation) can be stated even more strongly. One should optimize the manual process as much as possible before automating anything.

Deadly Ernest
Deadly Ernest

Way back in the early 1970s I did a training course on Methods Management in System Administration - now please keep in mind at that time this was NOTHING to do with computers; it was all about the management of paperwork and manual processing system in administration and production environments. It also covered a lot of stuff about how to manage the Methods you used to Administer things and improve them as well as managing change. Every major point in your article was covered in depth in that course except point 9 as automation was a minor issue then that only affected certain types of factory production. During the early 1990s I did a management course that included modules on Change Management and they included all but point 9 again. It seems this is one of those subjects that needs to come up again about every 20 years so people in management can be made aware of it any more for some reason. What you say is all good, and totally ignored by many in top and middle management, as they seem to get Emperor syndrome when they get high enough to have a layer of other manager below them. Emperor Syndrome is where they feel everything can be done by their royal decree.

DOSlover
DOSlover

A very useful, practical article that goes beyond simply IT. I would flesh out point two to include objectives. Sometimes vested interests look for a detail to relieve them of burden or responsibility that is detrimental to the objective. Having a very clear, preferrably concise, objective will cut these hidden/self interest agendas short very quickly if they detract from the core objective. This is the voice of sometimes bitter experience.