1. Was ist Root Cause Analysis?
Root Cause Analysis (RCA) ist ein systematischer Problemlösungsprozess zur Identifikation der grundlegenden Ursache(n) eines Problems oder Fehlers. Ziel ist nicht die Behandlung von Symptomen, sondern die dauerhafte Beseitigung der Fehlerquelle.
Der Unterschied:
| Ansatz | Frage | Ergebnis |
|---|---|---|
| Symptombehandlung | "Wie beheben wir das Problem schnell?" | Problem tritt wieder auf |
| Root Cause Analysis | "Warum ist das Problem entstanden?" | Problem wird dauerhaft gelöst |
Root Cause Analysis ist keine einzelne Methode, sondern ein Oberbegriff für verschiedene Techniken. Die bekanntesten sind 5-Why und das Ishikawa-Diagramm.
2. Die 5-Why-Methode
Grundprinzip
Die 5-Why-Methode wurde von Taiichi Ohno bei Toyota entwickelt. Das Prinzip ist simpel: Frage fünfmal "Warum?", um von der Oberfläche zur Wurzel des Problems vorzudringen.
5-Why: Iterative Fragetechnik, bei der durch wiederholtes Fragen nach dem "Warum" die tieferliegende Ursache eines Problems aufgedeckt wird. Die Zahl 5 ist ein Richtwert – manchmal reichen 3 Fragen, manchmal braucht man 7.
Beispiel: Maschine steht still
| Frage | Antwort |
|---|---|
| 1. Warum steht die Maschine? | Die Sicherung ist durchgebrannt. |
| 2. Warum ist die Sicherung durchgebrannt? | Der Motor war überlastet. |
| 3. Warum war der Motor überlastet? | Das Lager war nicht ausreichend geschmiert. |
| 4. Warum war das Lager nicht geschmiert? | Die Schmierpumpe fördert nicht genug. |
| 5. Warum fördert die Pumpe nicht genug? | Der Pumpenfilter ist verstopft. |
→ Root Cause: Verstopfter Pumpenfilter
→ Maßnahme: Filterreinigung in Wartungsplan aufnehmen
Praxis-Tipp
Stoppen Sie nicht bei der ersten "bequemen" Antwort. Wenn die Antwort auf ein Why mit "menschliches Versagen" endet, fragen Sie weiter: Warum konnte der Mensch diesen Fehler machen? Was hat das System nicht verhindert?
Regeln für effektive 5-Why
- Faktenbasiert arbeiten – keine Vermutungen
- Am Ort des Geschehens (Gemba) durchführen
- Team einbeziehen – verschiedene Perspektiven
- Nicht bei Personen stoppen – Systemfehler suchen
- Dokumentieren – für spätere Nachvollziehbarkeit
Häufiger Fehler
Die 5-Why-Analyse endet bei "Mitarbeiter hat nicht aufgepasst". Das ist keine Root Cause! Fragen Sie weiter: Warum konnte er nicht aufpassen? War die Arbeitsanweisung unklar? Fehlte eine Prüfung?
3. Das Ishikawa-Diagramm (Fischgräten-Diagramm)
Grundprinzip
Das Ishikawa-Diagramm wurde von Kaoru Ishikawa in den 1960er Jahren entwickelt. Es visualisiert mögliche Ursachen eines Problems in kategorisierten Zweigen – ähnlich einer Fischgräte.
Ishikawa-Diagramm: Grafische Methode zur strukturierten Sammlung und Kategorisierung potenzieller Fehlerursachen. Der "Kopf" des Fisches ist das Problem, die "Gräten" sind Ursachenkategorien.
Die 6 M (klassische Kategorien)
| M | Kategorie | Beispielfragen |
|---|---|---|
| Mensch | Personal, Qualifikation | Ausbildung? Erfahrung? Motivation? |
| Maschine | Anlagen, Werkzeuge | Zustand? Wartung? Kalibrierung? |
| Material | Rohstoffe, Zukaufteile | Qualität? Spezifikation? Lieferant? |
| Methode | Prozesse, Verfahren | Arbeitsanweisung? Reihenfolge? |
| Messung | Prüfmittel, Messverfahren | Genauigkeit? Häufigkeit? |
| Mitwelt | Umgebung, Umwelt | Temperatur? Feuchtigkeit? Sauberkeit? |
Je nach Branche werden die Kategorien angepasst. In der Dienstleistung z.B.: Mensch, Methode, Material, Management, Umgebung.
Durchführung Schritt für Schritt
- Problem definieren (rechts am "Fischkopf")
- Hauptkategorien festlegen (6 M oder angepasst)
- Brainstorming – alle möglichen Ursachen sammeln
- Zuordnen – Ursachen den Kategorien zuweisen
- Vertiefen – für jede Ursache: Warum? (Sub-Gräten)
- Priorisieren – wahrscheinlichste Ursachen markieren
- Verifizieren – Hypothesen mit Daten prüfen
Praxis-Tipp
Führen Sie das Ishikawa-Diagramm am Whiteboard oder Flipchart durch – nicht am PC. Die visuelle, gemeinsame Arbeit fördert die Kreativität und Beteiligung des Teams.
4. Weitere RCA-Methoden
| Methode | Beschreibung | Einsatz |
|---|---|---|
| 5-Why | Iteratives Warum-Fragen | Schnelle Analyse, einfache Probleme |
| Ishikawa | Kategorisierte Ursachensammlung | Komplexe Probleme, Teamarbeit |
| Fault Tree Analysis (FTA) | Top-Down, logische Verknüpfungen | Sicherheitskritische Systeme |
| Pareto-Analyse | 80/20-Regel, häufigste Ursachen | Priorisierung bei vielen Fehlern |
| Kepner-Tregoe | Strukturierte Problemanalyse | Komplexe, unklare Situationen |
| Apollo Root Cause | Realitätsbasierte Ursachenketten | Investigative Analysen |
In der Praxis werden oft mehrere Methoden kombiniert: Ishikawa für die Ursachensammlung, 5-Why für die Vertiefung, Pareto für die Priorisierung.
5. RCA in der Praxis: Ein Beispiel
Ausgangssituation
Ein MedTech-Unternehmen erhält Kundenreklamationen: "Batterie des tragbaren Monitors entlädt sich zu schnell."
Schritt 1: Ishikawa-Brainstorming
Gesammelte Ursachen:
| Kategorie | Mögliche Ursachen |
|---|---|
| Mensch | Falsche Handhabung, Lagerung beim Kunden |
| Maschine | Produktionsfehler, Lötqualität |
| Material | Batteriequalität, neuer Lieferant |
| Methode | Firmware-Bug, Energiemanagement |
| Messung | Endprüfung erfasst Problem nicht |
| Mitwelt | Transport, Temperatur im Lager |
Schritt 2: Priorisierung mit Daten
- Reklamationen erst seit Monat X → Korrelation mit neuem Batterielieferant
- Seriennummern-Analyse → betrifft nur bestimmte Chargen
- Labor-Test → neue Batterien haben 15% weniger Kapazität als spezifiziert
Schritt 3: 5-Why auf priorisierte Ursache
| Frage | Antwort |
|---|---|
| 1. Warum entlädt sich die Batterie zu schnell? | Die Kapazität ist geringer als spezifiziert. |
| 2. Warum ist die Kapazität geringer? | Der neue Lieferant verwendet andere Zellen. |
| 3. Warum wurden andere Zellen akzeptiert? | Die Wareneingangsprüfung prüft nur Spannung, nicht Kapazität. |
| 4. Warum wird Kapazität nicht geprüft? | Es gab keine Spezifikation dafür. |
| 5. Warum keine Spezifikation? | Bei Lieferantenwechsel wurde kein Design Review durchgeführt. |
→ Root Cause: Fehlender Design Review bei Lieferantenwechsel
→ Maßnahme: Prozess "Lieferantenwechsel kritischer Komponenten" mit verpflichtendem Review einführen
6. RCA im Qualitätsmanagement
| Norm | Anforderung | Kapitel |
|---|---|---|
| ISO 9001 | Ursachenanalyse bei Nichtkonformitäten | 10.2.1 |
| ISO 13485 | Korrekturmaßnahmen inkl. Ursachenanalyse | 8.5.2 |
| IATF 16949 | Systematische Problemlösung (8D) | 10.2.3 |
| FDA 21 CFR 820 | CAPA mit Root Cause | §820.100 |
RCA ist keine eigenständige Norm-Anforderung, sondern integraler Bestandteil von CAPA (Corrective and Preventive Action). Ohne echte Ursachenanalyse keine wirksame Korrekturmaßnahme.
7. Häufige Fehler bei der Root Cause Analysis
Fehler 1: Zu früh aufhören
Nach dem ersten "Warum" ist meist nur ein Symptom gefunden. Graben Sie tiefer!
Fehler 2: Schuld statt System
"Mitarbeiter X hat Fehler gemacht" ist keine Root Cause. Fragen Sie: Warum konnte der Fehler passieren? Was hat das System nicht verhindert?
Fehler 3: Keine Daten
Vermutungen statt Fakten führen zu falschen Maßnahmen. Verifizieren Sie Ihre Hypothesen!
Fehler 4: Alleine arbeiten
RCA ist Teamarbeit. Unterschiedliche Perspektiven finden unterschiedliche Ursachen.
Fehler 5: Keine Dokumentation
Ohne Dokumentation gehen Erkenntnisse verloren. Ähnliche Probleme werden erneut analysiert.
8. Zusammenfassung
Root Cause Analysis auf einen Blick
- ✓ Ziel: Grundursache finden, nicht Symptome behandeln
- ✓ 5-Why: Einfach, schnell, iterativ
- ✓ Ishikawa: Strukturiert, visuell, für komplexe Probleme
- ✓ Immer im Team durchführen
- ✓ Faktenbasiert arbeiten, Hypothesen verifizieren
- ✓ System hinterfragen, nicht Menschen beschuldigen
- ✓ Ergebnisse dokumentieren
Probleme tauchen immer wieder auf?
Mit Erfahrung in systematischer Problemlösung unterstütze ich Sie bei RCA-Workshops, der Etablierung systematischer Problemlösungsprozesse und dem Aufbau wirksamer CAPA-Systeme - pragmatisch und nachhaltig.
Kostenloses Erstgespräch vereinbaren