Strukturieren Sie Ihre Root-Cause-Analysis-Meetings für den Erfolg

Wie produktiv sind die Root-Cause-Analysis-Meetings Ihrer Organisation? Um diese Frage zu beantworten, ziehen Sie bitte die folgenden Fragen in Betracht:

1. Wie oft beginnen Ihre Root-Cause-Meetings damit, objektiv Daten zu sammeln, um das Problem zu beschreiben?

2. Wie oft beginnen Ihre Root-Cause-Meetings mit ausführlichen Diskussionen über mögliche Ursachen und enden damit, dass die Teilnehmenden gehen, um zahlreiche Theorien zu untersuchen?

3. Wie oft führen Ihre Root-Cause-Meetings zu einer wahrscheinlichsten Ursache?

Wenn Sie mit „oft“, „nicht oft“ und „oft“ geantwortet haben, sind Ihre Root-Cause-Meetings wahrscheinlich bereits produktiv – und die Ergebnisse sind der Beweis. Wenn Ihre Antworten hingegen „nicht sehr oft“, „ziemlich oft“ und „selten“ lauteten, lesen Sie bitte weiter, denn der Inhalt dieses Artikels könnte Ihr Denken anregen.

Typischerweise antworten die meisten Menschen auf die Frage, wie viel Zeit sie für diese Art von Meetings einplanen, mit „eine Stunde“. Wenn eine Stunde der durchschnittliche, geplante Zeitrahmen für ein Root-Cause-Meeting ist: Wie sollten diese Meetings strukturiert sein, damit die Teilnehmenden den größtmöglichen Nutzen daraus ziehen? Wie lassen sich diese Meetings am besten organisieren, um zu vermeiden, dass Teilnehmende erneut zusammenkommen und in dieselben Diskussionen zurückkehren müssen, wenn die nächsten Schritte unproduktiv sind? Was ist der beste Ansatz, wenn Diskussionen über Ursachen so ausufernd sind, dass Meetings kaum etwas erreichen und später fortgesetzt werden müssen?

Im Folgenden finden Sie drei häufige Fallstricke bei Root-Cause-Meetings sowie Kepner-Tregoes Empfehlungen, wie Sie diese vermeiden:

Fallstrick Nr. 1: Das Meeting beginnt, und den Teilnehmenden ist nicht klar, welches Problem behandelt wird.

Lösung: Legen Sie gleich zu Beginn des Meetings ein klares Thema fest (oder kommunizieren Sie es allen Stakeholdern im Vorfeld). Das setzt den Rahmen für die Diskussion und macht deutlich, was nicht zum Umfang gehört – und spart so Zeit, die sonst für nicht relevante Themen draufginge.

Erstellen Sie innerhalb des thematischen Rahmens eine Liste der Themen. Wenn es mehrere Probleme gibt, halten Sie sie in einem Dokument fest. Klären Sie die Symptome und richten Sie den Fokus strikt darauf, was beobachtet wird, statt darauf, was theoretisiert wird.

Wenn es ein klar umrissenes Problem gibt, ist der Einsatz des „5-Why“-Ansatzes hilfreich, um sich auf das Kernproblem zu konzentrieren, dessen „Ursache unbekannt“ ist. Wenn Ihr Team sich ausschließlich auf das konkrete Thema fokussiert hat, sollte anschließend noch eine weitere Frage betrachtet werden:

Müssen Sie die Ursache kennen, um wirksame, sinnvolle Maßnahmen zu ergreifen?

Nicht jedes Problem erfordert eine Root-Cause-Analyse. In manchen Fällen reicht eine Umgehungslösung oder eine adaptive Maßnahme aus; dann kann der Rest des Meetings eher zu einer Entscheidungsdiskussion über die beste Methode zur Behebung des Problems werden als zu einer Analyse seiner Diagnose. Wenn das Wissen um die Ursache nicht notwendig ist und Sie das Symptom entweder beheben oder damit leben können, ist es natürlich Zeitverschwendung, weiter über Root-Cause-Analyse zu sprechen.

Fallstrick Nr. 2: Das Meeting setzt sich mit einer ausufernden Diskussion über mögliche Ursachen fort, die sich als Ablenkung erweisen.

Sehr häufig kommen Stakeholder mit einer vorgefassten Vorstellung in diese Meetings, was ihrer Meinung nach passiert. Menschen haben ihre „Lieblingsursachen“ und verfolgen sie mit Leidenschaft. Nachdem das zu lösende Problem geklärt ist, möchten die meisten ihre Ideen einbringen. In gewisser Hinsicht ist es wichtig, etwas Diskussion zuzulassen, denn andernfalls warten die Teilnehmenden nur darauf, selbst zu sprechen, statt anderen aktiv zuzuhören – und die Ergebnisse werden nicht gut sein. Die Diskussion möglicher Ursachen kann jedoch schnell kontraproduktiv werden, wenn sie so umfangreich wird, dass sie das Meeting dominiert und dazu führt, dass Menschen gehen, um auf Basis ihrer Theorien unkoordiniert zu handeln. Zudem sollte Root-Cause-Analyse, wenn Zeit Geld ist, kein Spiel nach dem Motto „Meine Ursache ist besser als deine, und ich beweise es“ sein. Das führt dazu, dass viel Geld ausgegeben wird, häufig viel Zeit verschwendet wird und sich die Umgebung möglicherweise so verändert, dass es noch schwieriger wird, die wahre Ursache zu finden.

Bei wie viel Prozent Ihrer Root-Cause-Meetings spiegelt sich häufig das oben beschriebene Bild wider?

Lösung: Wenn Sie nur eine Stunde für das Meeting eingeplant haben, lassen Sie eine gewisse Diskussion über mögliche Ursachen zu – aber nur so lange, bis die Teilnehmenden alles ausgesprochen haben, was ihnen auf der Seele liegt. Erstellen Sie eine Liste der Theorien, sobald sie genannt werden, damit die Teilnehmenden zufrieden sind, dass ihre Idee notiert wurde. Sobald die Diskussion ins Stocken gerät und es im Raum still wird, stoppen Sie das Gespräch und gehen Sie dazu über, die bekannten Fakten zum Problem zu klären. Halten Sie die Teilnehmenden davon ab, vorschnell zu gehen, um Theorien zu untersuchen. Nur weil eine mögliche Ursache das beobachtete Symptom logisch erklären könnte, heißt das nicht, dass sie tatsächlich die wahre Ursache ist.

Denken Sie nur einmal nach: Wann haben Sie in der Vergangenheit erlebt, dass andere unnötige Maßnahmen ergriffen haben, um Ursachen zu untersuchen, die sich als falsch herausstellten?

Fallstrick Nr. 3: Teams verbringen nicht genug Zeit damit, Fakten zu sammeln, um das Problem zu beschreiben, bevor sie vorschnell auf eine Ursache schließen.

Das muss kein rigoroser Prozess sein – aber bedenken Sie die Alternative. Welche potenziellen Auswirkungen hat es, wenn Sie sich zu Beginn nicht ausreichend Zeit nehmen, um das Problem, das Sie erleben, zu beschreiben?

Wie oben erwähnt, sammeln Menschen aus Leidenschaft für ihre Lieblingsursachen häufig Daten, um zu beweisen, dass ihre Ursache wahrscheinlicher ist als eine andere. Tatsächlich könnte in einer Testumgebung vermutlich jemand verschiedene Experimente erstellen, die zeigen, wie viele Theorien die Art von Symptom auslösen könnten, die beobachtet wird. Was jedoch zuerst verstanden werden muss, sind die tatsächlich vorliegenden Bedingungen.

Lösung: Teams sollten mindestens 15 Minuten darauf verwenden, gut formulierte, präzise Fragen zu erarbeiten, die die bekannten Fakten des Problems spezifizieren und strukturieren. Wenn die richtigen Expertinnen und Experten bereits im Raum sind und die vorliegenden Daten korrekt sind, sollte das nicht viel Zeit in Anspruch nehmen und ist äußerst hilfreich. Sobald die verfügbaren Informationen dokumentiert sind, ist der richtige Zeitpunkt gekommen, mögliche Ursachen zu betrachten – mit dem Ziel, sie anhand der Fakten zu bewerten.

Bei Kepner-Tregoe nutzen wir eine leistungsstarke, bewährte Technik zur Erfassung von Problemdaten, die Teams ermöglicht, falsche Ursachen schnell auszuschließen und mithilfe von Logik eine wahrscheinlichste Ursache abzuleiten. Unsere Erfahrung hat gezeigt, dass dieser Prozess in nur 15 Minuten wirksam sein kann (vorausgesetzt, die von den Teilnehmenden eingebrachten Informationen sind zielführend) – ein Zeitraum, in dem Teams verfügbare Informationen nutzen, um ihre Ursachendiskussionen zu steuern und die nächsten Schritte logisch zu planen.

Das positive Verhalten, das wir fördern möchten: Vermeiden Sie es, falsche mögliche Ursachen zu untersuchen, indem Sie die Fakten des Problems nutzen, um Theorien auszuschließen, die keinen Sinn ergeben. Das Ergebnis sollten ein oder zwei verbleibende Ursachen sein, die auf logischen Annahmen beruhen. Von dort aus können Teams besprechen, welche nächsten Schritte am sinnvollsten sind.

Das negative Verhalten, das wir verhindern möchten: So viele Daten wie irgend möglich zu sammeln und ohne Verständnis dafür, wonach Sie suchen, nach Ursachen zu fischen. Denken Sie nur daran: In den meisten Organisationen finden täglich Hunderte (wenn nicht Tausende) von Veränderungen in ihrer Umgebung statt, und jede einzelne davon als mögliche Ursache zu prüfen, wäre eine enorme Verschwendung von Ressourcen. Eine gute Problembeschreibung kann den Umfang der Informationen, die zur Bestimmung der Ursache bewertet werden müssen, schnell eingrenzen und so potenziell Stunden unnötiger Arbeit sparen.

Wenn Sie das Obige berücksichtigen und es in einen Meeting-Ablauf übertragen, könnte ein produktives Root-Cause-Meeting eher so aussehen:

Root-Cause-Meetings sollten logikgetrieben statt impulsgesteuert sein. Reflexartige Reaktionen auf eine vermeintlich gefundene Ursache helfen selten und machen den Prozess oft unproduktiv – und das Problem schlimmer, insbesondere wenn sie auf Annahmen statt auf Fakten beruhen. Sich die Zeit zu nehmen, das Problem klar zu beschreiben, ist so wichtig; Daten sollten die Annahmen oder Hypothesen stützen – oder aus der Betrachtung ausgeschlossen werden. Letztlich gilt: Wenn Geld für das Testen von Ursachen ausgegeben wird, dann sollte es für diejenigen sein, die erklären, was tatsächlich passiert.