Um was geht es?
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.
Dieses Zitat von Goethe können Sie deshalb auch sehr gut auf den Problemlösungsprozess übertragen.
Was sind die Ursachen für eine solche Situation?
Es sind im wesentlichen zwei Dinge, die in einer Situation 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 den 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.
Was sind die Folgen einer “schlechten” Problembeschreibung?
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.
Wie können Sie es besser machen?
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.
Was gehört in eine “ordentliche” Problembeschreibung?
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
Und so könnte eine aussagekräftige Problemdefinition aussehen
Ü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
