The Day the CPK Report Came Out, the Room Fell Silent for Three Seconds
I remember several years ago, the yield of a machine in our plant was consistently stuck; no matter how much we adjusted it, it wouldn't improve. At that time, the production line complained daily, PMs hounded for progress updates, and the pressure was immense. Finally, a project team was assembled, and everyone was confident they could fix it using DMAIC. The result? After two months, the CPK decreased from 1.08 to 1.05, and DPMO even slightly increased, from 6210 to 6300. On the day the report was presented, the conference room truly fell silent for three seconds; the air was so thick I could hear my own heartbeat. What went wrong? DMAIC is clearly a good tool, so why do many projects end up like headless chickens, unable to conclude?
Where Did the Problem Lie?
In essence, many times we run DMAIC as a "process" rather than treating it as a "problem-solving mindset." You Define the objective, Measure the data, Analyze the causes, Improve the countermeasures, and finally Control the results – sounds reasonable, right? But in reality, these five steps are interconnected; if one step isn't clearly understood, it's easy to go astray later on. The most common issue is that people Define an "objective" but fail to clearly Define the "problem."
So the key is: you must be very clear about what "specific" problem you are trying to solve.
How to Do It in Practice?
To clarify the "problem," I usually draw a fishbone diagram, but not haphazardly; instead, I focus on the "result." For example, if your yield is low, don't just write "low yield"; that's too vague. You should write: "The yield of a certain process has been 5% below the target value on average for the past three months, with defects on the wafer edge accounting for 70% of total defects." This is specific enough.
Next, in the Measure phase, you need to quantify these "problems." For instance, in the case mentioned earlier, everyone only knew "the yield was bad," but they didn't truly quantify the distribution, location, and types of defects. We later re-measured and found that although the total number of defects hadn't changed, what was originally thought to be "random defects" actually had as many as 85% concentrated in specific quadrants of the wafer.
In other words: you must use data to clearly delineate the problem, and this data must be able to point to the "root cause" of the problem.
The Most Common Pitfalls
Frankly, the biggest pitfall I've encountered is not spending enough time in the Define phase, or being led by the boss's "objective." The boss says: "Increase the yield to 99%!" and you Define that you need to "improve yield to 99%." The result? You diligently Measure and Analyze, discovering a host of possible causes, but because the objective is too broad, you don't know where to start.
Another common pitfall is in the Analyze phase, where everyone habitually analyzes every conceivable variable. The outcome is an overwhelmingly large volume of data, with many non-significant p-values in the results, leading you to question everything. In essence, this is because you haven't narrowed down the scope of analysis based on the "problem" data from the Measure phase.
Therefore, the key is: in the Define phase, spend time "digging deep" into the problem; in the Measure phase, use data for "positioning"; and in the Analyze phase, "focus" on truly relevant variables.
One Thing You Can Do Today
For your next project, spend an extra 30 minutes in the Define phase to describe the problem more specifically!