Von Michael Barna, Kepner-Tregoe
Wenn es um Problemlösung geht, sehe ich bei vielen Kunden zwei gängige Techniken im Einsatz (oder beim Versuch des Einsatzes): die „5-Why-Methode“ und „Fischgräten-Diagramme“. Es ist wichtig festzuhalten, dass diese Werkzeuge ihren Platz und Zweck haben. Ebenso wichtig ist es jedoch sicherzustellen, dass Ihr Team sie auf eine Weise einsetzt, die logisch sinnvoll ist und einen Mehrwert bietet. Beide Methoden stehen in einer symbiotischen Beziehung zum Problemanalyse-Prozess von Kepner-Tregoe zur Ermittlung der wahren Ursache. Ich bin der Meinung, dass eine wichtige Erkenntnis aus jedem KT-Workshop nicht darin besteht, wie sich unsere Methode von anderen gängigen Techniken unterscheidet, sondern vielmehr darin, wie sie synergetisch wirken kann.
Der Problemanalyse-Ansatz von KT umfasst vier grundlegende Prozessschritte.
- Schritt 1 besteht darin, das Problem zu beschreiben und Fakten zu sammeln, um sicherzustellen, dass das Problem klar verstanden wird.
- Schritt 2 besteht darin, mögliche Ursachen zu identifizieren, um Theorien zu skizzieren, die gegen die bekannten Fakten geprüft werden können.
- Schritt 3 besteht darin, mögliche Ursachen zu bewerten, um falsche Ursachen auszuschließen und die wahrscheinlichste Ursache für weitere Tests zu identifizieren.
- Schritt 4 besteht darin, die wahre Ursache zu bestätigen, um die Ursache zu beweisen und eventuell verbleibende Wissenslücken zu schließen.
Ein Kernbestandteil von Schritt 1 ist die Erstellung einer Problembeschreibung, die das zu lösende Symptom benennt und sich auf die betroffene Einheit sowie das spezifische Problem konzentriert. Die Formulierung der Problembeschreibung erweist sich manchmal als der anspruchsvollste Aspekt der Problemanalyse, da eine falsche Problembeschreibung die gesamte restliche Analyse aus der Bahn werfen kann. In einigen Fällen sind sich die Beteiligten entweder unsicher über das zu lösende Problem oder uneinig, da sie widersprüchliche Wahrnehmungen des Problems haben. In anderen Fällen ist die Problembeschreibung entweder zu allgemein oder es handelt sich um eine Aussage, deren Ursache bereits bekannt ist.
Um Unklarheiten zu Beginn einer Problemanalyse zu minimieren (und sicherzustellen, dass eine Ursachenanalyse überhaupt eine angemessene Nutzung unserer Zeit und Ressourcen darstellt), müssen wir drei Kontrollfragen stellen:
- Gibt es eine Abweichung? (d. h. eine Abweichung von der erwarteten, normalen Leistung von etwas)
- Ist die Ursache zu 100 % unbekannt?
- Müssen wir die Ursache kennen, um wirksame und sinnvolle Maßnahmen zu ergreifen?
Bei Frage Nr. 2 kommt die 5-Why-Methode ins Spiel. Für diejenigen, die mit diesem Konzept nicht vertraut sind: Es handelt sich um eine Fragetechnik, bei der mehrmals nach dem „Warum“ gefragt wird, um zu einer systemischen Grundursache vorzudringen. Welchen Wert hat jedoch eine Ursachenanalyse, wenn die Beteiligten den Grund bereits kennen, „warum“ etwas passiert? Dies könnte eine enorme Verschwendung von Unternehmenszeit sein, und die Opportunitätskosten des Energieaufwands könnten beträchtlich sein.
Um sicherzustellen, dass die Beteiligten das richtige Problem angehen, und um zu validieren, ob eine Problemanalyse überhaupt ein notwendiger nächster Schritt ist, kann der Einsatz der 5-Why-Technik eine produktive Übung sein. In manchen Fällen müssen Teams vielleicht öfter als nur fünfmal nach dem „Warum“ fragen; in anderen Fällen kann die Anzahl der „Whys“, die benötigt werden, um zum Kern vorzudringen, weniger als fünf Iterationen betragen. Das Ziel dabei ist es, den Punkt zu erreichen, an dem die Teams keine Fortschritte mehr machen und zugeben: „Wir wissen nicht, warum“, oder den Punkt zu erreichen, an dem ein logischer nächster Schritt identifiziert werden kann (wie im folgenden Beispiel). An diesem Punkt endet die Aufgabe der 5-Why-Technik effektiv.
Wenn wir diese 5-Why-Bewertung durchgeführt haben und an den Punkt gelangt sind, an dem wir das „Warum“ nicht vollständig verstehen, würde KT eine dritte Folgefrage stellen, um die nächsten Schritte zu bestätigen: „Müssen wir wissen, warum, um wirksame und sinnvolle Maßnahmen zu ergreifen?“ In manchen Fällen kann die Antwort auf diese Frage ein klares „Nein“ sein. Beispielsweise weiß ein IT-Incident-Management-Team vielleicht nicht genau, warum der Dienst eines Benutzers beeinträchtigt ist, aber um den Dienst wiederherzustellen, müssen sie möglicherweise nur einen schnellen Workaround implementieren, und der Benutzer ist wieder zufrieden. In anderen Situationen ist dies möglicherweise nicht der Fall, und um mit wirksamen Maßnahmen fortzufahren, müssen wir eine systematische Fehlersuche durchführen.
Zusammenfassung:
Die 5-Why-Methode ist eine hervorragende Fragetechnik, die die vielen Ursachen eines Problems untersucht, bis der Punkt der „unbekannten Ursache“ erreicht ist oder festgestellt wird, dass das „Warum“ ohne weitere Analyse nicht vollständig bestätigt werden kann. An diesem Punkt sollte eine Diskussion darüber stattfinden, ob die Kenntnis des „Warum“ zum jetzigen Zeitpunkt geschäftskritisch ist oder ob es sich lohnt, Ressourcen aufzuwenden, um der Frage weiter nachzugehen.
Das Ergebnis eines gründlich abgeschlossenen Schritts 1 der Problemanalyse ist eine faktenbasierte Beschreibung des Problems. Der nächste Schritt besteht darin, diese Problembeschreibung, die bei KT als „Spezifikation“ bezeichnet wird, zu verwenden, um mögliche Ursachen zu identifizieren und anschließend zu testen.
Hier sollte logischerweise das Fischgräten-Diagramm (oder Ishikawa-Diagramm) zum Einsatz kommen.
Ein Fischgräten-Diagramm ist ein Hilfsmittel, das eine visuelle Darstellung möglicher Ursachen für ein Problem bietet. Es kann während der Problemanalyse äußerst nützlich sein, um die Beteiligten dabei zu unterstützen, über mögliche Ursachen nachzudenken, die das Problem logisch erklären könnten. Manchmal benötigt selbst unser Wissen und unsere Erfahrung gewisse Leitplanken, um unser Denken auf dem richtigen Weg zu halten oder einen Fachexperten dazu anzuregen, etwas Bestimmtes in Betracht zu ziehen.
Typischerweise unterteilt ein Fischgräten-Diagramm mögliche Ursachen in verschiedene Kategorien, wie zum Beispiel „Material, Personal, Methoden, Maschinen, Umwelt, Messungen usw.“. Unter Verwendung der Problemspezifikation aus Schritt 1, kombiniert mit der Logik des Fischgräten-Diagramms, können Teams mögliche Ursachen in Bezug auf einige der oben aufgeführten Kategorien untersuchen. Die Verwendung des Fischgräten-Diagramms an diesem Punkt kann den Beteiligten helfen, mögliche Ursachen im Brainstorming zu ermitteln, die angesichts dessen, was sie über das Problem wissen, sinnvoller erscheinen.
Wie viel Prozent Ihrer Meetings zur Ursachenanalyse beginnen jedoch typischerweise mit einem Fischgräten-Diagramm (Ishikawa) oder einer Debatte darüber, was die Beteiligten für die Ursache halten? Wie schnell wollen die Leute das Meeting verlassen, um das zu testen, was sie für die Ursache halten? Wann haben Sie erlebt, dass Mitarbeiter mehrere Ursachen gleichzeitig testen? Wie geht das normalerweise aus?
Es ist sehr verlockend, zu Beginn einer Untersuchung direkt in die Bewertung von Ursachen einzusteigen, aber dies wird kontraproduktiv, wenn Teams dies tun, ohne eine gründliche Beschreibung ihres Problems zu haben. Darüber hinaus kann die gleichzeitige Untersuchung einer Vielzahl von Ursachen viele Änderungen in den Prozess einführen und möglicherweise neue Symptome erzeugen, die das ursprüngliche Ereignis verschleiern könnten.
Der Mehrwert aus der Kombination eines Fischgräten-Diagramms mit der KT-Problemanalyse liegt darin, wie schnell wir viele der irrelevanten „Gräten“ des Diagramms eliminieren können, die das Problem vernünftigerweise nicht erklären können. Das Ausfüllen eines Fischgräten-Diagramms kann zu einem Dutzend oder mehr Gräten führen, die vom Diagramm abzweigen und jeweils eine andere mögliche Ursache darstellen. Vernünftigerweise wird es jedoch nur eine wahre Ursache geben, die aus der Analyse hervorgeht. Um Zeitverschwendung durch das Testen falscher Ursachen zu minimieren und zu verhindern, dass das Problem potenziell verschlimmert wird, lässt die KT-Problemanalyse die Teams jede einzelne „Gräte“ nehmen und die Theorie gegen die Problemdaten testen, indem sie fragen: „WENN dies die Ursache ist, wie erklärt sie dann die Fakten?“ Wenn eine im Diagramm aufgeführte Theorie die Daten nicht erklären kann, wird sie aus der Betrachtung eliminiert. Grundsätzlich wäre die „Gräte“, die die logischsten Annahmen in Bezug auf die Daten aufweist, die wahrscheinlichste Ursache – also die Ursache, bei der es für die Teams am sinnvollsten ist, sie zuerst weiter zu untersuchen.
Zusammenfassung:
Fischgräten-Diagramme haben ihren Platz und ihre Zeit bei der Problemlösung. Seien Sie jedoch vorsichtig damit, sie zum Mittelpunkt der Diskussion zu machen, bevor eine gründliche Problembeschreibung identifiziert wurde. Bei korrekter Anwendung können sie ein wertvolles Werkzeug sein, um logische Ursachen zu identifizieren und sogar eine visuelle Darstellung davon zu liefern, welche Ursachen eliminiert werden können. Damit ein Fischgräten-Diagramm jedoch ohne unnötigen Stress funktioniert, müssen Teams zuerst die Fakten des vorliegenden Problems sammeln, damit sie diese Informationen nutzen können, um mögliche Ursachen auszuschließen, die nicht sinnvoll sind, und den Fokus auf die wenigen zu verengen, die es sind.
