Improve Phase: Solution Selection Matrix and Pilot Design

That day, when the Cpk report came out, the room went silent for three seconds, and then I saw the section chief's face turn grim.

Have you ever encountered such a troublesome situation? On Monday morning in a meeting, a machine's critical parameter suddenly dropped to an unfamiliar level. I remember that time, in an etching process, the Critical Dimension (CD) of a certain hole suddenly drifted, and the Cpk plummeted from 1.35 to 1.08. The moment the report came out, the air in the meeting room froze for three seconds, and then I saw the section chief's face turn pale, because this number directly impacted the yield. At that point, we had already gone through the Define, Measure, and Analyze phases, confirming that the root cause was an unstable gas flow controller. Now, the problem emerged: with five or six potential solutions, which one should we choose? This is what we're going to discuss today in the Improve phase, specifically the "Solution Selection Matrix" and "Pilot Design."

Which "Miracle Cure" should we choose?

In essence, the Solution Selection Matrix is a tool that allows you to stop making decisions "based on intuition." Do you often hear: "I think changing to this brand of valve would be better," or "I think writing a program to monitor it would suffice"? Frankly, these "I think" statements are often the beginning of mistakes. After we complete the Analyze phase and identify a host of possible improvement solutions, such as:

1. Replace the gas flow controller (MFC) with Brand A.
2. Replace the gas flow controller (MFC) with Brand B.
3. Install an online gas analyzer.
4. Change the MFC calibration frequency from monthly to weekly.
5. Develop an AI algorithm to predict MFC drift.

With so many options, how do you know which one offers the greatest benefit, lowest risk, and most reasonable cost? This is where the selection matrix comes into play. It helps you list all the consideration factors and then score each solution.

How to do it in practice? It's all about scoring!

This matrix is actually not complicated; you can set it up easily with Excel.

1. List all candidate solutions: These are the five solutions mentioned earlier.
2. Determine evaluation criteria: This is the key! You need to define these based on your factory's actual situation. For example, I would consider the following points:

* Difficulty: The simpler, the better, weighted 15%.

* Expected Benefit: The estimated Cpk improvement, weighted 30%.

* Risk: Potential side effects upon implementation, the lower, the better, weighted 20%.

* Time: Time required for implementation, the shorter, the better, weighted 15%.

1. Score each solution: Assign a score from 1 to 5 for each evaluation criterion (1 being the worst, 5 being the best). For example, replacing MFC Brand A might score 4 for cost but 5 for expected benefit. Developing an AI algorithm might score 2 for cost (initial development manpower) but 1 for implementation difficulty (engineers would be overwhelmed).
2. Calculate the weighted total score: Multiply each score by its weight, then sum them up. The solution with the highest total score is the one you should prioritize.

In our case, replacing the unstable MFC improved Cpk from 1.08 to 1.50, reduced DPMO from 6210 to 3.4, with a cost of only a few hundred thousand and an implementation time of two weeks. It ultimately received the highest score in the matrix.

Once a solution is selected, it's not immediately rolled out across the board; instead, "Pilot Design" is necessary. In other words, a small-scale test. For example, if we have 20 identical machines, you wouldn't replace all 20 MFCs at once. We would first select 1-2 machines, install the new MFCs, and closely monitor the data. The advantage of this approach is that if the new solution has any unexpected problems, the impact will be minimal. It's like buying a new phone; you don't buy ten at once, you usually buy one to try out.

The most common pitfall: Numbers can lie, but people lie even more.

The biggest pitfalls I've seen are "non-objective evaluation criteria" and "biased evaluators." Sometimes, an engineer will give a high score to a solution they themselves proposed and low scores to others' proposals. In such situations, as the project leader, you must insist on "letting the data speak." Additionally, the weighting of evaluation criteria is crucial; if you set "implementation difficulty" too high, everyone will choose simple solutions, but simple solutions are not necessarily the most effective. Also, during the Pilot phase, it's essential to ensure the data is authentic and not "beautified" to push a solution through. I've even seen cases where someone secretly increased the maintenance frequency of the test machine to make the pilot data look good, only for it to fail miserably after full implementation. Honestly, such shortcuts ultimately fall back on the individual.

One thing you can do today

Next time you encounter multiple solutions, try listing three evaluation criteria and scoring each solution!