8DUrsachenanalyse

Fünf Anzeichen, dass Ihr 8D-Report geschlossen, das Problem aber nicht behoben ist

Die meisten 8D-Reports wirken abgeschlossen. Fünf Prüfpunkte, sichtbar allein im Papier, zeigen, ob der Fehler wirklich aufgehört hat.

Von Matej Kalčič, Founder & CEO, Galileon6 Min. Lesezeit
Fünf Anzeichen, dass Ihr 8D-Report geschlossen, das Problem aber nicht behoben ist, schwarzer Hintergrund, goldener Akzent.

“Problem gelöst. Fall geschlossen. Unterschrieben. Abgelegt.”

Neun Monate später kehrt derselbe Fehler zurück.

Öffnen Sie ein beliebiges 8D-Archiv. Die meisten Reports wirken abgeschlossen. Wenige sind es wirklich, und die fünf Anzeichen eines fehlerhaften Prozesses stehen nicht in der Fertigung. Sie stehen im Papier selbst, und man findet sie, ohne den Schreibtisch zu verlassen.

Warum das keine Ermessensfrage ist

8D ist keine allgemeine Vorliebe für strukturierte Problemlösung. Fords eigene kundenspezifische Anforderungen (IATF Customer-Specific Requirements) nennen “Global 8D” als vorgeschriebenes Format für Korrekturmaßnahmen bei Lieferanten: Reaktion innerhalb von 24 Stunden, Sofortmaßnahme im selben Zeitfenster umgesetzt, der vollständige 8D-Report mit Grundursache und einem Plan für Korrektur- und Vorbeugemaßnahmen dann innerhalb von 15 Kalendertagen.

Diese beiden Fristen messen unterschiedliche Dinge. Die 24-Stunden-Frist schützt den Kunden heute. Der Report am 15. Tag soll beweisen, dass die Ursache tatsächlich gefunden und behoben wurde, nicht nur zurückgehalten. Ein Report, der D3 nie von D5 getrennt hat, kann beide Fristen im Kalender einhalten und die zweite trotzdem inhaltlich verfehlen.

Das Papier sagt es bereits

Ein 8D-Report soll zwei Dinge beweisen: dass das Team verstanden hat, was schiefgelaufen ist, und dass es eine Wiederholung verhindert hat. Die meisten Reports beweisen nur das Erste, und auch das nicht immer.

Fünf Prüfpunkte trennen einen Report, der geschlossen wurde, von einem Report, der gewirkt hat. Lesen Sie sie der Reihe nach, anhand Ihres letzten geschlossenen 8D-Reports.

Eins: die Sofortmaßnahme im Kleid der Abstellmaßnahme

Karussell-Tafel: Sofortmaßnahme und Abstellmaßnahme stehen auf derselben Zeile. D3: “Schulung des Bedieners.” D5: “Bediener erneut schulen.”

D3 ist die Sofortmaßnahme: Teile sortieren, eine Prüfung einführen, die Blutung stoppen. D5 verifiziert und wählt die dauerhafte Abstellmaßnahme, die Maßnahme, die die Ursache beseitigt. D6 führt sie dann ein.

Stehen D3 und D5 auf derselben Zeile, ist aus der Übergangslösung nie eine echte Abhilfe geworden. “Schulung des Bedieners” in D3 und “Bediener erneut schulen” in D5 benennen eine einzige Handlung zweimal, nicht zwei verschiedene.

Der 8D-Rahmen, der auf Fords Handbuch Team Oriented Problem Solving von 1987 zurückgeht, hält diese beiden Schritte bewusst getrennt. Eine Sofortmaßnahme kauft Zeit. Eine Abstellmaßnahme beseitigt die Ursache, die die Sofortmaßnahme überhaupt nötig machte. Ein Report, der beides nicht auseinanderhält, hat nie tatsächlich geprüft, ob die Ursache beseitigt wurde.

Zwei: eine Beschreibung, die in drei Zeilen passt

Karussell-Tafel: D2 ist kürzer als drei Zeilen. Beispiel D2: “Teil NOK. Kundenreklamation. Siehe Anlage.”

D2 soll das Problem präzise genug beschreiben, um danach suchen zu können: was, wo, wann, wie viel. Eine Beschreibung, die kürzer als drei Zeilen ist, ist meist nur ein wiederholtes Symptom, keine Beschreibung.

Dieses Anzeichen verdient eine eigene Geschichte, keinen Absatz. Zwei Jahre für die Beschreibung eines Fehlers erzählt sie vollständig: ein Fehler, dessen Beschreibung zwei Jahre brauchte, dessen Behebung dann Wochen dauerte, sobald er sich auf Abruf erzeugen ließ.

Drei: das Feld “Ist-Nicht”, das leer bleibt

Karussell-Tafel: das Feld für das, was das Problem NICHT ist, bleibt leer. Beispiel: Problem IST: Stift verbogen, Linie 2. Problem IST NICHT: (leer).

Charles Kepner und Benjamin Tregoe bauten eine Methode um eine Frage, die die meisten Reports auslassen: wo tritt der Fehler nie auf. Ihr Buch von 1965, The Rational Manager, strukturiert jedes Problem gleich: festhalten, wo es IST, dann festhalten, wo es NICHT ist. Der Unterschied zwischen beiden Spalten ist der einzige Ort, an dem die Grundursache liegen kann.

Der VDA empfiehlt für D2 und D4 im 8D-Report ausdrücklich die Kepner-Tregoe-Methode Ist/Ist-Nicht und wertet sie als Zeichen einer revisionssicheren Analyse. Ein Report, in dem das Feld Ist ausgefüllt und das Feld Ist-Nicht leer ist, hat nichts eingegrenzt. Jede Theorie bleibt gleich wahrscheinlich.

Vier: nirgends ein Verifizierungsdatum

Karussell-Tafel: kein Verifizierungsdatum, nirgends. Beispiel: “D6 wirksam verifiziert am: ______ Status: GESCHLOSSEN”.

D6 dient dazu, nach einer festgelegten Frist zu bestätigen, dass die Abstellmaßnahme den Fehler tatsächlich gestoppt hat. Ein Report kann eine Abhilfe einführen und sie nie überprüfen.

Ein geschlossener Report ohne Verifizierungsdatum hat die Absicht zur Prüfung festgehalten. Die Prüfung selbst hat er nicht festgehalten.

Fünf: eine Grundursache, drei Reportnummern

Karussell-Tafel: dieselbe Grundursache in drei getrennten Reports. Beispiel: Grundursache, Reports A, B und C: “mangelnde Schulung”. Ein ursächlicher Faktor, keine Grundursache.

D7 soll verhindern, dass eine bekannte Ursache an anderer Stelle im Werk zurückkehrt. Das funktioniert nur, wenn jemand neue Reports mit alten vergleicht.

Taucht dieselbe Grundursache in drei getrennten Reports auf, hat D7 versagt, bevor es überhaupt begonnen hat: Niemand hat die Reports nebeneinandergelegt. TapRooT, eine in der Schwerindustrie verbreitete Methode der Ursachenanalyse, zieht hier eine klare Grenze. “Mangelnde Schulung” ist ein ursächlicher Faktor, die Stelle, an der der Prozess einen Fehler durchließ, keine Grundursache, der Grund, warum der Prozess diese Lücke überhaupt zuließ. Ein Report, der beim ursächlichen Faktor stehen bleibt, wird geschlossen. Die Lücke, durch die der Fehler kam, bleibt für den nächsten Report offen.

Warum Reports bestehen und Fehler nicht

James Reason, von der University of Manchester, veröffentlichte 1990 das Schweizer-Käse-Modell. Jede Schicht eines Sicherheitssystems hat Löcher. Meistens liegen die Löcher auf verschiedenen Schichten an verschiedenen Stellen, und nichts kommt durch. Zu einem Fehler kommt es, wenn sich die Löcher ausrichten.

Ein 8D-Archiv funktioniert genauso. Jeder Report fängt sein eigenes Loch. Niemand legt die Reports nebeneinander. Das Formular wurde gebaut, um unterschrieben zu werden, nicht um einen Fehler zu fangen, der durch eine Lücke zurückkehrt, die fünf getrennte Reports schon jeder für sich beschrieben haben.

Ein Leck, an dem ich einmal gearbeitet habe, bestand fünfzehn Jahre lang. Als wir einmal aufschrieben, was es wirklich war, das ganze Problem, jeden betroffenen Prozessschritt, dauerte die Behebung vier Tage und war endgültig gelöst. Das Papier war nie der schwierige Teil. Der schwierige Teil war, eine genaue Beschreibung des Problems zu schreiben.

Nicht jedes Problem verdient einen 8D

8D ist für Kundenreklamationen gebaut und für Probleme, die ernst genug sind, um eine vollständige Team-Untersuchung zu rechtfertigen. Wer eine interne Abweichung oder einen kleinen Ausschuss durch alle acht Disziplinen schickt, verbrennt eine Woche Ingenieurzeit für ein Problem, das einen Nachmittag gebraucht hätte.

4-Step deckt interne Abweichungen ab. PDCA deckt kontinuierliche Verbesserung ab. Just-Do-It deckt alles ab, was trivial genug ist, um es sofort zu beheben. Die richtige Methode soll den Weg zur Abhilfe verkürzen. Die falsche Methode verlängert ihn nur.

Was ein Report tatsächlich schließt

Ein unterschriebener 8D-Report beweist, dass das Formular ausgefüllt wurde. Ein Fehler, der nie zurückkehrt, beweist, dass die Abhilfe gewirkt hat. Nur eine dieser beiden Aussagen verdient das Wort “geschlossen”.

Nehmen Sie Ihren letzten geschlossenen 8D-Report zur Hand. Prüfen Sie alle fünf Anzeichen der Reihe nach. Die meisten Reports scheitern an mindestens einem.

Mehr auf galileon.si

Quellen

Alle Beiträge