I haven’t written much about error proofing in my several years of blogging about lean manufacturing. When I teach, I don’t go into error proofing much. The primary reason is that error proofing is (to my way of thinking, at any rate) very specific to a particular task, activity, or process. When I’ve looked at literature about error proofing, specific examples relevant to specific equipment or tasks are given. I always find myself thinking, “That’s great…if one has that type of equipment or is carrying out that particular task.”
Another thing is that there’s error proofing and there’s error warning. And each requires it’s own explanation and set of examples. An example of error proofing is that my car can’t be put into “D” unless I’m pressing on the brake. Error warning is that “Service Engine” light that I’ve ignored for a couple of years now and the little bell that rings when I don’t fasten my seat belt (that one I don’t ignore). All that is straightforward enough but…when does one employee error-proofing and when does one employ error-warning?
Finally, error proofing isn’t easy. It often takes some fancy engineering or at least some know-how and a bit of time to design and install many error proofing mechanisms. One can have a plant organizing it’s work place within an hour but error proofing takes planning, a bit of creativity, and probably a bit of finances to (That transmission-brake linkage in my car didn’t design itself, ya know.)
And yet…
I read an article in my local paper today about a 94,000 gallon jet fuel spill recently committed by the Navy. It’s caused a lot of problems in the area including home evacuations, wild life kills, and worries among local residents about contaminated air and water. It was, and remains, a big deal.
Here’s an excerpt from an article I found online about the spill:
While the official cause is still under investigation, initial indicators point to a mishap during a tank refueling that occurred on Wednesday, May 10. Officials say a fuel switch was in the wrong position, which caused fuel to flow into a small 2,000-gallon tank instead of into one of three larger 880,000-gallon tanks. Once the capacity of the smaller tank was reached, the fuel overflowed for several hours. The Navy is still investigating how the switch was in the incorrect position.
Now, preventing this wouldn’t have required sending everyone to a class on error proofing…nor would it have required hiring an “error proofing expert” to give advice. All it requires is that someone insist that the process be mapped and that every possibility for error be brainstormed and resolved. And then it requires that someone actually implement those error proofs, preventions, or warnings. I’m guessing that anyone reading this could come up with a few possible preventions or warnings, even knowing as little as we do about the situation:
- A sensor that cut off the flow of fuel when it reached a certain level in the smaller tank.
- A sensor that sounded a warning when the fuel reached a certain level in the smaller tank,
- A timer that cut off the fuel after a few minutes,
- A timer that sounded an alarm after a few minutes when turned to the smaller tank,
- A visual above the switch that said, “If you turn the switch to this tank, don’t go anywhere, dammit! You’ve got to turn if off in about 15 minutes!”
Some of these ideas are better than others. Some of these ideas are more easily implemented that others. But all of these ideas are better than nothing, which the evidence seems to indicate was what they had.
Error proofing, like most lean tools, is pretty straightforward. You just gotta do it.
- Brainstorm a list of important processes.
- Map the process.
- Go back and brainstorm anything that can go wrong, i.e., variances, at each step of the process, e.g., “We might turn the switch to the wrong tank and leave it switched overnight. That would be really bad.”
- Prioritize those variances.
- Brainstorm ways to prevent or, at least, provide warnings of variances.
- Pick the best solutions.
- Implement them.
That’s it.