Trace the loss through the system—not just to the red KPI.

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.

• Specific object, defect, event, or performance gap
• Location, product, shift, and operating condition
• First occurrence, frequency, duration, and business impact
• Comparable periods where the problem did not occur

Separate symptoms, contributing factors, and root causes

A symptom is where the problem becomes visible. A contributing factor changes its likelihood or severity. A root cause is a controllable causal factor whose treatment prevents recurrence within the defined system. Complex incidents may have several interacting causes rather than one neat answer.

Use a fishbone diagram to organize possible causes, a Pareto chart to focus the evidence, change analysis to identify what became different, and 5 Whys to pursue a causal chain. These tools generate and structure hypotheses; they do not validate them by themselves.

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.