Here is a situation encountered on a recent project. I have abstracted the key-points here.
The project started as a textbook DMAIC engagement with all the elements you would expect to find including impact on customer, strategic problem, clearly measurable benefits and well-defined goals.
The project was too tackle rework created at a certain process step producing a 5% defect rate. Although the defect rate was known, the number being fixed was not. Rapidly cracked-open the rework process and came up with a fix rate of 50%. So simple goals:
- Reduce the defect rate from 5% to X%
- Improve the rework from 50% to Y%
Attention moved onto the root-causes for the defects and as the analysis continued it became clear that the customer was unintentionally creating the defects and there were many many reasons why the customer could create the defect.
As an analogue it’s a bit like treating people with back pain. In a week any number of people can suffer and there could be any number of root-causes. It’s the treatment of the symptoms that becomes important with any number of root-causes to address.
So the project came a crunch point, what to do.
- Could launch a DfSS project and rebuild the process from the ground-up with the goal of avoiding the defect situation in the first place. Not likely, way too big a project.
- Could relentlessly quantify and address each and every root-cause. Decided against this, as I like getting rapid results. It would cost a lot of time & money and most factors are out of my control anyway. (Although am pushing forward a few highly targeted improvements here.)
I decided to focus on the rework process. It consists of three main steps and at each point the defect can be corrected. I am setting-up a DOE trial that will change these and other factors to find the optimum setting for fixing defects. Hence I am treating the symptoms not the cause. It feels wrong, but it happens!