Process improvement is a simple idea that is the difference between a company with no opportunity for improvement, and one that continually gets better. The idea is that the company's habits should be taken out and examined every so often to see how they can be improved. Process improvement is the main way of implementing a reasoned approach to business, as discussed in the reason document.
A process is a way that a group of people within the company work together to do a task. In any company, there are hundreds of informal processes of which no one is really aware. A process can be as simple as who next makes the coffee at the company coffee machine, or as complex as how a new product is made.
What is a Process?
Processes are a company's habits, the mechanisms that have built up over time for solving various problems. The existence of processes is why a single person's leaving a company is so disastrous: that person was a participant in many processes, which now have a person-sized hole. Although some may think a person useless, it isn't unusual for such "useless" people to have many unofficial roles, that will have to be done by someone else in his/her absence.
In a way, processes are like little computer programs. They are done in a step-by-step fashion. They have exact rules that can be written down. The difference is that processes are programs for a set of people rather than for a computer.
Processes can often differ from stated company policy. Whenever things don't seem to happen as they should, and someone has to hand carry a transaction through multiple stages to expedite it, dysfunctional processes are probably at fault. Those stages should happen automatically without the need for an babysitter.
For instance, it may be that an invoice arrives each month with payment due a month later. The "process" that may have evolved is for the submitter to phone in the invoice total to an expediter, while simultaneously sending the written invoice elsewhere. The expediter then checks with various parties to prevent holdups would otherwise come back through slow memo/authorization communication channels, culminating in a call to the final check writer to supply additional information lost along the way. If one relied soley on the "official" process, progress could stall in dozens of ways.
The reason official processes don't work is usually that they don't factor in real life. They are created by a person who hasn't consulted all the parties involved, or is in a different department than some of the people who will execute the process, and the resulting process just doesn't address reality.
Why Are Processes So Hard to Get Right?
On the other hand, ad hoc (unofficial) processes do work, but they can be very inefficient, because they arise from local improvements instead of global ones. That is, they evolve rather than being designed. Each person who takes part tries to do what s/he can to improve the process, but quickly hits a limit when the process crosses into someone else's bailiwick. So ad hoc processes end up with lots of workarounds for getting things done without the help of necessary parties.
The step missing from most processes, that would make all the difference, is the step of self improvement. The only rule one need know, from which the entire process-improvement strategy can be derived, is that when a process doesn't work, it ought to be fixed. If would could just add to the end of every informal process in the company the extra step "figure out what could be improved about this process and fix it", every company would be perfectly organized.
Improving a Process
The first step is to make everyone aware that these processes are going on, invisible but all-powerful. As soon as workers start thinking in process terms, it becomes apparent exactly why things are going wrong. It's not really those bozos in department X causing the trouble, it's the way the system is set up. Instead of the official 2-step process that doesn't work, an elaborate 20-step one has evolved that does work but is very inefficient.
The next step is to write down precisely what's really going on: the real process, not the "official" one. You'll be amazed at how precisely an informal process can be written out, and at the same time how convoluted it has become, while remaining completely underground. This happens because as soon as the informal process works at all people stop changing it, so it never becomes optimized.
Now the process can be improved. The various people involved can be consulted, to figure out why the 2-step official process didn't work and the 20-step informal one does. Then a 5-step process that works can be designed, everyone involved can be educated about it, and the problem is solved.
For this to work, the person tasked with optimizing the process must be able to effect changes in everyone involved in the process. No single person who's part of the process has this authority, which is why all those workarounds got into it in the first place. To straighten things out, the optimizer must be able to design a big picture procedure that each party involved agrees to follow.
Once process improvement becomes a company habit, it'll be used for both large things and small. Small processes can be improved just as large ones can, in fact much more quickly because fewer people are involved, and the process is easier to understand; all it takes is agreement on a fix and the process is changed. Just like that.
For example, there's the coffee story. A coffee shop had good coffee, among the best when it was good, but sometimes something went wrong, especially when things were busy: the worst time for bad coffee! The owner wanted to improve coffee consistency so he tracked down the problem.
He found that when things got busy, the pot would run out and whoever was there would start the next pot. The new pot would begin brewing, but would only be partially done when the next server needed some. That server would pour a cup out of the partially-brewed pot, and set it back to finish brewing.
The problem was that the first cup out of a partially brewed pot is too strong, and leaves the rest of the pot too weak. When the whole pot has time to brew, these combine to make a perfect pot of coffee. But when some is taken before it's done, the first customers get too-strong coffee, and the rest get too-weak.
The owner thought for a while and then drew a line on the coffee pot. Then he called over the staff and instituted the rule that whenever the level dropped below that line, that person would start the next pot of coffee so that it'd be ready by the time the first pot ran out. Even if things were busy, especially if things were busy, the server must drop everything to make that next pot of coffee when the level dropped below the line.
From then on the coffee at his shop was consistently great.
This simple example shows how even the most simple processes can be analyzed and improved, to huge benefit. It also shows that processes are often the culprit, not people. The servers at the coffee shop were trying to do well, but there was nothing they could do. The solution had to be imposed by someone with the necessary authority, with a little thought and the imposition of simple rule.
And perhaps most importantly, the coffee-shop example illustrates that process improvement often results in increased quality with equal or less effort on the part of the workers. In this case, starting the new pot brewing when the line was reached was no extra effort for the workers, and yet produced an immensely better result. Usually this is how good process improvement works; it takes no more time from the bulk of the people involved, but either increases quality or saves a few people huge amounts of time. It really gives something for nothing.
In addition to streamlining the company, process improvement has an added benefit. It free middle managers from a constant stream of busywork. Much of what they do at an unorganized company is to "fight fires". This means that they must step in and apply temporary fixes to problems. By improving the processes that result in the problems, a company can permanently fix the problems. It's hard for some companies to imagine, but by taking enough time to fix every problem permanently, in a short time the middle managers will be able to go back to their real jobs instead of fire fighting.
A common question is how formal should processes be. The answer is that some should be formal (i.e. written down) and some should not. There are two reasons to formalize a process. The first is when new people will be executing part of the process regularly. Rather than have an old hand lay out the procedure verbally to newcomers, a written process can be used to save time.
The other reason to write a process down is when it is complicated and is expected to be revisited again (as all complicated processes should). It is very helpful to have the process be explicit, with rationales for each of its steps. Just as with any sort of design, rationale paragraphs can be invaluable to those modifying the design later.
The nice thing about process improvement is that it saves time when compared to the "fire fighting" management technique. By applying a little more effort to potentially recurring problems by engineering fixes that permanently prevent that problem from occuring again, rather than just quickly applying a temporary fix, one has saved time in the long run, usually even in the medium run. So a byword of process improvement is "fix it once, permanently, rather than once each time it happens".
| || |
March 2, 1996: created.
August 10, 1996: tightened.
Copyright © 1996,
All Rights Reserved