Root Cause Analysis: A Worked Manufacturing Example

Define the problem before explaining it

Describe the gap in observable terms: what happened, where, when, how often, how large the effect was, and what should have happened instead. Avoid causal language in the problem statement. “Filler 2 is unreliable” already assumes the answer; “unplanned stops exceeded 46 minutes on SKU B during night shift” can be tested.

Freeze the relevant evidence early: event logs, alarm sequences, sensor trends, quality records, operator observations, maintenance work, product mix, and recent changes. Synchronize timestamps before reconstructing the sequence.

• Contain an immediate safety or customer risk under the approved procedure.
• Use the method table next to choose a way to organize evidence.
• Follow the six-jam example, then record your own competing explanations in the worksheet.

Choose an RCA method for the problem

Use the tools to ask better questions. A fishbone diagram is useful when several explanations remain plausible. A 5 Whys chain helps explore one explanation in detail. Stop when you run out of evidence, even if you have asked fewer than five questions.

ASQ describes RCA as part of a larger problem-solving process. Protect people and customers first. Urgent containment can run alongside the investigation, but record it separately from a permanent corrective action.

Worked RCA example: six packaging jams

This is a fictional teaching example, not a Vrolen customer result. A packaging line has six jams totaling 46 minutes during ten runs of product B. Product A runs without the same jam. The first report says “operator setup error.” That label is too broad to tell us what to fix.

The investigation compares the jam timeline, product setup records and maintenance observations. It considers low air pressure, faulty packaging material and an incorrect guide setting. The table separates observations from conclusions.

Test causal candidates against evidence

For each hypothesis, state the expected signature: what should be present if the cause is true, what should be absent, and what observation would disprove it. Check timing, mechanism, dose or frequency, and consistency across affected and unaffected runs.

Operational models and simulation can test whether a candidate cause is capable of producing the observed system effect. This is a counterfactual check, not proof. Confirmation still requires physical evidence, a controlled trial, inspection, measurement, or recurrence data.

• Did the candidate precede the effect?
• Is there a credible physical or process mechanism?
• Does the pattern appear when the candidate is present and disappear when absent?
• Can the observed magnitude and timing be reproduced?
• What alternative explanation fits the evidence equally well?

Follow the loss across the system

Production systems propagate effects. An upstream micro-stop can starve a downstream constraint minutes later; a quality hold can appear as low performance; a scheduling rule can create apparent equipment downtime. Align events on one timeline and distinguish the origin of the disturbance from the location where the KPI moved.

Constraint context helps prioritize the investigation. A frequent fault on a protected, non-constraint process may be less urgent than a smaller recurring disturbance at the system constraint. This does not make the first fault acceptable, it clarifies impact and sequencing.

Design corrective action and prove it held

Corrective actions should remove or control the verified cause, strengthen detection, and avoid transferring risk elsewhere. Assign an owner, due date, verification metric, and observation window. Training alone is weak when the process, control, design, or workload still makes the failure likely.

After implementation, verify both the local mechanism and the system outcome. Confirm that the failure signature disappeared, the target metric improved under comparable conditions, and no new safety, quality, or flow problem emerged. Update standard work, maintenance logic, alarms, and the operating model with what the team learned.

1. Contain

   Protect people, customers, and production while preserving evidence.

2. Explain

   Build and test competing causal chains.

3. Correct

   Remove or control verified causes and failed barriers.

4. Verify

   Observe performance over a defined window and comparable conditions.

5. Standardize

   Update controls, work, training, and monitoring.

Use the RCA worksheet and verify the action

Download the blank worksheet and the filled teaching example below. Record the problem, containment, each candidate cause, evidence for and against it, the test, an action owner and the review date. Keep “not checked” separate from “rejected.”

In the example, the proposed action is to add the product-specific width check to the approved changeover process and verify it before release. Observe ten comparable product-B runs, recording running hours and jam duration as well as jam count. Zero jams in a short test would be encouraging, but would not prove the fault can never return.

Use a downtime Pareto to choose the next recurring loss. For a problem needing several teams, the A3 worked example shows how to keep the investigation and follow-up together. Software selection belongs in the separate RCA software guide.