_1762866128417-DS2_OO1j.png)
Warum die Ursachenanalyse entscheidet
Jede Korrekturmaßnahme ist nur so gut wie die Ursachenanalyse, auf der sie beruht. Wer die falsche Ursache findet, setzt teure Maßnahmen um – und das Problem tritt trotzdem wieder auf. ISO 9001 verlangt in Kapitel 10.2 ausdrücklich, die Ursachen von Nichtkonformitäten zu bestimmen; ISO 13485, IATF 16949 und die Harmonized Structure aller ISO-Managementsystemnormen enthalten dieselbe Anforderung.
Die englische Bezeichnung lautet Root Cause Analysis (RCA). Gesucht wird die Grundursache: die Ursache, deren Beseitigung verhindert, dass das Problem wieder auftritt. Häufig ist sie nicht technischer, sondern organisatorischer Natur – etwa eine fehlende Vorgabe, eine unklare Zuständigkeit oder ein Prüfschritt, der nie definiert wurde.
Symptom, direkte Ursache, Grundursache
| Ebene | Beispiel | Maßnahme auf dieser Ebene |
|---|---|---|
| Symptom | Kunde erhält falsch etikettierte Ware | Ware austauschen (Korrektur) |
| Direkte Ursache | Etikettendrucker hat falsche Vorlage verwendet | Vorlage korrigieren |
| Grundursache | Etikettenvorlagen werden ohne Freigabe geändert; keine Prüfung des ersten Etiketts | Freigabeprozess für Vorlagen und Erstetikettenprüfung einführen |
Erst Maßnahmen auf der Ebene der Grundursache verhindern das Wiederauftreten. Korrektur und Beseitigung der direkten Ursache bleiben trotzdem sinnvoll – sie reichen nur allein nicht aus, um das Problem dauerhaft zu lösen. Ein guter Test: Würde das Problem auch dann nicht wieder auftreten, wenn eine andere Person, ein anderes Gerät oder eine andere Schicht beteiligt wäre?
Die 5-Why-Methode
Die 5-Why-Methode stammt aus dem Toyota-Produktionssystem. Ausgehend vom Problem wird so lange „Warum?“ gefragt, bis eine Ursache erreicht ist, die sich beseitigen lässt. Die Zahl fünf ist ein Richtwert – manchmal genügen drei Fragen, manchmal braucht es sieben. Wichtig ist, jede Antwort mit Fakten zu belegen, bevor die nächste Frage gestellt wird.
- 1
Warum fiel die Maschine aus?
Weil die Sicherung durch Überlast ausgelöst hat.
- 2
Warum gab es Überlast?
Weil das Lager nicht ausreichend geschmiert war.
- 3
Warum war es nicht geschmiert?
Weil die Schmierpumpe kein Öl gefördert hat.
- 4
Warum förderte sie kein Öl?
Weil der Ansaugfilter verstopft war.
- 5
Warum war der Filter verstopft?
Weil der Filter nicht im Wartungsplan enthalten war. → Grundursache: Wartungsplan unvollständig.
Stärken: schnell, ohne Hilfsmittel, gut im Team. Grenzen: führt bei mehreren Ursachen leicht auf einen einzigen Pfad; Ergebnis hängt stark vom Wissen der Beteiligten ab. Bei komplexen Problemen sollte 5-Why mit Ishikawa kombiniert werden – oder als Baum mit mehreren Zweigen durchgeführt werden.
Das Ishikawa-Diagramm
Das Ishikawa-Diagramm – nach seiner Form auch Fischgrätendiagramm genannt – sammelt mögliche Ursachen strukturiert nach Kategorien. Am „Kopf“ steht das Problem, an den „Gräten“ die Einflussgrößen. In der Produktion haben sich die 6M bewährt:
| Kategorie | Leitfrage | Beispiele |
|---|---|---|
| Mensch | Welche Rolle spielen Qualifikation, Erfahrung, Belastung? | Neue Mitarbeitende, Schichtwechsel |
| Maschine | Welche Anlagen, Werkzeuge, Software sind beteiligt? | Verschleiß, Einstellung, Wartung |
| Material | Welche Rohstoffe, Teile, Hilfsstoffe? | Lieferantenwechsel, Chargenschwankung |
| Methode | Welche Verfahren, Vorgaben, Abläufe? | Fehlende oder unklare Arbeitsanweisung |
| Mitwelt | Welche Umgebungsbedingungen? | Temperatur, Feuchte, Staub |
| Messung | Wie wird gemessen und geprüft? | Messmittel, Prüfplan, Prüfhäufigkeit |
Im Dienstleistungs- und Verwaltungsbereich werden die Kategorien oft angepasst, etwa um Management, Kommunikation oder IT-Systeme. Wichtig: Das Diagramm sammelt mögliche Ursachen. Welche davon zutreffen, muss anschließend mit Daten bestätigt werden.
Beispiel: Ishikawa und 5-Why kombiniert
Ein Hersteller von Kunststoffteilen stellt seit zwei Wochen vermehrt Lunker – also Hohlräume – in einem Bauteil fest. Das Team sammelt im Ishikawa-Diagramm mögliche Ursachen: neue Granulatcharge (Material), geänderte Trocknungszeit (Methode), hohe Luftfeuchtigkeit in der Halle (Mitwelt), neue Bedienperson in der Nachtschicht (Mensch), Verschleiß der Rückstromsperre (Maschine) und eine geänderte Pr üfmethode (Messung).
Die Daten zeigen: Die Lunker treten in allen Schichten auf, aber nur bei Material aus dem neuen Silo. Damit rücken Material und Methode in den Fokus. Die anschließende 5-Why-Analyse ergibt: Das Granulat aus dem neuen Silo hatte eine höhere Restfeuchte, weil der Trockner für die längere Förderstrecke nicht neu eingestellt wurde – und dafür gab es keine Vorgabe bei Änderungen an der Materialversorgung. Ein Versuch mit verlängerter Trocknungszeit bestätigt die Ursache. Die Grundursache ist damit nicht der Trockner, sondern das fehlende Änderungsmanagement bei der Materialversorgung – und genau dort setzt die Korrekturmaßnahme an.
Weitere Methoden im Überblick
| Methode | Prinzip | Geeignet für |
|---|---|---|
| Ist/Ist-nicht-Analyse | Vergleich, was betroffen ist und was nicht | Eingrenzung bei unklarem Fehlerbild |
| Pareto-Analyse | Häufigste Fehlerarten zuerst angehen (80/20-Regel) | Priorisierung bei vielen Einzelfehlern |
| Fehlerbaumanalyse (FTA) | Logische Verknüpfung von Ursachen mit UND/ODER | Komplexe Systeme, sicherheitskritische Ereignisse |
| Änderungsanalyse | Was hat sich vor dem ersten Auftreten geändert? | Plötzlich auftretende Probleme |
| Streudiagramm | Zusammenhang zwischen zwei Größen prüfen | Bestätigung vermuteter Ursachen |
| FMEA | Systematische Betrachtung möglicher Fehler vorab | Vorbeugung, Neuentwicklungen |
Welche Methode wann?
- Einfaches, klar abgegrenztes Problem: 5-Why im kleinen Team.
- Viele mögliche Einflussgrößen: Ishikawa zur Sammlung, danach 5-Why für die wahrscheinlichsten Zweige.
- Unklares Fehlerbild: zuerst Ist/Ist-nicht-Analyse, um das Problem einzugrenzen.
- Viele verschiedene Fehler: Pareto, um die wichtigsten zuerst anzugehen.
- Sicherheitskritisch oder komplex: Fehlerbaumanalyse mit Expertinnen und Experten.
- Plötzliches Auftreten: Änderungsanalyse – was war anders?
Ursachen bestätigen
Eine plausible Ursache ist noch keine bestätigte Ursache. Bevor Sie Maßnahmen festlegen, prüfen Sie die Hypothese:
- Lässt sich der Fehler mit der vermuteten Ursache gezielt erzeugen?
- Verschwindet er, wenn die Ursache beseitigt wird?
- Erklärt die Ursache alle Fakten aus der Problembeschreibung – auch, warum andere Teile nicht betroffen sind?
- Gibt es Daten, die den Zusammenhang stützen, etwa Messreihen vor und nach einer Änderung?
Die Ursachenanalyse im Team moderieren
- 1
Problem klar beschreiben
Alle Teilnehmenden arbeiten mit derselben, faktenbasierten Problembeschreibung.
- 2
Die richtigen Leute einladen
Personen aus dem Prozess, die die Abläufe vor Ort kennen – nicht nur Führungskräfte.
- 3
Vor Ort gehen
Den Ort des Geschehens ansehen, Teile und Daten prüfen, mit Beteiligten sprechen.
- 4
Ursachen sammeln, nicht bewerten
Zuerst alle Ideen aufnehmen, dann gemeinsam priorisieren.
- 5
Schuldfrage vermeiden
Die Analyse sucht Systemschwächen, keine Schuldigen. Sonst werden Informationen zurückgehalten.
- 6
Ergebnis dokumentieren
Methode, Ursachen, Belege und Teilnehmende festhalten.
Typische Fehler
- „Menschliches Versagen“ als Grundursache: Fast immer steckt dahinter eine Systemschwäche – fehlende Vorgabe, schlechte Ergonomie, Zeitdruck, fehlende Prüfung.
- Zu früh aufhören: Die erste plausible Antwort wird akzeptiert, obwohl weitere „Warum“-Fragen möglich wären.
- Keine Bestätigung: Maßnahmen beruhen auf Vermutungen statt auf geprüften Ursachen.
- Nur die Entstehung betrachten: Warum der Fehler nicht entdeckt wurde, bleibt offen.
- Analyse am Schreibtisch: Ohne Blick auf Prozess, Teile und Daten bleibt die Analyse oberflächlich.
Ursachenanalyse in docxpert
Im CAPA-Management von docxpert ist die Ursachenanalyse eine eigene Phase. Sie wählen 5-Why oder Ishikawa als Methode und dokumentieren die Analyse direkt am Vorgang. Erst wenn die Ursachenanalyse vollständig ist, geht es weiter zum Maßnahmenplan. So bleibt nachvollziehbar, auf welcher Ursache jede Maßnahme beruht.
Häufige Fragen
Warum genau fünf Warum-Fragen?
Die Zahl ist ein Richtwert, keine Regel. Sie erinnert daran, nicht bei der ersten Antwort stehen zu bleiben. Manchmal ist die Grundursache nach drei Fragen erreicht, manchmal braucht es mehr.
Was bedeuten die 6M im Ishikawa-Diagramm?
Mensch, Maschine, Material, Methode, Mitwelt und Messung. Je nach Bereich werden die Kategorien angepasst, etwa um Management oder IT.
Kann menschliches Versagen eine Grundursache sein?
Selten. Meist zeigt die weitere Analyse, warum ein Fehler möglich war und nicht bemerkt wurde – etwa durch fehlende Vorgaben, unklare Gestaltung oder fehlende Prüfungen. Diese Systemschwächen lassen sich beseitigen.
Wie viele Personen sollten an einer Ursachenanalyse teilnehmen?
Drei bis sechs Personen mit unterschiedlichem Blick auf den Prozess sind ideal. Größere Gruppen werden schnell unübersichtlich.
Wie bestätige ich eine Ursache?
Indem Sie zeigen, dass der Fehler mit der Ursache gezielt erzeugt oder abgestellt werden kann, und dass die Ursache alle bekannten Fakten erklärt – idealerweise mit Daten.
Was ist der Unterschied zwischen 5-Why und Ishikawa?
5-Why verfolgt eine Ursachenkette in die Tiefe, Ishikawa sammelt mögliche Ursachen in der Breite. Kombiniert ergänzen sich beide sehr gut.
Brauche ich für jede Abweichung eine Ursachenanalyse?
Für jede Korrekturmaßnahme ja – ISO 9001 verlangt, Ursachen zu bestimmen. Der Aufwand richtet sich nach Bedeutung und Risiko des Problems.
Welche Rolle spielt die FMEA?
Die FMEA ist eine vorbeugende Methode, die mögliche Fehler vor ihrem Auftreten betrachtet. Erkenntnisse aus Ursachenanalysen sollten in die FMEA zurückfließen.
Wie verhindere ich, dass eine Ursachenanalyse nur eine plausible Vermutung festhält?
Formulieren Sie jede vermutete Ursache als überprüfbare Aussage: Wenn sie zutrifft, welche Beobachtung oder Daten wären zu erwarten? Suchen Sie nach Prozessaufzeichnungen, Messwerten, Materialmustern und Aussagen der Personen, die den Ablauf kennen. Vergleichen Sie betroffene Fälle mit Fällen ohne Fehler, damit Gemeinsamkeiten und Unterschiede sichtbar werden. Eine Ursache ist stärker belegt, wenn sie bekannte Fakten erklärt und eine gezielte Änderung des vermuteten Mechanismus das Problem beeinflusst. Trennen Sie dabei Fakten, Annahmen und noch offene Fragen im Protokoll. Fragen Sie außerdem, warum vorhandene Kontrollen den Fehler nicht entdeckt haben; sonst bleibt die Ausbreitung möglich. Vermeiden Sie die Abkürzung „Bedienfehler“, solange Gestaltung, Information, Arbeitslast und Aufsicht nicht geprüft sind. Bei widersprüchlichen Hinweisen sollte das Team weiter untersuchen oder die Unsicherheit ausdrücklich dokumentieren, statt Gewissheit vorzutäuschen.