Mark’s post on The Whiteboard tells a pretty common story. The good news is that this company has more business than they can handle. Pretty good results in these times. The bad news is that they are having problems ramping up production to meet the demand. In Mark’s words:
I’m working for a company that is very, very busy. They developed a new process that is the first of it’s kind and have taken the market share away from their competition. But they have not spent enough time making the process robust enough to handle the increase demand and the scrap costs are going out of the roof. Currently about 65K a day. Any suggestions? Our number 1 scrap producer is a machine that can not perform at the same capability as when Engineering did their run off…
At the risk of coming across as flip, the very first thing to do if a machine starts producing scrap material is to shut it down. It is better to make nothing because that is a cheaper alternative than making stuff you can’t use.
However, it goes deeper than that.
Engineering had done a “run off” (which I presume was a test on theoretical speeds). Now actual performance isn’t meeting expectation. This is a problem.
But let’s rewind a bit and talk about how to manage a production ramp-up. Hopefully it is a problem more people will be having as the economy begins to recover.
Although this is in the context of the machine, exactly the same principles apply to any type of production. Only the context and the constraint changes.
Presumably there was some speed for this machine where it didn’t produce scrap, or the scrap was minimal. Going back to that time, here is what should have happened.
Promise production at the rate the machine is known to support.
Now crank up the speed a bit and see what happens. In the best case, you are overproducing a bit, but you are learning what the machine is actually capable of doing.
Crank it up a little more. Oops, scrap.
STOP!
Because you have been running a little faster than required, you have bought a little time. Understand why that scrap happened. Try to replicate it. Dig into the problem solving. Try to replicate the problem under controlled conditions. LEARN.
Hopefully you can find the cause and fix it.
Try it. Run the machine again, at the faster speed. Scrap? Back around to the “problem solving” cycle. Repeat until you can reliably run at the faster speed without scrap.
Then, and only then, promise the higher rate, because now you can reliably deliver it.
Then notch it up a bit until you encounter the next problem.
This cycle of promising only what you can actually deliver protects the customer while you are pushing the envelop internally to discover the next problem.
The alternative? Make a promise knowing you actually have no clue whether or not you can meet it.
But that’s what they did. So now they are burning a lot of money every day making scrap material.
The same principles apply, however. They are already not delivering what they promised. So throttle things back to the point where they can predict the results, and go from there. Pretending they can run faster than they can is not accomplishing anything other than burning money. Deal with facts, no matter how uncomfortable.
If you make a schedule based on what you wish you could do, you will have a schedule you wish you could meet.
No matter what, each time scrap is produced, the fact must be acknowledged. That allows the immediate response that is framed around a simple question:
“How the hell did this happen?”
Put another way, “What have we just learned about the limits of this process?”
It is only within that framework that you actually get any better. Anything else is relying on luck, and in this case at least, that didn’t work.