Problembeschreibung bei Root Cause Analysen

Die Problembeschreibung bei Root Cause Analysen steht bekanntlich am Anfang jedes Problemlösungsprozesses. Egal ob dieser mit der A3-Methode, dem 8D-Report oder dem Six Sigma DMAIC-Prozess durchgeführt wird.

Nicht allen Problemlösern ist jedoch bewusst, dass eine gute Problembeschreibung  eine wichtige Voraussetzung für eine effektive und effiziente Problemlösung ist.

Denn wenn bereits am Anfang einer Root Cause Analyse die falschen Prioritäten gesetzt werden, kann das Ganze schnell in einer Sackgasse enden. Und alle Mühe war umsonst, weil man wieder von vorne anfangen muss.

Das nebenstehende Zitat von Goethe können Sie deshalb auch sehr gut auf den Problemlösungsprozess übertragen.

Es sind im wesentlichen zwei Dinge, die zu Beginn einer Root Cause Analyse schief laufen können.

Zum einen neigen Menschen dazu, sich nach einem unerwünschten Vorfall sofort Gedanken über die möglichen Ursachen zu machen – und bezeichnen diese Ursache als das eigentliche Problem.

Hinzukommt, Dass sich jeder seine persöniche Meinung gebildet hat, was denn das “Problem” ist.

Entweder sind es unterschiedliche Informationen, die jeder erhalten oder sich besorgt hat. Oder es sind die persönlichen Erfahrungen aus ähnlichen Vorfällen, die einfach auf die neue Situation übertragen wird. Nach dem Motto: “Wenn der Müller schon nicht beim Fahren des Staplers aufgepasst hat, dann war es jetzt genau so. Und deshlab ist der Stapler umgekippt.”

Wenn sich deshalb jetzt zum ersten Mal die Mitarbeiter für die Untersuchung eines unerwünschten Vorfalls treffen, hat höchstwahrscheinlich jeder zunächst eine eigene Meinung und Sichtweise, was denn das “Problem” ist.

Oder ein anderes Phänomen habe ich oft festgestellt, dass um den heißen Brei herumgeredet wird, der „schwarze Peter“ wird herumgereicht oder über Probleme in anderen Bereichen gesprochen wird. Vielleicht auch mit dem Hintergedanken, zunächst von den eigenen Problemen abzulenken.

Folgendes kann Ihnen passieren, wenn Sie am Anfang nicht strukturiert vorgehen und genau festlegen, was das Problem bei dem jeweiligen Vorfall ist:

Sie laufen Gefahr, sich mit Dingen zu beschäftigen, die mit dem eigentlichen Problem nichts zu tun haben.
Weil z.B. jeder, der an der Problemlösung beteiligt ist, seine eigene Meinung hat, was denn das eigentliche Problem ist.

Sie entmutigen diejenigen, die sich in der Diskussion um die Problemdefinition von anderen überfahren fühlen, engagiert an der weiteren Problemlösung mitzuarbeiten.
Weil andere sich besser und geschickter ausdrücken können, eigene Probleme geschickt kaschieren, den „schwarzen Peter“ mit fadenscheinigen Argumenten anderen zuschieben oder einfach kommunikativ dominanter auftreten.

Sie brauchen letztendlich sehr viel Zeit, eine gemeinsame Basis für die weitere Problemlösung.
Weil alle erst mal Ihre persönliche Meinung zu dem Vorfall präsentieren wollen – mit dem Ansinnen, dass sie das „wahre“ Problem erkannt haben.

Wenn Sie jetzt also nicht aufpassen, kann es sehr schnell zu einer unnötigen Diskussion kommen. Bei denen das eigentliche Problem zerredet wird oder heftig darüber diskutiert, an welchem “Problem” zuerst gearbeitet werden sollte.

Und diesen zeitlichen Aufwand können Sie sich eigentlich sparen.

Schauen wir uns das Ganze an einem Beispiel an:

Angenommen:

Sie werden auf der Autobahn mit 120 km/h in eine Baustelle mit einer Geschwindigkeitsbegrenzung auf 60 km/h und werden geblitzt.

Wenn Sie den Vorfall jetzt in einem Team schildern, das sich mit der systematischen Root Cause Analyse noch nicht so gut auskennt, und fragen, was das Problem ist, werden aus Erfahrung mit hoher Wahrscheinlichkeit folgende Antworten kommen:

• Zu schnell gefahren!
• Die Straße ist so breit!
• Nicht aufgepasst!
• Pech gehabt!
• Stress!
• …

Und schon entsteht eine Diskussion darüber, wer recht hat oder an welchem “Problem” gearbeitet werden muss.

Diese Diskussionen, in denen das wahre Problem zerredet wird, können Sie sich zukünftig sparen, wenn Sie die Problembeschreibung wie folgt formulieren.

Aus meiner Erfahrung sollte eine Problembeschreibung  mindestens folgende Fragen beantworten:

Die Frage nach dem „wer“ würde ich ganz weglassen, weil Namen der Betroffenen in einem Problemlösungsprozess wegen der Gefahr von Schuldzuweisungen nichts zu suchen haben.

Mit der Frage „Warum?“ sollte nicht bereits nach den Ursachen gefragt werden. Damit sollten Sie sich bis zur nächsten Phase „Ursachenanalyse“ gedulden. Nein, hier geht es um die Frage, warum das unerwünschte Ereignis überhaupt ein Problem ist. Dazu beschreiben Sie am besten die Auswirkung des Vorfalls auf die Unternehmensziele. D.h., welche Auswirkungen hat der Vorfall auf die Arbeitssicherheit, Qualität, Kundenzufriedenheit, Termineinhaltung, Umweltschutz, Betriebsmittel, Mitarbeiterzufriedenheit?

Und das möglichst mit Kosten, Zahlen, Daten und Fakten. Diese Informationen sind Tatsachen und nicht wie Meinungen diskutierbar. Und die Sprache „Euro“ versteht jeder Beteiligte. Kosten sind deshalb  die gemeinsame Klammer für den Problemlösungsprozess. Besonders, wenn die Ursachen für das Problem auf mehrere Bereiche verteilt sind.

Das „Hauptproblem“ im Beispiel wäre also aus meiner Sicht:

Bußgeld 240 €, 2 Punkte in Flensburg und 2 Monate Fahrverbot

Übrigens, der Fahrer wurde in diesem Jahr schon einmal geblitzt und musste ein Bußgeld von 60 € zahlen.

Eine Problembeschreibung besteht also aus zwei Abschnitten:

Abschnitt 1 enthält alle Fakten (und anfangs auch Verutungen), die zu dem Hauptproblem in Abschnitt 2 geführt haben.

In Abschnitt 2 werden die Auswirkungen des Vorfalls auf die einzelnen Ziele des Unternehmen beschrieben. Das ist das Hauptproblem bzw. der Fokus, auf den sich die Root Cause Analyse konzentrieren sollte. Indem mit dem Wissen über die wahren Ursachen wirksame und nachhaltige Verbesserungen entwicklet werden, die eine Wiederholung des Vorfalls verhindern sollen.

Aus der Praxis für die Praxis

Wenn Sie mit der Problembeschreibung ruck zuck fertig sein wollen, empfehle ich folgende Vorgenhsweise:

Bevor Sie sich zum ersten Mal mit Ihrem Untersuchungsteam treffen, ermitteln Sie die (möglichen) Auswirkungen des Vorfalls auf das Unternehmen (–> Abschnitt 2 der Problembeschreibung)

1. Sammeln Sie beim ersten Treffen mit Ihrem Team alle Informationen, die den Vorfall so präzise wie möglich beschreiben.
2. Kennzeichnen Sie alle Informationen, ob es sich um Fakten oder Vermutungen handelt.
3. Vermeiden Sie jegliche Diskussionen über Personen, die an dem Vorfall beteilgt waren.
4. Lassen Sie sich nicht auf Forderungen von einzelnen Teammitgliedern ein, wenn es um Wichtigkeiten und Dringlichkeiten, richtig oder falschen Angaben geht. Sammeln Sie erst mal alles und schreiben es in den Abschnitt 1 der Problembeschreibung.
5. Am Ende des Tages sollten alle Beteiligten ….
   • … die gleiche Sichtweise haben, was passiert ist – und was nicht.
   • … dei Auswirkungen des Problems auf die Unternehmensziele kennen.
   • … akzeptieren, worauf sich die anschließende Ursachenanalyse fokussieren soll – und auf was nicht

Am Ende des Tages sollten alle Beteiligten ….

… die gleiche Sichtweise haben, was passiert ist – und was nicht.

… dei Auswirkungen des Problems auf die Unternehmensziele kennen.

… akzeptieren, worauf sich die anschließende Ursachenanalyse fokussieren soll – und auf was nicht