Root Cause Analysis in PCB Manufacturing

Root cause analysis is the method a board shop uses to stop a defect from coming back. It is not a meeting and it is not a form; it is a short investigation that ends with a change that can be verified. Most failed attempts at problem solving in a factory fail for the same reason, which is that the investigation stops as soon as an explanation sounds plausible, and the plausible explanation is usually the one that was suggested first rather than the one the evidence supports.

What Counts as a Root Cause

A root cause is a condition that can be changed and whose removal prevents the recurrence. That definition excludes anything that names a person or a mood, and it also excludes the defect itself, since a short circuit is a symptom rather than a cause. The test is simple: if the finding cannot be turned into a change to a parameter, a tool, a material, an instruction or a check, then the investigation has not finished.

There is usually more than one contributing condition, and it is worth separating them rather than arguing about which is the cause. An escape of a defective panel may involve a process condition that produced the defect and a detection weakness that allowed it to pass. Both are worth correcting, and both need an owner, because fixing only the process leaves the detection gap and fixing only the detection leaves the defects being made.

Describing the Problem Precisely

Defect investigation starts with a description that can be measured. Which board, which panel, which batch, which machine, which shift, how many units, and what exactly was observed. A description that is vague will produce a vague cause, because an investigation can only work with what it has been given. Photographs and coupon measurements at this stage save hours of discussion later.

The description should also state where the defect was found and where it probably originated, since those are often different steps. A hole wall void found at final inspection may originate in drilling, in desmear or in plating, and knowing that it was found at the end while being made at the start is itself useful information about how the control failed to catch it earlier.

<img src="https://www.gopcba.com/wp-content/uploads/2023/05/victor-garcia-2PJMDIgK9EA-unsplash.jpg" alt="Team working through a fishbone diagram on a whiteboard” />

Using a Fishbone Diagram

A fishbone diagram organises possible causes into a few branches, usually machine, method, material, measurement, man and environment. Its value is not the drawing but the discipline of covering every branch before choosing a hypothesis. Most investigations that reach a wrong conclusion have skipped a branch, and the skipped branch is usually the one that nobody on the team owns.

The branches should be filled in with specific candidate conditions rather than general categories. Under material, the candidates might be a laminate lot, a prepreg batch or a bath chemistry; under method, a bake time, a drill parameter or a panel loading arrangement. Once the branches carry candidates, the group can choose which to test, and the test is what turns the diagram from a brainstorm into an investigation.

The 5 Whys in Practice

The 5 whys is a simple chain of questions that pushes an explanation back toward a controllable condition. It works best when each answer is checked against evidence rather than accepted because it sounds right, and it works badly when it is used to reach a conclusion that the team already had in mind. The number five is a guide rather than a rule; the chain stops when the answer is something the shop can change.

A worked chain might run from a mask skid to a squeegee pressure, to the setup sheet, to the fact that the sheet does not state a pressure, to the reason the sheet was never updated after the last change. The useful endpoint is the last item, because it is a documentation gap that will produce the same problem again on the next product. Chains that stop at the operator end at a person, and a person cannot be revised at the next document review.

Testing the Hypothesis

A hypothesis is only worth acting on if it can be tested. The test may be a designed comparison, a review of data from previous batches, or a deliberate change monitored over the next few lots. In a board shop, the fastest test is usually a data comparison: if the hypothesis is a drill parameter, the batches produced with the old and new setting can be compared through the AOI results or the coupon measurements.

The test should be recorded with its result whether or not it confirmed the hypothesis. A rejected hypothesis is valuable, because it removes a candidate and prevents the next investigation from starting in the same place. Shops that record only successful investigations repeat their own work, and the effort spent on the same suspicion three times is the hidden cost of informal problem solving.

Making the Change Stick

The change that closes an investigation should be written into the system rather than into a memory. A parameter goes into the setup sheet, a check goes into the traveller, a material restriction goes into the specification, and a drawing note goes into the fabrication notes. Anything less and the change will survive only as long as the people who made it, which in a shop with turnover is measured in months.

Verification completes the loop. The next few batches should be checked for the defect, and the result recorded against the investigation. If the defect returns, the cause was incomplete and the investigation reopens with better information than it had the first time. If it does not, the shop has one fewer failure mode, which is the only durable kind of quality improvement a factory can make.

Practical Rules

Describe the problem with data, cover all the branches before choosing a hypothesis, and push the explanation until it names something the shop controls. Test the hypothesis, record the outcome either way, and write the change into the documents that govern production.

Keep the investigation short and the participants few. A group of three people with the records in front of them will reach a testable cause in an hour, while a larger meeting will spend the same hour agreeing on the wording of the problem and produce a defect description instead of a cause.

FAQ

How many whys is enough? As many as it takes to reach a condition the shop controls. Five is a guide, not a rule.

What if the cause is a person? Then the investigation is not finished. Look for the instruction, the tool or the environment that allowed the mistake to be easy to make.

Should every defect get an investigation? No. Investigate the defects that repeat, that are expensive, or that could escape to a customer. Rank them by cost and frequency.