Horrorszenario: Das Telefon klingelt und Sie erfahren mit Schrecken, dass das Problem, das Sie vor einem Monat für gelöst hielten, zurück ist – und größer als je zuvor. Ihnen wird flau im Magen und Ihr Puls beschleunigt sich, während Sie fieberhaft versuchen herauszufinden, was genau passiert ist. UND Sie wissen, dass es nur eine Frage der Zeit ist, bis die Werksleitung an Ihrer Tür steht, um eine „ernste“ Diskussion zu führen.
Dies geschieht allzu oft und raubt uns wertvolle Zeit für das, wofür wir belohnt werden – Produkte auszuliefern. Schlimmer noch, es bringt uns in den Bereich, für den wir bestraft werden – erneut das zu reparieren, von dem uns gesagt wurde, es sei endgültig behoben.
Bevor wir dazu kommen, was jetzt zu tun ist, werfen wir einen kurzen Blick darauf, was passiert ist, als wir dachten, wir hätten es richtig gemacht, und was in Wirklichkeit schiefgelaufen ist.
Die meisten alltäglichen Ursachenanalysen (Root Cause Analysis, RCA) folgen einem oder einer Kombination der unten aufgeführten Schritte:
- „Ich kenne die Ursache.“ (RCA-Maßnahme – Brainstorming): Beheben Sie das Problem und überlegen Sie hoffentlich, was als Folge der Korrektur vor- oder nachgelagert schiefgehen könnte („über die Korrektur hinausdenken“).
- „Ich glaube, ich kenne die Ursache.“ (RCA-Maßnahme – Five Whys): Verifizieren, beheben und „über die Korrektur hinausdenken“.
- „Ich habe einige Vermutungen zur Ursache.“ (RCA-Maßnahme – Fischgräten-Diagramm): Verwenden Sie die Ursache(n) aus einem Fischgräten-Diagramm, beheben Sie sie und „denken Sie über die Korrektur hinaus“.
Was passiert also in diesem Prozess, wenn man es nicht richtig macht? Es beginnt in der Regel mit der Problembeschreibung. In vielen Fällen neigen Bediener dazu, direkt zur Ursache zu springen und das Problem in so vagen Begriffen zu erfassen, dass nur sie selbst wissen, was gemeint ist. Wenn man versucht, ihnen eine Struktur zu geben, z. B. durch den Five-Why-Prozess, sieht das etwa so aus:
Frage: „Warum ist die Produktion auf Linie drei langsam?“ …
Antwort: „Die neuen Rohre passen nicht.“
Frage: „Warum passen die neuen Rohre nicht?“ …
Antwort: „Das Loch ist zu klein, um ein einfaches Einsetzen zu ermöglichen.“
Frage: „Warum ist das Loch zu klein?“ …
Antwort: „Ich weiß es nicht, gestern war bei uns noch alles in Ordnung.“
Frage: „Was ist seit gestern passiert?“ …
Antwort: „Ich weiß es nicht.“
Normalerweise spricht der Bediener an diesem Punkt mit anderen Kollegen und dem Schichtleiter, und sie entwickeln einige „Lösungen“, indem sie eine verbale Fischgräten-Diskussion für Ideen nutzen. Dann nehmen sie die Änderungen vor, dokumentieren – hoffentlich – was sie getan haben, und machen weiter.
Wann Bestätigung das Brainstorming ersetzen sollte
Was ist also schiefgelaufen? Erstens ist fünf keine magische Zahl im Five-Why-Prozess. Manchmal sind zusätzliche Fragen erforderlich, um zu einer validen möglichen Ursache zu gelangen. Mit „Ich weiß es nicht“ zu enden, liefert keine validen Daten zur Definition einer Ursache. Es zeigt lediglich an, dass mehr Informationen benötigt werden. Bei der Anwendung der 5 Whys ist es wichtig, Antworten aus der vorangegangenen Frage zu isolieren und sich auf deren Bestätigung zu konzentrieren – nicht nur auf Brainstorming. Brainstorming statt gezielter, punktgenauer Befragung impliziert, dass alle Antworten gültig sind, was Bediener dazu ermutigt, viele „Lösungen“ anzuwenden, um alle Antworten abzudecken. Dies verschleiert lediglich die wahre Ursache und überfrachtet die Daten für künftige Analysen, sollte das Problem erneut auftreten.
Dranbleiben: Finden Sie die Ursache der Ursache
Und hier ist noch etwas, das schiefgehen kann. Es ist ebenso wichtig, eine Zwischenursache nicht als „Hauptursache“ zu definieren, ohne sie ZUERST anhand von Fakten und Daten zu prüfen, um festzustellen, ob sie die wahre Ursache ist. Die Falle, die mögliche Ursache nicht zuerst gegen die Fakten zu prüfen, besteht darin, dass Bediener ihre Fehlersuche auf Korrekturen für „bekannte Ursachen“ ausrichten, die in vielen Fällen nichts mit dem ursprünglichen Problem zu tun haben.
Letztendlich können Sie bessere Ergebnisse erzielen, wenn Ihre Bediener bei ihren RCA-Fragen tiefer gehen und nach der Ursache der Ursache suchen, etwa so:
Frage: „Warum ist die Produktion auf Linie drei langsam?“ …
Antwort: „Die neuen Rohre passen nicht.“
Frage: „Warum passen die neuen Rohre nicht?“ …
Antwort: „Das Loch ist zu klein, um ein einfaches Einsetzen zu ermöglichen.“
Frage: „Warum ist das Loch zu klein?“ …
Antwort: „Ich weiß es nicht, gestern war bei uns noch alles in Ordnung.“
Frage: „Was ist seit gestern passiert?“ …
Antwort: „Ich weiß es nicht.“
Frage: „Was ist für das Loch spezifiziert?“ …
Antwort: „Es ist in der Werkzeugeinstellung spezifiziert.“
Frage: „Was ist in der Werkzeugeinstellung spezifiziert?“ …
Antwort: „Was auch immer in der Standardarbeitsanweisung (SOP) für die Werkzeugeinstellung steht.“
Frage: „Haben wir überprüft, was für das Werkzeug eingestellt wurde?“ …
Antwort: „Nein, wir sind davon ausgegangen, dass alles in Ordnung ist.“
Frage: „Lassen Sie uns nachsehen.“ …
Antwort: „Es sieht so aus, als gäbe es einen Fehler bei der Dateneingabe für die Einrichtung während der Programmierung.“
Indem Sie gezielte Fragen stellen, um problemspezifische Daten zu isolieren, KÖNNEN Sie Ihre hartnäckigen Probleme auf ein Minimum reduzieren und jenes Albtraumszenario vermeiden … „ER IST WIEDER DA!“ …
