Von Michael Barna, Kepner-Tregoe
Warum sträuben sich Menschen dagegen, eine Root Cause Analysis durchzuführen? „Zu zeitaufwendig!“ „Zu teuer!“ „Zu schwierig!“
Workarounds oder Vermutungen reichen manchmal aus – aber in einer Welt von Operational Excellence, Six-Sigma-Präzision, Lean-Workflows und sich schnell verändernden Hightech-Grenzbereichen ist Root-Cause-Analysis-Expertise entscheidend, um wettbewerbsfähig und profitabel zu bleiben.
Wir kommen häufig in Organisationen, in denen Mitarbeitende gelernt haben, klassische Tools für Root Cause Analysis (RCA) zu nutzen – insbesondere die Five Whys und Fishbone-(Ishikawa-)Diagramme –, diese aber als unzureichend empfinden, um die Ursache schwieriger Probleme zu finden. Die KT Problemanalyse bietet einen Prozess, der sich bei der Durchführung von RCAs für komplexe Probleme als wirksam erwiesen hat. Häufig lassen sich KT Problemanalyse, Five Whys und Fishbone in unterschiedlichen Kombinationen einsetzen, um den RCA-Prozess zu verbessern. Entscheidend ist, die richtigen RCA-Tools effizient zu nutzen, um eine präzise Lösung schneller zu erreichen.
Hier sind zwei Hacks, um RCA zu verbessern, indem Sie Methoden kombinieren und so diesen Prozess optimieren.
1. Stellen Sie sicher, dass es ein Problem gibt, das gelöst werden muss
Bevor Sie ein Fishbone-Diagramm (siehe unten) erstellen, benötigen Sie eine Problemformulierung. Aber was, wenn Sie nicht die richtige Problemformulierung haben oder tatsächlich gar keine Ursache finden müssen? Eine Problemformulierung benennt das zu lösende Symptom – ausgehend von der Einheit, bei der das Problem auftritt, und dem konkreten Problem, das sie hat. Es ist nicht ungewöhnlich, dass Problemlösende unterschiedliche Wahrnehmungen des Problems haben. In anderen Fällen ist die Problemformulierung entweder zu allgemein oder es handelt sich um eine Aussage, bei der die Ursache bereits bekannt ist.
Um Verwirrung beim Start einer Root Cause Analysis zu minimieren und sicherzustellen, dass dies ein angemessener Einsatz von Zeit und Ressourcen ist, nutzen Sie diesen einfachen Hack.
Es gibt drei Gatekeeper-Fragen, die Sie stellen müssen:
- Gibt es eine Abweichung? (d. h. eine Veränderung der erwarteten, normalen Leistung von etwas)
- Ist die Ursache zu 100 % unbekannt?
- Müssen wir die Ursache kennen, um wirksame, sinnvolle Maßnahmen zu ergreifen?
Wenn die Antwort auf eine dieser Fragen „Nein“ lautet, ist RCA nicht der beste Weg nach vorn: Es gibt bessere Möglichkeiten, Zeit und Ressourcen einzusetzen.
Viele Situationen sind keine Abweichungen und benötigen keine RCA. Ein Abweichungsproblem liegt vor, wenn etwas nicht mehr so funktioniert wie in der Vergangenheit. Es gab eine Abweichung in der Leistung, und wir müssen die Ursache kennen, um sie zu beheben. Das kann sich auf die Leistung eines Objekts beziehen, z. B. einer Maschine, eines IT-Systems oder einer Person.
Die Durchführung einer RCA dient dazu, die Ursache einer Abweichung zu identifizieren. Wenn Sie verstehen, dass unterschiedliche Problemarten unterschiedliche Methoden und Techniken erfordern, können Sie Ihre Ressourcen auf Abweichungsprobleme fokussieren, während Variations-, Effizienz- und Innovationsprobleme mit anderen Tools und Methoden besser adressiert werden. (Siehe: Was ist passiert? Unterschiedliche Problemarten erfordern unterschiedliche Ansätze )
Um schnell festzustellen, ob die Ursache unbekannt ist, können die Five Whys helfen. Die Five Whys sind eine iterative RCA-Technik, mit der man schnell zur Ursache gelangt. Bevor Sie eine komplexere RCA verfolgen, lohnt es sich, die Five Whys zu nutzen, um zu prüfen, ob die Ursache tatsächlich unbekannt ist. Indem wir Warum fragen, bis die Antwort lautet: Ich weiß es nicht, stellen wir sicher, dass die Ursache unbekannt ist, und gewinnen Erkenntnisse, die die Beschreibung des Problems verbessern.
Wir müssen außerdem fragen, ob wir die Ursache kennen müssen. Manchmal reicht ein Workaround aus. Ein Workaround kann eine bessere Option sein, als Zeit in die Ursachenfindung zu investieren – etwa wenn eine Maschine, die ohnehin in Kürze ersetzt werden soll, ein Problem hat.
Die Gatekeeper-Fragen öffnen die Tür für RCA. Beachten Sie, wie die Aussage „Filter Nummer eins verliert Öl“ eine Verbesserung gegenüber dem zunächst beobachteten Problem „Öl ist auf dem Boden“ ist. Zu „Filter Nummer eins verliert Öl“ könnten wir mit den 5 Whys gelangen, ausgehend von der ersten Beobachtung: Öl ist auf dem Boden … warum? … Weil Filter Nummer eins Öl verliert … warum? … Weiß nicht … Müssen wir die Ursache kennen, um das zu beheben? … Ja.
Hack #1: Nutzen Sie die drei Gatekeeper-Fragen von KT, bevor Sie RCA verfolgen. Das verhindert verschwendete Zeit und ermöglicht, andere Problemarten auf effizientere Weise zu bearbeiten.
2. Beschreiben Sie zuerst das Problem
Allzu oft springen Teams, die gemeinsam die Ursache finden wollen, aufgrund liebgewonnener Theorien, die möglicherweise nicht zutreffen, direkt zur Ursache. Statt alle potenziellen Ursachen in einem Fishbone-Diagramm aufzulisten und zu kategorisieren – warum nicht einfach die Ursachen testen, die einige Teammitglieder bevorzugen? Die Antwort: Zu oft ist dieses Vorpreschen und Testen auf Ursachen verfrüht und wird zu einem großen, teuren Zeitfresser.
Um dem vorschnellen Springen zur Ursache entgegenzuwirken, ist es besser, einen Schritt zurückzutreten und das Problem zuerst präzise zu beschreiben, bevor Sie das Fishbone-Diagramm zur Ursachenidentifikation nutzen. Wenn Sie das tatsächliche Problem von Anfang an beschreiben, können Sie einige Lieblingsursachen ausschließen und die Ursachen im Fishbone-Diagramm besser fokussieren. Eine präzise Problembeschreibung hilft Problemlösenden, die im Fishbone-Diagramm gesammelten Ursachen zu bewerten, indem sie deren Gültigkeit logisch gegen die bekannten Fakten testen – so lassen sich ganze Kategorien von Theorien eliminieren, die die Daten nicht erklären.
Wenn wir zum Beispiel wissen, dass der Ölfilter Nummer eins Öl verliert, der Ölfilter Nummer zwei dieses Problem aber offenbar nicht hat, können wir jede vorgeschlagene Fishbone-Theorie testen, indem wir fragen: „Wenn das die Ursache ist, wie erklärt sie dann die Tatsache, dass nur Filter Nr. 1 leckt, während Filter Nr. 2 in Ordnung ist?“ Wenn die Logik besagt, dass Filter Nr. 2 bei dieser Theorie ebenfalls betroffen sein müsste, dann lohnt es sich nicht, das weiter zu untersuchen, und wir können diesen „Knochen“ von der Liste streichen. Ein Fishbone zu füllen kann ein umfangreiches Ratespiel sein. Eine belastbare, strukturierte Problembeschreibung minimiert das Risiko, verschwenderische Maßnahmen zu ergreifen, indem sie Vermutungen hinterfragt und prüft, was vor dem Gericht der Fakten Bestand hat – und was nicht.
Hack #2: Bevor Sie beginnen, Ursachen zu identifizieren – oder noch schlimmer: bevor Sie vorschnell zur Ursache springen und testen –, beschreiben Sie das Problem auf Basis relevanter Daten.
Troubleshooting-Teams mit guten RCA-Fähigkeiten nehmen sich die Zeit, ein Problem zu verstehen, bevor sie versuchen, es zu lösen. Das beginnt mit Hack #1: sicherzustellen, dass es sich um ein Abweichungsproblem handelt, das gelöst werden muss, bevor RCA eingesetzt wird, und Hack #2: das Problem anhand verfügbarer Daten in konkreten Begriffen zu beschreiben.
Über Kepner-Tregoe
Seit mehr als sechs Jahrzehnten befähigt Kepner-Tregoe Organisationen mit einem bewährten, strukturierten Ansatz zur Problemlösung. Als führend in der Problemlösung hat KT Tausenden von Organisationen geholfen, Millionen von Problemen durch effektivere Root Cause Analysis sowie bessere Entscheidungsfähigkeiten zu lösen. Durch unsere einzigartige Kombination aus Training und Beratung erzielen unsere Kunden höhere Effizienz, bessere Qualität und größere Kundenzufriedenheit – bei gleichzeitiger Senkung ihrer Kosten.
