7. Ishikawa-Diagramm (Ursachenanalyse)

Kapitel Übersicht

Kapitel 7/8 Lesezeit: ~10 Min Modul 10: Planung II

🎯 Lernziele

Nach diesem Kapitel können Sie: - Das Ishikawa-Diagramm als Werkzeug zur systematischen Ursachenanalyse einsetzen - Die 4M-, 6M- und 8M-Analyse unterscheiden und anwenden - Ursachen-Wirkungs-Beziehungen in IT-Projekten visualisieren - Ishikawa mit 5-Why und Pareto-Analyse kombinieren

📋 Einführung

Das Ishikawa-Diagramm, auch als Fischgräten-Diagramm oder Cause-and-Effect-Diagramm bekannt, ist eines der sieben Qualitätswerkzeuge (Seven Basic Tools of Quality). Es wurde 1943 von Kaoru Ishikawa entwickelt und ist bis heute ein Standardwerkzeug in der systematischen Problemanalyse.

Ursprung

Ishikawa entwickelte das Diagramm ursprünglich für die japanische Stahlindustrie, um komplexe Produktionsprobleme systematisch zu dekonstruieren. Inzwischen ist es ein weltweit etabliertes Instrument in der Qualitätssicherung, im Projektmanagement und in der IT-Beratung.

Das Diagramm visualisiert Ursachen-Wirkungs-Beziehungen in einer graphisch anschaulichen Form: - Der Kopf des Fisches repräsentiert das zu lösende Problem (Effekt) - Die Gräten stehen für die Hauptkategorien potenzieller Ursachen - Die Nebenäste enthalten detaillierte Ursachen innerhalb jeder Kategorie

🔍 Die 4M-Analyse

Die ursprüngliche Methode umfasst vier Hauptkategorien, die im Produktionsumfeld etabliert waren:

Kategorie	Bedeutung	Beispiele in der IT
Mensch	Alle am Prozess beteiligten Personen	Qualifikation, Motivation, Schulung, Auslastung
Maschine	Technische Hilfsmittel und Werkzeuge	Server, Netzwerk, Software-Tools, Hardware
Material	Eingangsressourcen und Daten	Datenqualität, Bibliotheken, APIs, Schnittstellen
Methode	Vorgehensweisen und Prozesse	Entwicklungsprozess, Teststrategien, Dokumentation

Mensch als häufigste Ursache

Statistische Analysen zeigen, dass in IT-Projekten 60-70% aller Probleme auf die Kategorie "Mensch" zurückzuführen sind: mangelnde Schulung, Überlastung, unklare Kommunikation oder fehlende Kompetenzen.

📈 Die 6M-Analyse (Erweiterung)

Mit zunehmender Komplexität der Prozesse wurden zwei weitere Kategorien eingeführt:

Kategorie	Bedeutung	Beispiele in der IT
Messung	Metriken und Kontrollinstrumente	Performance-Monitoring, KPIs, Logs, Testabdeckung
Mitwelt	Externe Einflüsse	Gesetzesänderungen, Marktentwicklung, Konkurrenz,供应商-Änderungen

Die Mitwelt ist besonders in IT-Projekten kritisch: Änderungen bei Cloud-Providern, neue Sicherheitsvorschriften oder Marktdruck können Projekterfolg massiv beeinflussen.

🎯 Die 8M-Analyse (Standard in der IT-Beratung)

Die umfassendste Variante, die in modernen IT-Projekten Standard ist, erweitert die Analyse um zwei weitere Dimensionen:

Kategorie	Bedeutung	Beispiele in der IT
Management	Führung und Entscheidungsfindung	Projekt Governance, Budget, Priorisierung, Stakeholder-Management
Money (Geld)	Finanzielle Rahmenbedingungen	ROI-Anforderungen, Kostendruck, Budget-Cuts, Vergütungsmodelle

Management als Blocker

Häufig sind Management-Entscheidungen die eigentliche Wurzel von Problemen: unrealistische Zeitpläne, Budgetkürzungen oder mangelnde Ressourcenallokation. Das Ishikawa-Diagramm macht diese strukturellen Probleme sichtbar.

🔄 Schritt-für-Schritt Anleitung

Schritt 1: Problemdefinition

Formulieren Sie das Problem eindeutig und messbar. Vermeiden Sie vage Beschreibungen.

Schlecht	Gut
"Die Software ist langsam"	"Die Ladezeit des Dashboards > 5 Sekunden"
"Das Projekt läuft nicht"	"Projektverzug von 4 Wochen beim Milestone M3"
"Die Qualität ist schlecht"	"Testabdeckung < 60% in Modul Payment"

Schritt 2: Team-Composition

Stellen Sie ein interdisziplinäres Team zusammen. Je nach Projektgröße 3-8 Personen.

Diversität ist der Schlüssel

Ein Ishikawa-Workshop mit nur Entwicklern liefert selten umfassende Ergebnisse. Einholen Sie Perspektiven von DevOps, Security, Sales, Support und Management ein.

Schritt 3: Brainstorming

Nutzen Sie das 8M-Framework als Struktur. Lassen Sie das Team für jede Kategorie Ursachen sammeln.

Schritt 4: Visualisierung

Erstellen Sie das Diagramm. Nutzen Sie dafür: - Whiteboard oder Flipchart (für Workshops) - Digitale Tools (Miro, Lucidchart, Draw.io) - Markdown/Mermaid (für Dokumentation)

Schritt 5: Priorisierung

Nicht alle Ursachen sind gleich relevant. Nutzen Sie zur Priorisierung: - Häufigkeit: Wie oft tritt die Ursache auf? - Auswirkung: Wie stark beeinflusst sie das Problem? - Aufwand: Wie leicht ist die Behebung?

💡 IT-Projektbeispiel: Performance-Problem

Eine Web-Applikation zeigt massive Performance-Einbrüche während der Spitzenlastzeiten.

graph LR
    P[Performance-Einbrüche<br>Peak-Load] --> M1[Mensch]
    P --> M2[Maschine]
    P --> M3[Material]
    P --> M4[Methode]
    P --> M5[Messung]
    P --> M6[Mitwelt]
    P --> M7[Management]
    P --> M8[Money]

    M1 --> U1[Entwickler unzureichend<br>in Performance-Optimierung geschult]
    M1 --> U2[Überlastung durch<br>mehrere parallele Projekte]

    M2 --> U3[Server-Hardware<br>unzureichend dimensioniert]
    M2 --> U4[Kein Auto-Scaling<br>in Cloud-Umgebung]

    M3 --> U5[CSV-Exporte mit<br>100.000+ Datensätzen]
    M3 --> U6[Veraltete Datenbank-Indizes]

    M4 --> U7[Kein Performance-Testing<br>im CI/CD-Pipeline]
    M4 --> U8[Monolithische Architektur<br>behindert Skalierung]

    M5 --> U9[Kein Monitoring für<br>Datenbank-Abfragen]
    M5 --> U10[Falsche KPIs:<br>nur Response-Time gemessen]

    M6 --> U11[Marktspitzen<br>nicht antizipiert]
    M6 --> U12[Konkurrenz-Features<br>erhöhen User-Traffic]

    M7 --> U13[Budget-Cuts für<br>Infrastruktur-Upgrade]
    M7 --> U14[Unrealistische<br>Release-Termine]

    M8 --> U15[Günstige Cloud-Region<br>mit hoher Latenz]
    M8 --> U16[Kein Budget für<br>Performance-Tools]

    style P fill:#f96,stroke:#333,stroke-width:3px
    style M1 fill:#e8f4f8,stroke:#2980b9,stroke-width:2px
    style M2 fill:#e8f4f8,stroke:#2980b9,stroke-width:2px
    style M3 fill:#e8f4f8,stroke:#2980b9,stroke-width:2px
    style M4 fill:#e8f4f8,stroke:#2980b9,stroke-width:2px
    style M5 fill:#f8e8e8,stroke:#c0392b,stroke-width:2px
    style M6 fill:#f8e8e8,stroke:#c0392b,stroke-width:2px
    style M7 fill:#f8f8e8,stroke:#f39c12,stroke-width:2px
    style M8 fill:#f8f8e8,stroke:#f39c12,stroke-width:2px

Analyseergebnis: - Root Causes (Häufigkeit + Auswirkung): M3-U6 (veraltete Indizes), M4-U7 (kein Performance-Testing), M2-U4 (kein Auto-Scaling) - Quick Wins (Häufigkeit + geringer Aufwand): M3-U6 (Indizes aktualisieren), M5-U9 (Monitoring implementieren) - Strategic Fixes (Auswirkung + hoher Aufwand): M2-U4 (Auto-Scaling), M4-U8 (Microservices-Migration)

🔄 Kombination mit anderen Methoden

Ishikawa + 5-Why

Die 5-Why-Methode ist ideal für die vertiefte Analyse einzelner Ursachen aus dem Ishikawa-Diagramm.

Kombinations-Ansatz

1. Ishikawa-Wizard: Team sammelt alle potenziellen Ursachen für "Performance-Problem"
2. Identifikation: Top 3 Ursachen mit höchstem Einfluss werden identifiziert
3. 5-Why-Deep-Dive: Für jede Top-Ursache 5-mal nach dem "Warum" fragen

Beispiel: - Problem: Veraltete Datenbank-Indizes (M3-U6) - Why 1: Wurden nach Datenmigration nicht aktualisiert - Why 2: Kein Prozess für Index-Maintenance - Why 3: DB-Admin fehlt im Projektteam - Why 4: Budget für zusätzliche Ressourcen nicht genehmigt - Why 5: Management hat DB-Optimierung als "nice-to-have" eingestuft

Ishikawa + Pareto

Die Pareto-Analyse (80/20-Regel) priorisiert die identifizierten Ursachen quantitativ.

pie title Ursachenverteilung (Pareto-Analyse)
    "Veraltete Indizes" : 35
    "Kein Auto-Scaling" : 25
    "Kein Performance-Testing" : 15
    "Entwickler-Schulung" : 10
    "Management-Budget" : 10
    "Andere" : 5

Pareto-Insight

Die Analyse zeigt, dass 3 Ursachen (veraltete Indizes, kein Auto-Scaling, kein Performance-Testing) für 75% des Performance-Problems verantwortlich sind. Fokussierung auf diese 3 Ursachen liefert maximalen ROI.

📊 Checkliste: Ishikawa-Workshop

✅ Vorbereitung
  ✅ Problem klar definiert (eindeutig + messbar)
  ✅ Interdisziplinäres Team zusammengestellt (3-8 Personen)
  ✅ Workshop-Raum mit Whiteboard/Flipchart
  ✅ Post-its in verschiedenen Farben vorbereitet

✅ Durchführung
  ✅ 8M-Kategorien am Board skizziert
  ✅ Brainstorming: Ursachen pro Kategorie sammeln
  ✅ Doppelungen zusammenführen
  ✅ Ursachen visualisieren (Fischgräten-Diagramm)

✅ Analyse
  ✅ Ursachen nach Häufigkeit bewerten
  ✅ Ursachen nach Auswirkung bewerten
  ✅ Ursachen nach Aufwand zur Behebung bewerten
  ✅ Pareto-Diagramm erstellen

✅ Maßnahmen
  ✅ Top 3-5 Root Causes identifiziert
  ✅ Verantwortlichkeiten zugewiesen
  ✅ Zeitrahmen für Maßnahmen definiert
  ✅ Erfolgsmetriken definiert

🚀 Fazit

Das Ishikawa-Diagramm ist ein mächtiges Werkzeug für IT-Berater, um komplexe Probleme systematisch zu dekonstruieren. Die 8M-Methode strukturiert das Chaos und fördert interdisziplinäre Zusammenarbeit. In Kombination mit 5-Why und Pareto-Analyse werden aus Problemen fundierte, priorisierte Maßnahmenpläne.

Häufiger Fehler

Das Ishikawa-Diagramm ist kein Selbstzweck. Ohne konsequente Umsetzung der identifizierten Maßnahmen ist es bloße Dokumentation. Definieren Sie nach jedem Workshop klare Action Items mit Verantwortlichen und Deadlines.

➔ Weiter zum nächsten Kapitel

Im nächsten Kapitel 8. Quiz können Sie Ihr Wissen aus diesem Modul in einem interaktiven Wissensquiz testen.