InsightFab
Knowledge Base/DOE Failure Case Analysis: 5 Situations of Improper Execution
DOE6 min read

DOE Failure Case Analysis: 5 Situations of Improper Execution

Drawing from fifteen years of manufacturing experience, this article dissects common DOE failures, emphasizing that the root cause often lies in improper execution rather than flawed experimental design. It illustrates why even a well-conceived DOE can yield dismal results due to uncontrolled variables during its implementation, offering crucial insights to prevent costly reworks.

The day the CPK report was released, silence fell for three seconds, so profound you could almost hear a crow fly by

I still remember a few months ago, a new process had just completed its first batch of experiments, and everyone was waiting for the results. Xiao Chen, the rookie engineer, nervously projected the CPK report. On the screen, the CPK values for several key parameters were abysmal, some even as low as 1.08, translating to a DPMO of 6210. The entire conference room instantly fell silent, so quiet you could almost hear a crow "caw-caw" flying past. The boss's face was paler than the walls of the cleanroom. This DOE was utterly useless, a waste of numerous wafers and time! To be honest, I've seen this situation far too many times in my fifteen years; often, it's not that your DOE design is poor, but that "execution" has gone wrong.

Where's the Problem? DOE Failure Is Not the Experimental Design's Fault

Many people, upon seeing a DOE failure, instinctively blame it on an insufficiently complex experimental design, incorrect factor selection, or overlooked interaction terms. However, frankly speaking, for a mature process like ours, DOE design structures typically follow a common template and are unlikely to be grossly erroneous. The real problem often arises when a "good" design is "mishandled" during actual execution. In essence, you think you're building a house according to blueprints, but what you end up with is an illegal structure. The essence of DOE is "controlling variables," but when the experiment's execution itself is filled with "uncontrolled" variables, the results are naturally unreliable.

What to Actually Do? Please Stop Letting "Noise" Destroy Your Efforts

When I helped Xiao Chen review that disastrous case, I uncovered several fatal flaws in the execution.

  1. Inconsistent Equipment Status: To meet the deadline, he used two different machines for the experiment. One machine had an older chamber condition, while the other was newer, which directly introduced the huge "machine variation" noise.
  2. Varying Operator Techniques: Three shifts of operators were involved during the experiment, each with different loading/unloading speeds and parameter fine-tuning habits. You know, some senior operators just have a different "feel."
  3. Environmental Parameter Drift: The experiment spanned several days, and the environmental temperature and humidity data provided by facility management exceeded the standard range during certain periods, but no one reported it.
  4. Measurement Error: Several parameters in the report showed abnormally large measurement data variation. Subsequent investigation revealed that the measurement instrument had not been calibrated for a long time, leading to inaccurate readings.
  5. Sample Contamination: Several wafers were improperly packaged during transport and contaminated with foreign matter, naturally resulting in scrap.

Therefore, the key is that before executing a DOE, all "non-experimental factors" must be stable and consistent, from machine status, personnel operation, environmental conditions, to the measurement system, all must be like a legendary copy-pasted SOP. This is what "controlling variables" truly means!

The Most Common Pitfall: When You Mistake "Should Be" for "Is Actually"

The most common pitfall I've encountered is engineers mistaking "it should be this way" for "it actually is this way." The boss asks: "Has the machine been calibrated?" You reply: "It should have been, it was scheduled for yesterday according to the PM schedule." But you didn't double-check. The boss asks: "Did the operators follow the SOP?" You reply: "They're experienced, there shouldn't be any problems." Only when your data explodes do you discover they "habitually" skipped a certain step. These "should-bes" are breeding grounds for DOE failures. To put it plainly, in process experiments, there is no "should be," only "confirmation."

One Thing You Can Do Today

Before your next DOE, spend 10 minutes checking the machine's latest PM records.

Want to try it yourself?

Every tool mentioned in this article is available on InsightFab — just upload a CSV to analyze.

Go to Tools