Meine Tochter fragt mich, warum ich keine Zeit zum Spielen mit ihr habe. Meine Antwort - „weil ich gerade zu tun habe“ - stellt sie nicht zufrieden.
Manchmal geht es uns im Beruf genauso. Wir möchten etwas verstehen und werden mit oberflächlichen Antworten abgespeist.
Dagegen gibt es ein Mittel, das jeder Qualitätsmanager kennt: Die 5-Why-Methode. Auf der Suche nach der Ursache eines Problems ketten wir die Frage und Antworten aneinander an, bis wir der Sache auf den Grund gekommen sind.
Das kann dann so aussehen:
Erstes Why:
Warum ist unser Release nicht rechtzeitig fertig geworden?
Weil wir am Ende noch nacharbeiten mussten.
Zweites Why:
Warum mussten wir am Ende noch nacharbeiten?
Weil die Integrationstests fehlgeschlagen sind.
Drittes Why:
Warum sind die Integrationstests fehlgeschlagen?
Weil eine externe Komponente sich anders als erwartet verhielt.
Viertes Why:
Warum verhielt sich eine externe Komponente anders als erwartet?
Weil ihre Implementierung von der Spezifikation abwich.
Fünftes Why:
Warum wich ihre Implementierung von der Spezifikation ab?
Weil der Lieferant diese Komponente vor Freigabe nicht ausreichend getestet hatte.
So gesehen sind die Five Why‘s ein Lokalisationsinstrument, ein Detektor zur Identifikation von Problemursachen (Root Causes). Mit jeder Frage graben wir uns eine Schicht tiefer, mit jeder Frage präzisieren wir unser Verständnis des Problems, kreisen es ein.
Dass die Five Why‘s ausgerechnet fünf Fragen beinhalten (und nicht drei oder zehn) ist nun nicht gerade exakte Wissenschaft, sondern Erfahrung. Wie das Beispiel oben zeigt, schaffen fünf Fragen eine recht gute Eingrenzung der Ursache.
Sicher könnten wir noch weiter fragen, die Ursachenforschung auf eine andere Ebene heben: Im oben genannten Beispiel könnte der Lieferant der externen Komponente selber die Five Why‘s anwenden und hinterfragen, warum er seine Komponente vor seiner Freigabe nicht ausreichend getestet hat.
Der Vorwurf der Reduktionismus
Dass die 5 Why’s auch ihre Grenzen haben, zeigt Barry O‘Reilly in seinem Blog. Sein Argument: Die Suche nach der Ursache führt zu einer Verengung des Verständnisses, die komplexen Problemen nicht gerecht wird:
When problems occur we hunt for a single root cause, that one broken piece or person to hold accountable. Our analyses of complex system breakdowns remains linear, componential and reductive. In short, it’s inhumane.
Als Beispiel für seine These führt O‘Reilly die Reaktorkatastrophe von Tschernobyl von 1986 an. Die offizielle Untersuchung der Katastrophe nannte als Fehlerursache fehlende Kompetenzen und Erfahrungen der verantwortlichen Betreiber. Spätere Untersuchungen durch die internationale Atomenergiebehörde, nach dem Fall des Eisernen Vorhangs, deckten eine Reihe weiterer Ursachen auf, darunter Fehler in der Konstruktion des Reaktors.
Nun ließe sich O‘Reilly‘s Beispiel damit entkräften, dass die offizielle Untersuchung der Reaktorkatastrophe von Tschernobyl mit Sicherheit auch politisch motiviert war: Weil die Sowjetunion ihre Schwächen gegenüber dem Westen verbergen wollte, durften Konstruktionsfehler im offiziellen Bericht nicht erwähnt werden.
Doch unabhängig von diesen historischen Variablen lässt sich sagen: Die 5 Why‘s mit ihrer Fixierung auf die Fehlerursache können durchaus reduktionistisch wirken. Im oben genannten Beispiel starten wir mit einem verspäteten Release und enden mit dem Freigabeprozess eines Lieferanten. Können wir sicher sein, dass mit Lösung des Freigabeprozesses für diese eine Komponente unsere Releases nicht mehr verzögert sein werden? Sicher nicht.
Fazit
So gesehen helfen uns die 5 Why‘s bei der Identifikation und gründlichen Aufklärung von spezifischen Problemursachen. In weniger komplexen Situationen mag das vollkommen ausreichen: Bleibt mein Auto auf der Straße stehen, wird ein Mechaniker sich von einer Ursache zur nächsten vorarbeiten, bis er die Fehlerursache gefunden hat.
Bei komplexen Problemen, in denen vielfältige, voneinander abhängige Ursachen am Werk sind, werden die Five Why‘s nicht ausreichen, um eine Fehlerwiederholung zu verhindern. Hier kann es helfen, den Kontext des Problems aufzuzeichnen. Das Ishikawa-Diagramm (auch als Fischgräten-Diagramm bekannt) hilft dabei, die Einflussfaktoren (Mensch, Maschine, Material, Umwelt…) zu beschreiben, bevor Ursachenanalysen gestartet werden.
Eine Warnung zum Schluss: In meiner Coaching-Ausbildung wurde mir eingetrichtert, Warum-Fragen zu vermeiden. Grund: In menschlichen Beziehungen können Warum-Fragen schnell einen vorwurfsvollen Ton bekommen und unser Gegenüber unter Rechtfertigungsdruck setzen. Deshalb ist es zur erfolgreichen Anwendung der 5 Why-Methode wichtig, dass die Beziehungsebene geklärt ist. Wenn persönliche Konflikte vorhanden sind, können die 5-Whys in gegenseitigen Vorwürfen enden, die niemanden weiter bringen.
Erstes Foto von Streetwindy von Pexels
Zweites Foto von Vlad Chețan von Pexels