The Day the CPK Report Came Out, Silence Fell for Three Seconds
I still remember years ago, a new product was introduced to our production line, and everyone said it would be a huge hit. What happened? Production had barely begun when the yield dropped drastically. During the meeting, the supervisor, with a grim expression, stared at the CPK report, which conspicuously showed 1.08. Do you know what CPK 1.08 means? Simply put, if you produce one million wafers, approximately 6210 will be scrapped! I'll never forget those three seconds of silence; it was more terrifying than a midnight power outage. Afterward, the supervisor pointed directly at me: "XX, you're from the IE department, figure something out!" Damn, my inner monologue was: IE isn't a panacea! But I still had to say: "Yes, I'll handle it."
Where's the Problem?
Many times, when we see poor yield or production bottlenecks, our first reaction is to "quickly fix the machine" or "try changing a parameter." This is essentially like your car not starting, but you just keep turning the key. Frankly, this isn't problem-solving; it's just trying your luck. The truth is, you need a systematic method to find the real root cause. This method is precisely the core spirit of the IE Toolbox: tracing from phenomena back to fundamental causes, then implementing targeted improvements. Many engineers only look at results but don't analyze the process. This is why IE is so crucial.
How Is It Actually Done?
How do you climb out of a dire situation like CPK 1.08, step by step? I usually do it this way:
- Define: First, you need to clearly articulate what the "problem" actually is. Is it low yield? Insufficient capacity? Or excessively high costs? In the example above, it's a CPK of 1.08, resulting in a DPMO of 6210. The more specific the numbers, the better; never just say "the yield is a bit poor."
- Measure: Next, you need to collect data. This step is where people most often stumble; many newcomers spend half a day pulling machine logs without knowing what to look for. I recommend drawing a process flow diagram and then measuring time, quantity, and defect rates at each critical station. For instance, we can identify which process step has the highest defect rate. Is it etching? Or thin film? Or is a particular machine experiencing unusually long downtime?
- Analyze: Once you have the data, don't just let it sit there. You can use an Ishikawa Diagram (Fishbone Diagram) or the 5 Whys method to systematically identify potential causes. For example, if you find that Machine A has particularly long downtime, you need to ask: Why is the downtime long? Is it frequent breakdowns? Why frequent breakdowns? Is it a software issue? Or aging hardware? Keep asking "why" step by step until you find the root cause that "you believe can be changed."
- Improve: After identifying the cause, you can design improvement solutions. At this stage, don't just brainstorm; base your solutions on data and analysis results. For example, if it's a software issue, ask the programmer to optimize it; if it's aging hardware, consider repair or replacement. Remember, improvement solutions must have "measurable objectives."
- Control: Finally, after implementing improvements, you must continuously monitor to ensure the problem does not recur. This is like needing rehabilitation after surgery. You can set up a periodic report or establish an automated monitoring system.
The key takeaway is that these five steps are interconnected and indispensable.
The Most Common Pitfalls
Honestly, the IE Toolbox sounds great, but in practice, the most common issues encountered are "incomplete data" and "resistance to change." Once, I asked a newcomer to pull data from a specific machine, and he only retrieved data from the previous day. I asked him: "What about data from the past month or even the past year?" He looked bewildered. Without sufficient historical data, you simply cannot determine whether the current situation is "normal" or "abnormal." Another pitfall is that when you propose improvement solutions, you often encounter resistance like "that's how we've always done it." In these situations, data is your most powerful weapon.
One Thing You Can Do Today
Identify the most pressing problem you currently face, and define it using "numbers."