Definition
Root Cause Analysis, or RCA, is a structured investigation of the underlying causes of a problem so corrective action addresses more than its symptoms. It uses evidence to explain what happened, how it happened, and what must change to prevent or reduce recurrence.
RCA is not complete when a team produces a plausible story or fills out a corrective-action form. The causal explanation and the effectiveness of the response both require verification.
Separate containment, correction, and corrective action
Containment protects the customer or operation while the problem is being investigated. It may include isolating suspect product, additional verification, controlled sorting, or temporary restrictions.
Correction addresses the immediate nonconformity, such as reworking an affected part or replacing an incorrect record. Corrective action addresses the cause so the problem is less likely to return.
These activities may proceed in parallel, but they serve different purposes. A successful sort can protect the next shipment without explaining why the defect occurred or why the existing controls missed it.
Define the problem before selecting a cause
Specify the requirement, the observed deviation, affected scope, timing, and operating conditions. Retain the records needed to compare where the problem occurs with where it does not.
For a supplier issue, align the buyer's and supplier's definitions of the event. Different assumptions about revision, measurement, unit of analysis, or exposure can send the teams toward incompatible explanations.
Tools such as 5 Whys and cause-and-effect diagrams help generate and organize hypotheses. They do not prove that the final branch of a discussion is the actual cause.
A hypothetical machining incident
In a separate incident involving the precision-component process, a bore measures 10.120 millimeters against an upper specification of 10.100. The team contains potentially affected material and checks the measurement method before drawing conclusions.
The investigation finds that the issue appears after one setup-recovery sequence but not after the normal sequence. Program records show that the recovery route restores an outdated tool offset, and a controlled test on non-release trial material reproduces the problem.
| Investigation layer | Hypothetical finding | Required response |
|---|---|---|
| Occurrence | An outdated offset is restored during recovery | Remove the obsolete configuration and control the recovery path |
| Escape | Recovery does not trigger the required first-piece release | Add and verify the appropriate release interlock |
| System control | Setup changes were not consistently assessed for risk | Update change review, responsibilities, and linked documents |
| Effectiveness | The revised route must work under relevant conditions | Test the change and monitor subsequent production evidence |
The example is separate from the SPC early-warning illustration and does not imply that its in-spec reading was the same event. It also does not establish that every oversize bore has a software or setup cause.
The team should preserve the evidence that distinguishes this explanation from alternatives such as tool wear or measurement error. Tests must be authorized and designed so they do not expose customers, people, or equipment to unnecessary risk.
Avoid ending the analysis at “operator error”
An operator action may be part of the event sequence, but it may not explain why the system allowed the failure. Examine instructions, access, interface design, training, workload, verification, and the availability of approved alternatives.
Likewise, “retrain the operator” is not automatically an adequate corrective action. If an uncontrolled recovery sequence remains available, repeating the training may leave the mechanism intact.
Investigate both occurrence and escape. A change that reduces the chance of producing a defect and a change that prevents its release address different weaknesses.
Verify the cause and then verify the action
Cause verification asks whether the evidence supports the proposed mechanism. Action verification asks whether the implemented change addresses that mechanism without creating an unacceptable new problem.
Define acceptance criteria before closing the issue. The evidence may include controlled challenge tests, representative setup changes, observation across shifts, and monitoring over a justified production period.
A few good parts or a short period without complaints may be insufficient for an intermittent problem. The verification plan should reflect the way the failure occurs and the exposure needed to evaluate recurrence.
Update the operating system and retain the learning
Translate the approved change into work instructions, training, maintenance, process-risk analysis, control plans, and customer notifications where required. Assign ownership so the revised practice survives staff changes and schedule pressure.
Check whether the same mechanism exists in other lines, sites, products, or suppliers. Apply lessons where technically relevant rather than copying a solution into a different process without validation.
Do not confuse completing an action with recovering its economic value. Reduced scrap, rework, disruption, or warranty cost must be measured through the relevant operating and financial records.
Frequently asked questions
- Must RCA identify exactly one root cause? No. A problem may involve multiple interacting causes and failed controls that require separate actions.
- Are five “whys” always enough? No. The number of questions is less important than the quality of the causal evidence.
- Can containment be removed when the action is installed? Not automatically. Follow the approved effectiveness and release criteria before withdrawing protective measures.
Close the problem, not just the report
VPP connects supplier corrective-action discussions to evidence, accountable implementation, and sustained results. The objective is to reduce recurrence and operating exposure rather than accept a completed report as proof that the underlying issue is resolved.