Blog

Kontinuierliche Qualitätsverbesserung durch Root Cause Analysis (RCA)

Xebia
by  Xebia
09 Oct, 2019
Xebia Background Header Wave

Jede Organisation strebt danach, ihre Qualität zu verbessern: Sei es die Produkt-Qualität, sei es die Qualität der internen Abläufe und Arbeitsweisen. Sicher, heute ist man sich immer mehr dessen bewusst, dass durch die immer kürzer werdende Time-To-Market ein erheblicher Konkurrenzdruck entsteht. Dies erzeugt gewisse Erwartungen auf der Kundenseite die – will man als Organisation weiterhin erfolgreich sein – erfüllt werden müssen. Das bedeutet für die Organisation nichts anderes, als ein verstärktes Augenmerk auf Qualität und Geschwindigkeit zu legen.

Qualität bedeutet aber nicht, nur das zu machen, was geschäftlichen Erfolg verspricht. Wichtig ist, vor allem auch, die Faktoren zu beseitigen, die nicht wesentlich zum Erfolg beitragen. Das bedeutet, dass man die Faktoren identifizieren sollte, die «Waste» (Verschwendung) beinhalten. Es ergibt keinen Sinn, in etwas besser zu werden, das nicht zum Erfolg beiträgt.
Wenn ein Faktor einen «Value» beinhaltet, bedeutet das allerdings nicht zwangsläufig, dass es keine Probleme mit diesem Faktor gibt. Vielleicht sind die eventuell existierenden Probleme noch nicht in Erscheinung getreten. Ein Faktor hingegen, der «Waste» beinhaltet, muss nicht unbedingt ein Problem darstellen. Probleme sind also Entitäten die nicht unbedingt mit «Value» und «Waste» gleichzusetzen sind die aber trotzdem gelöst werden müssen.

Kontinuierliche Qualitätssteigerung beinhaltet also:

  • Identifizieren von Faktoren die einen «Value» beinhalten, und diese fördern
  • Identifizieren von Faktoren die einen «Waste» beinhalten, und diese minimieren
  • Probleme identifizieren, benennen, und lösen

«Value» und «Waste» habe ich ausgiebig im Blog «Value Driven Testing: Ein Lean Testing Ansatz» behandelt (Value Driven Testing: Ein Lean Testing Ansatz). Im nachfolgenden Beitrag möchte ich deshalb näher darauf eingehen, Probleme zu identifizieren, benennen, und zu lösen. Hierbei sollte beachtet werden, dass die Root Cause Analysis ein wesentlicher Bestandteil des Lean Testing Frameworks «TAKT» ist (siehe Blog «Ein Lean Testing Ansatz»).

Das Problem mit den Problemen

Probleme stellen Hindernisse dar, die überwunden oder umgangen werden müssen, um von einer unbefriedigenden Ausgangssituation in eine befriedigendere Zielsituation zu gelangen. Um ein Problem lösen zu können, muss man es zuerst erkennen. Dies setzt Offenheit gegenüber Fehlern und Fehl-Konstrukten voraus. Es geht dabei nicht um „Finger Pointing“, um einen Schuldigen zu finden, sondern um die Aufdeckung von Fehlern, die als Startpunkt für Verbesserungen dienen. Da man sich ohne eine Offenheit gegenüber Fehlern nur schwierig verbessern kann, sollten Fehler als Chance begrüsst werden. Das bedeutet, dass eine etablierte Fehlerkultur ein wichtiger Schritt zur Verbesserung der Qualität ist.

Schauen wir uns folgendes Problem an:

Ein kritischer Defect wird erst vom Kunden in der Produktion gefunden.

Sehr häufig verfällt jeder in der Organisation sofort in einen «Korrigier-Modus»: Fehler lokalisieren, Fehler beheben, Fehlernachtest durchführen und die Korrektur an den Kunden ausliefern. Mehr wird leider nicht gemacht. Aufgrund des Zeitdrucks und fehlender, systematischer Problemlösungstechniken werden dabei nicht selten nur die Symptome des Problems beseitigt. Die eigentliche Ursache des Problems bleibt weiterhin bestehen, mit der Folge, dass die gleiche oder eine ähnliche Problemstellung nach einiger Zeit wieder auftritt. Damit die Qualität sich aber langfristig verbessern kann (Kontinuierliche Qualitätsverbesserung) sollte man jetzt auch eine Root Cause Analysis (RCA) durchführen, auch bekannt als Ursachenanalyse.

Um eine RCA erfolgreich durchzuführen, könnte man 3 Techniken einsetzen:

  • 5W-Methode
  • Ishikawa Analyse
  • Reverse Engineering Methode

Diese 3 Methoden können grundsätzlich unabhängig voneinander eingesetzt werden. Die Reverse Engineering Methode ist ein von mir entwickeltes Vorgehen, dass man aber unbedingt in Kombination mit der 5W-Methode oder Ishikawa Analyse einsetzen sollte. Und zwar deswegen, weil bei sowohl 5W als auch Ishikawa ein sehr wichtiger Aspekt fehlt, darüber später mehr.

5W-Methode – warum, warum, warum...

Die Basis-Methode für eine RCA, ist die 5W-Methode. Das «W» steht dabei für «warum?» oder «wieso?» (im Englischen: «why?»).

Kennzeichnend für die 5W-Methode ist:

  • Durch gezielte Warum/Wieso-Fragen, die Ursache für einen Fehler oder ein Problem zu bestimmen.
  • Die Anzahl der Nachfragen ist dabei nicht auf fünf begrenzt.
  • Wichtig ist, so lange nachzuhaken, bis die Ursache eindeutig identifiziert und nicht mehr weiter aufteilbar ist.

Der Name 5W-Methode kommt daher, dass erfahrungsgemäss bereits die fünfte Warum-Frage den Fragenden zur eigentlichen Ursache (Root Cause) bringt.

Es ist wichtig, diese letzte Ebene zu erreichen, da sich nur hier wirksame Massnahmen definieren lassen. Abhängig vom Problem oder Fehler, kann es aber sein, dass schon nach drei W-Fragen die Ursache gefunden wird. Bei komplexeren Problemen können andererseits bedeutend mehr als nur 5 Fragen benötigt werden.
Zur Überprüfung, ob der wahre Grund (Root Cause) tatsächlich gefunden worden ist, sollte man die Antwort auf die letzte Frage und die Problemdefinition umkehren. Wenn der Umkehrschluss logisch erscheint und somit funktioniert, ist die Wahrscheinlichkeit sehr hoch, dass man am Ende der Kausalkette angelangt ist.

Ishikawa Analyse – der Fisch stinkt vom Kopf her

Die 5W-Methode birgt die Gefahr, dass mehrere Ursachen die eventuell zusammenhängen, vernachlässigt werden. Die 5W-Methode zielt immer nur auf genau eine Ursache für eine Problemstellung ab. Eine wirkungsvolle Ursache-Analyse-Technik, die solche Mehrfachgründe berücksichtigt, ist das Ishikawa-Diagramm (Fischgrät- bzw. Fishbone-Diagramm). Es ermöglicht die Darstellung mehrerer Haupt- und Nebenursachen, die zur Ursache-Analyse beitragen. Grundsätzlich geht es darum, herauszufinden, welche Ursachen zu dem Problem beitragen. Sobald diese Ursachen identifiziert sind, sind die möglichen Lösungsansätze relativ einfach zu eruieren. Im Gegensatz zur 5W-Methode, können mit dieser Methode mehrere Ursachen ermittelt werden. Man legt sich also nicht à priori fest auf nur eine mögliche Ursache.

Bei der Anwendung des Ishikawa Diagramms, werden 7 Bereiche definiert, die möglicherweise als Ursache in Frage kommen. Diese Bereiche sind auch bekannt als die 7M: Menschen, Maschinen, Material, Methoden, Mitwelt/Milieu, Messung und Management. In diesem Zusammenhang werden auch öfters die 8M erwähnt. Hier wird Money als 8. eigenständiges Element hinzugenommen. Dies würde ich aber nicht empfehlen, da es möglich ist, alle Probleme auf (fehlendes) Geld zurückzuführen. Das ist nicht dienlich bei der Suche nach den wirklichen Ursachen. So sollte man auch sehr vorsichtig sein mit dem siebten «M»: Management. Auch hier besteht die Gefahr, alle Probleme auf das Management abschieben zu wollen.

<img class="alignnone size-medium" src="

2019/10/Isikawa2_1-1.jpg" width="584" height="223" />

8 Schritte zur Ishikawa Analyse

  • Schritt 1: Problemdefinition

Wie auch bei der 5W-Methode ist es wichtig, das Problem korrekt und umfassend zu beschreiben. Eine fehlerhafte Problembeschreibung wird unweigerlich zu einer falschen Kausalkette und damit zu einer unwirksamen Lösungsmassnahme führen.

  • Schritt 2: Auswahl

Anschliessend sollte man analysieren, welches der 7M auf keinen Fall als mögliche Ursache-Kategorie in Frage kommt, oder welches man absolut nicht in der Analyse einbeziehen möchte. Die Ursache-Kategorien sollten also gewählt werden. Ich empfehle dabei sehr zurückhaltend vorzugehen. Beim von vornhinein Ausschliessen von einem oder mehreren Ms, besteht die Gefahr, dass mögliche valide Ursachen nicht einmal in Betracht gezogen werden. Es ist deshalb ratsam alle 7M in der Analyse einzubeziehen. Wenn wichtige Bereiche fehlen, die nicht in einer der 7M Kategorien eingeteilt werden können, sollten diese als eigene Ursache-Kategorien hinzugenommen werden.

  • Schritt 3: Darstellung

Alle möglichen Ursache-Kategorien werden jetzt in einem sogenannten Fischgräte-Modell dargestellt. Hierzu könnte man aber auch ein Mindmap einsetzen.

  • Schritt 4: Gruppen-Zusammenstellug

Nun wird eine Gruppe von Mitarbeitern zusammengestellt, die dazu beitragen kann mögliche Ursachen zu eruieren. Hier ist es wichtig auf die richtige Zusammenstellung der Gruppe zu achten. Eine ausgewogene Gruppe bestehend aus Management, Entwicklung, Business Analysten und Testern, wird zu einem besseren Resultat kommen, als eine einseitig zusammengestellte Gruppe.

  • Schritt 5: Ursachen-Sammlung

Jeder Mitarbeiter versucht jetzt mögliche Ursachen zu finden, und platziert diese in den entsprechenden Zweigen: den M-Kategorien.

  • Schritt 6: Kausal-Ketten-Ermittlung

Jetzt wird für jede gefundene Ursache die 5W-Methode angewendet. Bei jeder auf dem Fischgrat platzierten Ursache fragt man solange «warum», bis die eigentliche Ursache (der Wirkungszusammenhang) gefunden wird.

Bild Ishikawa Ausgefüllt

  • Schritt 7: Ursachen-Festlegung

Es geht jetzt darum, eine Auswahl von Szenarien zu treffen, die am wahrscheinlichsten sind. Also die Szenarien von Ursachen mit ihrer Kausalkette die am wahrscheinlichsten zur Root Cause des Problems führen. Eine Auswahl könnte man treffen, indem jeder aus der Gruppe Klebepunkte auf das Szenario platziert, das aus seiner Sicht am wahrscheinlichsten ist. Das oder die Szenarien, mit den meisten Punkten wird oder werden als Ursache(n) des Problems akzeptiert.

  • Schritt 8: Lösungsmassnahme

Zum Schluss müssen für die gewählten Ursachen Lösungsmassnahmen definiert und umgesetzt werden. Nach einer gewissen Zeit, sollten die getroffenen Massnahmen auf ihre Wirksamkeit überprüft werden. Wenn die Wirksamkeit ausbleibt, hat man womöglich eine falsche Ursache ermittelt.

Die Ishikawa-Methode hat den Vorteil, dass die Resultate bezüglich einer RCA präziser sind als bei der 5W-Methode. Gerade deswegen, weil mehrere eventuell zusammenhängende Root-Causes ermittelt werden. Diese Methode ist aber bedeutend formalisierter als die 5W-Methode. Das birgt die Gefahr, dass der Aufwand dementsprechend auch bedeutend höher ist. Hier muss zwischen «höherem Aufwand» vs. «Finden von eventuell mehrerer Ursachen» abgewogen werden.

Reverse Engineering Methode (REM)

Sowohl die Ishikawa Analyse als auch die 5W-Methode zielen nur darauf ab die Ursachen eines Problems zu finden und haben das Bestreben eine Lösung zu implementieren, damit das Problem in der Zukunft nicht mehr auftaucht. Das bedeutet, dass diese beide Methoden nur zukunftsorientiert sind.
Die Frage: «Was hätten wir vorher konkret machen müssen, damit das Problem nicht aufgetaucht wäre?», wird aber nicht beantwortet. Hier kommt die REM-Methode ins Spiel.

Gehen wir von folgender Problemstellung aus:

Wieso ist Defect X in der Produktion aufgetaucht?

Mit der 5W Methode und/oder der Ishikawa Analyse können jetzt folgende Root Causes gefunden werden:

  • Schlecht formulierte User Story
  • Keine User Story vorhanden
  • Ein spezifischer Testfall wurde nicht kreiert
  • Zeitdruck / zu wenig Zeit vorhanden
  • Zu wenige Tester
  • Falsche Priorisierung
  • Betreffender Defekt wurde vergessen zu korrigieren
  • Kenntnislücken beim Tester
  • Testdaten
  • Testumgebung

Für die festgelegten Root Cause muss jetzt eine Lösungsmassnahme implementiert werden um sicherzustellen, dass dieses Problem in der Zukunft nicht mehr auftaucht. Wenn die Root Cause Kenntnislücken beim Tester sind, könnte man den betreffenden Tester z.B. in einem CTFL-Kurs schicken (ISTQB Certified Tester Foundation Level). Die momentane Situation wird dabei aber nicht berücksichtigt. Im Zuge der REM-Methode müssen für das oben beschriebene Problem zwei Fragen gestellt werden, deren Beantwortung sehr präzise und ausführlich sein sollte:

  • Frage an die Testabteilung / Tester:

Welchen Testfall hätten wir entwerfen müssen, damit wir diesen Fehler frühzeitig (vor Auslieferung) gefunden hätten?
Die Beantwortung dieser Frage sollte zu einem konkreten Testfall führen, der, wenn ausgeführt, genau den betreffenden Fehler aufdecken würde. Hiermit werden zwei Sachen erreicht:

  • Derartige Fehler werden in Zukunft gefunden, da jetzt ein konkreter Testfall vorliegt (Regression).
  • Durch das nachträgliche Entwerfen des Testfalls, hat der Tester seine Fähigkeiten und Aufmerksamkeit hinsichtlich zukünftigen Testdesigns gesteigert. Der Tester wird in die Lage versetzt, sich zu verbessern.
    • Frage an die Entwicklungsabteilung / Entwickler:

    Was hätten wir als Entwickler machen müssen, damit dieser Fehler nicht hätte entstehen können und frühzeitig vom Entwickler hätte entdeckt werden können?
    Die Beantwortung dieser Frage sollte zu einer Korrektur und einem konkreten Unit Testfall führen. Der Entwickler wird in die Lage versetzt, zukünftig bessere Testprozeduren zu schreiben oder für eine konsequentere Einbindung der Unit Tests in Continuous Integration zu sorgen

Bei der REM-Methode geht es also darum, dass eine bestimmte konkrete Aufgabe nachgeholt werden muss. Durch den dadurch entstandenen Lerneffekt wird eine längerfristige Qualitätssteigerung ermöglicht und das konkrete Problem wird sofort angegangen. Beachtet werden sollte, dass die REM-Methode die eigentliche Ursache des Problems nicht ermittelt. Deshalb ist es im Zuge einer kontinuierlichen Qualitätsverbesserung wichtig, neben der REM-Methode auch die 5W-Methode oder die Ishikawa Analyse einzusetzen.

Tipp aus der Praxis

Zusätzlich ist es hilfreich, bei der Durchführung einer RCA, ein Template zu verwenden. Dies stellt einerseits sicher, dass wichtige Schritte nicht vergessen werden, anderseits wird die Nachvollziehbarkeit der Analyse, auch für Weiterverwendung erhöht. Durch die Verwendung eines Template wird auch der offizielle Charakter der RCA unterstrichen.

Fazit

Um die Qualität kontinuierlich zu verbessern ist es wichtig, dass Probleme identifiziert, analysiert und offen besprochen werden, was eine gute Fehlerkultur voraussetzt. Für die Analyse sind Ishikawa und 5W sehr gut geeignet aber nicht genügend. Es braucht auch noch die REM-Methode.

Wenn Sie mehr über Root Cause Analysis erfahren möchten, oder Interesse hätten einen RCA in Ihrer Organisation durchzuführen, dann nehmen Sie doch Kontakt mit uns auf. Wir helfen Ihnen gerne weiter oder führen zusammen mit Ihnen einen Workshop bezüglich RCA durch.

Questions?

Get in touch with us to learn more about the subject and related solutions