Estimated reading time: 7 minutes
In einem kürzlich erschienenen Artikel habe ich argumentiert, dass 8D keine Problemlösungsmethode ist; es ist ein Untersuchungs-Framework. Die Resonanz war unmittelbar. Qualitätsexperten aus der Luft- und Raumfahrt, der Fertigung und aus Lean-Organisationen meldeten sich und sagten: „Wir haben das gleiche Problem mit 9S“, oder „Genau das passiert bei A3“, oder „DMAIC leidet auch darunter“.
Das Problem beschränkt sich nicht auf 8D. Tatsächlich handelt es sich um eine systemische Verwechslung, die sich über alle Branchen erstreckt. Organisationen verwechseln Frameworks zur Ursachenuntersuchung mit Methoden zur Problemlösung. Und dann wundern sie sich, warum Probleme trotz perfekter Compliance-Dokumentation immer wieder auftreten!
Lassen Sie mich den Unterschied verdeutlichen: Frameworks organisieren Untersuchungen; Methoden lehren das Denken. Mit anderen Worten: Wenn Ihr Team den Unterschied nicht versteht, trainieren Sie es darauf, Formulare auszufüllen, statt Probleme zu lösen.
Das Muster wiederholt sich über alle Branchen hinweg
Jede größere Branche hat ihr eigenes strukturiertes Framework für Korrekturmaßnahmen entwickelt. Diese Frameworks haben unterschiedliche Namen, unterschiedliche Schrittfolgen und unterschiedliche Compliance-Anforderungen. Trotz ihrer Unterschiede haben sie jedoch alle ein grundlegendes Merkmal gemeinsam: Sie sagen Ihnen, was zu tun ist, aber nicht, wie Sie denken sollen. Schauen wir uns die gängigsten Frameworks an und sehen wir, wo sie zu kurz greifen:
9S: Das erweiterte Framework der Luft- und Raumfahrt
In der Luft- und Raumfahrt ist das dominierende Framework die 9S-Methodik, die in den Standards AS13000 (2014) und ARP9136 (2016) festgeschrieben ist. Wenn ich Qualitätsexperten aus der Luft- und Raumfahrt bitte, 9S zu erklären, sagen sie meist: „Es ist im Grunde 8D mit einem zusätzlichen Schritt.“ Das ist zutreffend. Hier ist die Struktur:
- Schritt 0: Sofortige Eindämmungsmaßnahmen einleiten
- Schritt 1: Das Team zusammenstellen
- Schritt 2: Das Problem definieren
- Schritt 3: Eindämmungsmaßnahmen abschließen und optimieren
- Schritt 4: Die Ursache(n) identifizieren
- Schritt 5: Permanente Korrekturmaßnahmen definieren und auswählen
- Schritt 6: Permanente Korrekturmaßnahmen implementieren und Wirksamkeit prüfen
- Schritt 7: Standardisieren und Wissen im gesamten Unternehmen transferieren
- Schritt 8: Das Team würdigen und auflösen
Der zusätzliche Schritt (Nummer 7) konzentriert sich explizit auf Wissensmanagement und Standardisierung. Er stellt sicher, dass gewonnene Erkenntnisse dokumentiert und auf andere Produktionslinien, Fabriken, Lieferanten oder ähnliche Prozesse übertragen werden. Das ist wertvoll. Beispielsweise verhindert der Wissenstransfer, dass das gleiche Problem an anderer Stelle im Unternehmen auftritt.
Doch hier stellt sich die entscheidende Frage: Wie führen Sie Schritt 4, „Identifizierung der Ursache(n)“, aus? 9S sagt es Ihnen nicht. Genau wie 8D ist es ein Platzhalter. Es setzt voraus, dass Sie bereits wissen, wie man Ursache von Symptom isoliert, wie man Hypothesen testet und wie man Korrelation von Kausalität unterscheidet. 9S ist ein Framework, keine Methode.
A3: Toyotas visuelles Framework
In der Lean-Fertigung ist der Goldstandard das A3-Problemlösen – ein 8- bis 10-stufiges Framework auf Basis von PDCA (Plan-Do-Check-Act), das auf ein einziges Blatt Papier im A3-Format passt.
A3 legt Wert auf:
- Visuelle Kommunikation
- Prägnante Dokumentation
- Reflexion und Lernen
- Problemlösung auf Managementebene
Es ist typischerweise wie folgt strukturiert:
- Hintergrund/Aktuelle Situation
- Problembeschreibung
- Zielsetzung
- Root Cause Analysis
- Gegenmaßnahmen
- Umsetzungsplan
- Follow-up/Überprüfung
- Ergebnisse
A3 eignet sich hervorragend für die funktionsübergreifende Zusammenarbeit und die strategische Ausrichtung. Toyota nutzt es, um das PDCA-Denken und die Problemlösungsfähigkeiten der Manager zu entwickeln. Aber schauen Sie sich Schritt 4 an: Ursachenanalyse. A3 sagt Ihnen, dass eine Ursachenanalyse erforderlich ist. Aber leider sagt es Ihnen nicht, wie diese durchzuführen ist. Das Framework liefert die Berichtsstruktur, setzt aber voraus, dass Sie bereits über die analytischen Fähigkeiten verfügen. Wie 8D und 9S ist A3 ein Framework, keine Methode.
DMAIC: Das datengesteuerte Framework von Six Sigma
In Six-Sigma-Umgebungen ist das dominierende Framework DMAIC: Define, Measure, Analyze, Improve, Control. DMAIC ist ein 5-stufiges Framework, das für komplexe, datenintensive Probleme entwickelt wurde:
- Define: Das Problem eingrenzen und an den Geschäftszielen ausrichten
- Measure: Daten sammeln, um die aktuelle Leistung zu verstehen
- Analyze: Ursachen mit statistischen Werkzeugen identifizieren
- Improve: Lösungen implementieren und optimieren
- Control: Verbesserungen durch Überwachung und Standardisierung sichern
DMAIC-Projekte laufen in der Regel über 3+ Monate und nutzen anspruchsvolle statistische Werkzeuge wie Hypothesentests, Regressionsanalysen und statistische Versuchsplanung (DOE).
Schauen Sie sich auch hier die „Analyze“-Phase an. DMAIC erfordert eine Ursachenanalyse. Es betont die datengesteuerte Untersuchung. Es verlangt statistische Strenge. Es bietet jedoch keinen Denkprozess zur systematischen Isolierung kausaler Mechanismen. DMAIC-Anwender nutzen typischerweise Werkzeuge wie Ishikawa-Diagramme, 5-Why-Fragen oder Pareto-Analysen, aber diese Werkzeuge werden in das DMAIC-Framework importiert. Sie sind nicht fester Bestandteil davon. DMAIC ist ein Problemlösungs-Framework, keine Methode.
PDCA: Der Urvater von allen
PDCA (Plan-Do-Check-Act) ist das Fundament der meisten modernen Frameworks. PDCA wird oft auch als Deming-Zyklus oder Shewhart-Zyklus bezeichnet. PDCA ist der konzeptionelle Urvater der kontinuierlichen Verbesserung:
- Plan: Problem identifizieren, Ursachen analysieren, Maßnahmen definieren
- Do: Lösungen im kleinen Rahmen umsetzen
- Check: Wirksamkeit messen
- Act: Verbesserungen standardisieren oder anpassen
PDCA besticht durch seine Einfachheit. Es strukturiert den Verbesserungszyklus und betont das Lernen durch Iteration.
Wieder einmal ist die „Plan“-Phase, in der die Ursachenanalyse stattfindet, eine „Blackbox“. PDCA sagt Ihnen, dass Sie die Ursachen analysieren sollen, sagt Ihnen aber wiederum nicht, wie Sie dies systematisch tun sollen. Es bietet auch keine Methode zur Unterscheidung von echten Ursachen und scheinbaren Ursachen. Und es leitet nicht bei Hypothesentests oder der Validierung von Beweisen an. Auch hier gilt: PDCA ist ein Framework, keine Methode.
Der rote Faden: Frameworks organisieren, Methoden lehren
All diese Frameworks (8D, 9S, A3, DMAIC, PDCA) sind Strukturen für die Untersuchung von Problemen und das Projektmanagement. Sie beantworten:
- Welcher Abfolge sollten wir folgen?
- Wer sollte beteiligt sein?
- Wie dokumentieren und kommunizieren wir?
- Welche Verifizierungsschritte sind erforderlich?
- Wie stellen wir Nachhaltigkeit sicher?
Dies sind entscheidende Fragen. Frameworks bringen Disziplin in Korrekturmaßnahmen. Sie sorgen für Konsistenz, Verantwortlichkeit und organisatorisches Lernen. Aber keines von ihnen beantwortet die grundlegende Frage: Wie isolieren wir systematisch die Ursache vom Symptom?
Hier kommen Problemlösungsmethoden ins Spiel:
- Kepner-Tregoe Problem Analysis (vergleichende IS/IS NOT-Analyse und systematisches Testen von Ursachen)
- 5-Why-Fragen (Iteratives Hinterfragen von Ursachen, sofern evidenzbasiert und nicht spekulativ)
- Fehlerbaumanalyse (Deduktive Logikmodellierung)
- Ursache-Wirkungs-Analyse mit Hypothesentests
- Statistische Versuchsplanung zur Isolierung kausaler Variablen
Dies sind Problemlösungsmethoden. Sie haben logische Strukturen. Sie leiten das Denken. Sie lehren Sie, wie Sie sich durch rationales Hinterfragen vom Symptom zur Ursache vorarbeiten. Das Framework gibt Ihnen den Fahrplan. Die Methode gibt Ihnen die Navigationswerkzeuge.
Warum hält sich die Verwechslung hartnäckig?
Organisationen schulen Mitarbeiter in Frameworks und gehen davon aus, dass sie das Denken selbst herausfinden werden. Diese Annahme ist kostspielig. Folgendes passiert:
- Ein Unternehmen führt 9S, A3 oder DMAIC als seinen „Problemlösungsprozess“ ein
- Teams werden in den Schritten des Frameworks geschult
- Compliance-Vorlagen werden erstellt
- Berichte werden eingereicht und abgeschlossen
- Probleme treten erneut auf
Warum? Weil das Team nie gelernt hat, kausal zu denken. Sie haben nur gelernt, wie man einen Bericht ausfüllt. Das Framework bot Struktur, vermittelte aber keine Problemlösungskompetenz. Und sechs Monate später, wenn derselbe Fehlermodus unter leicht veränderten Bedingungen wieder auftaucht, fragt die Führungsebene: „Haben wir das nicht schon gelöst?“
Nein. Sie haben es dokumentiert. Sie haben es nicht gelöst.
Was Organisationen stattdessen tun sollten
Wenn Sie echte Problemlösungskompetenz aufbauen wollen, müssen Sie:
1. Den Unterschied zwischen Frameworks und Methoden anerkennen
Hören Sie auf zu sagen: „Wir nutzen 9S zur Problemlösung“ oder „Wir sind in A3 geschult.“ Das ist so, als würde man sagen: „Wir nutzen Microsoft Project für den Hochbau.“ Das Tool organisiert die Arbeit – es baut nicht das Gebäude. Seien Sie präzise und sagen Sie: „Wir nutzen 9S als unser Untersuchungs-Framework und wenden die Kepner-Tregoe Problemanalyse zur Ursachenidentifizierung an.“
2. Teams in tatsächlichen Problemlösungsmethoden schulen
Nicht nur in Frameworks. Lehren Sie die Menschen, wie man Ursachen von Symptomen isoliert, wie man Vergleiche anstellt, Hypothesen testet und Beweise validiert. Der deutsche VDA empfiehlt explizit die Kepner-Tregoe Problemanalyse als Best Practice für die Ursachenanalyse im 8D-Report. Warum? Weil jahrzehntelange Qualitätsdaten aus der Automobilindustrie beweisen, dass es funktioniert.
3. Methoden in Ihr Framework integrieren
Machen Sie es explizit. Ihre Vorlagen sollten festlegen: „Ursachenermittlung durchgeführt mit [Methode]. Nachweise beigefügt.“ Erlauben Sie Teams nicht, von der Problembeschreibung direkt zur vorgeschlagenen Korrekturmaßnahme zu springen, ohne dazwischen eine logische, evidenzbasierte Kausalanalyse nachzuweisen.
4. Verwechseln Sie Compliance nicht mit Kompetenz
Das Ausfüllen eines 9S-Berichts, eines A3 oder eines DMAIC-Projekts ist eine Compliance-Aktivität. Das Lösen des Problems ist eine Kompetenz-Aktivität. Das ist nicht dasselbe. Sie können eine perfekte Framework-Dokumentation und eine schreckliche Problemlösung haben. Oder Sie können eine brillante Problemlösung haben, die in einem Framework schlecht dokumentiert ist. Das Ziel ist natürlich beides: eine konforme Dokumentation und eine kompetente Problemlösung!
Abschließender Gedanke
Frameworks sind wertvoll. Sie bringen Disziplin, Konsistenz und Verantwortlichkeit in Korrekturmaßnahmen. Sie stellen sicher, dass Probleme eingedämmt, Lösungen verifiziert und Wissen transferiert wird.
Aber Frameworks sind kein Ersatz für kritisches Denken. Sie sind kein Ersatz für eine Ursachenanalyse. Und sie sind ganz sicher keine Problemlösungsmethoden.
Wenn Ihr Unternehmen echte Problemlösungskompetenz aufbauen will (die Art, die ein Wiederauftreten verhindert, Garantiekosten senkt und Ihre Kunden schützt), müssen Sie darin investieren, den Menschen das Denken beizubringen, nicht nur das Ausfüllen von Formularen.
Frameworks geben Ihnen Struktur. Problemlösungsmethoden geben Ihnen Substanz.
Ohne beides verwalten Sie lediglich Papierkram.
Über den Autor
Phillip Thompson ist Senior Vice President of Client Experience bei Kepner-Tregoe Inc., einem Beratungsunternehmen, das auf kritisches Denken und rationale Problemlösungsmethoden spezialisiert ist. Mit fast 40 Jahren Erfahrung hat Phillip mit Fortune-100-Unternehmen in 15 Branchen zusammengearbeitet, um organisatorische Fähigkeiten in systematischer Problemlösung und Entscheidungsfindung aufzubauen.
