Ishikawa Diagramm

Definition, Inhalt und Herkunft

Definition: Das Ishikawa-Diagramm, auch bekannt als Fischgräten-, Herringbone-, Ursache-Wirkungs-Diagramm oder Fishikawa, ist ein Kausaldiagramm, das von Kaoru Ishikawa entwickelt wurde. Es dient dazu, die potenziellen Ursachen eines bestimmten Ereignisses systematisch darzustellen. Ishikawa führte diese Methode 1968 ein.

Inhalt und Herkunft: Das Diagramm ist eine visuelle Darstellungsform, die eine strukturierte Analyse von Problemen ermöglicht, indem es alle möglichen Ursachen in geordneter Weise aufzeigt. Es wurde ursprünglich im Rahmen des Qualitätsmanagements in Japan entwickelt und wird heute weltweit in verschiedenen Branchen eingesetzt, um die Ursachenanalyse zu unterstützen und Problemlösungen zu finden.

Ziele und Nutzen

Ziele:

• Systematische Ermittlung möglichst vieler Ursachen eines Problems, um übereilte und voreilige Schlussfolgerungen zu vermeiden.

• Strukturierte und visuelle Darstellung der definierten Ursachen, um ein besseres Verständnis und eine umfassende Analyse zu ermöglichen.

Nutzen:

• Förderung eines tieferen Verständnisses der Problemursachen durch Teamarbeit und Diskussion.

• Erhöhung der Wahrscheinlichkeit, die wahren Ursachen eines Problems zu identifizieren.

• Unterstützung bei der Entwicklung gezielter Maßnahmen zur Problemlösung.

• Verbesserung der Kommunikation und Zusammenarbeit im Team durch die gemeinsame Erstellung und Analyse des Diagramms.

Anwendung und Vorgehen

Anwendung: Ein Ishikawa-Diagramm wird eingesetzt, um die Ursachen eines Problems in verschiedenen Bereichen zu analysieren. Es kann in der Produktion, im Dienstleistungssektor, im Gesundheitswesen und in vielen anderen Bereichen angewendet werden.

Vorgehensweise:

1. Teamaufstellung: Zusammenstellung eines multidisziplinären Teams.

2. Problemdefinition: Präzise Formulierung des zu analysierenden Problems.

3. Hauptkategorien identifizieren: Bestimmung der Hauptkategorien der möglichen Ursachen, wie Materialien, Methoden, Menschen, Maschinen, Umwelt und Messung.

4. Ideensammlung: Brainstorming und Sammeln möglicher Ursachen, die den Hauptkategorien zugeordnet werden.

5. Unterursachen identifizieren: Detaillierte Analyse durch wiederholtes Hinterfragen („Warum geschieht das?“) zur Identifikation von Unterursachen.

6. Visualisierung: Erstellung des Ishikawa-Diagramms zur geordneten Darstellung aller Ursachen und Unterursachen.

7. Bewertung und Maßnahmen: Bewertung der Ursachen, Identifizierung der wichtigsten Ursachen und Definition gezielter Maßnahmen zur Problemlösung

Anwendungsbeispiel

Ausgangslage

Ein Softwareentwicklungsunternehmen hat wiederholt Probleme mit der hohen Anzahl von Softwarefehlern (Bugs) in ihren Anwendungen. Diese Fehler führen zu Verzögerungen bei der Markteinführung, erhöhten Supportkosten und Unzufriedenheit bei den Kunden. Trotz mehrerer Testphasen und Code-Reviews treten weiterhin zahlreiche Fehler auf, die in der Produktionsumgebung entdeckt werden.

Vorgehen

Teamaufstellung:

• Ein multidisziplinäres Team wurde zusammengestellt, das aus Softwareentwicklern, Testern, Projektmanagern und Qualitätssicherungsspezialisten bestand. Ziel war es, alle relevanten Perspektiven einzubeziehen.

Definition des Problems:

• Das Problem wurde als „Hohe Anzahl von Softwarefehlern in der Produktionsumgebung“ definiert. Diese Definition wurde präzise formuliert, um ein gemeinsames Verständnis zu gewährleisten.

Hauptkategorien der Ursachen:

• Die Hauptkategorien wurden basierend auf den typischen Ursachen im Softwareentwicklungsprozess definiert:

• Materialien (Werkzeuge und Technologien): Fehlende oder unzureichende Entwicklungswerkzeuge, veraltete Technologien.

• Methoden: Ineffiziente Entwicklungsprozesse, unzureichende Testmethoden.

• Menschen: Mangelnde Erfahrung oder Schulung der Entwickler, Kommunikationsprobleme im Team.

• Maschinen (Infrastruktur): Unzureichende Hardware, Netzwerkprobleme.

• Umwelt: Unklare Anforderungen, sich ändernde Projektvorgaben.

• Messung: Unzureichende Qualitätskontrollen, fehlende Metriken zur Fehleranalyse.

Ideensammlung:

• Das Team sammelte mögliche Ursachen für die Softwarefehler und ordnete sie den Hauptkategorien zu. Dies erfolgte durch Brainstorming-Sitzungen und Diskussionen.

Unterursachen identifizieren:

• Für jede Hauptursache wurden Unterursachen identifiziert, indem die Frage „Warum geschieht das?“ gestellt wurde. Diese Unterursachen wurden auf kleineren Seitenachsen im Ishikawa-Diagramm platziert.

Ergänzende Diagramme:

• Bei besonders komplexen Bereichen wurden zusätzliche Ishikawa-Diagramme erstellt, um eine detaillierte Analyse zu ermöglichen.

Bewertung und Maßnahmen:

• Die Wahrscheinlichkeit des Auftretens jeder Ursache wurde gemeinsam bewertet. Wahrscheinliche Ursachen, die durch Daten oder Teamkonsens verifiziert wurden, wurden grün markiert. Ursachen, die ausgeschlossen wurden, rot, und zu bestätigende Ursachen orange.

• Basierend auf dieser Analyse wurden gezielte Maßnahmen zur Fehlerreduktion definiert, wie z.B. die Einführung neuer Testmethoden, Schulungen für die Entwickler und die Verbesserung der Entwicklungsinfrastruktur.

Resultat

• Fehlerreduktion: Die Implementierung der identifizierten Maßnahmen führte zu einer signifikanten Reduktion der Softwarefehler um 70%.

• Verbesserte Prozesse: Die Überarbeitung der Entwicklungs- und Testprozesse resultierte in effizienteren Abläufen und besserer Qualitätssicherung.

• Mitarbeiterentwicklung: Durch gezielte Schulungsprogramme wurde die Kompetenz der Entwickler gesteigert, was sich positiv auf die Fehlerquote auswirkte.

• Kundenzufriedenheit: Die reduzierte Fehleranzahl führte zu höherer Kundenzufriedenheit und weniger Supportanfragen.

Referenzen

• Ishikawa, K. (1968). Guide to Quality Control. Tokyo: Asian Productivity Organization.

• Juran, J. M. (1988). Juran's Quality Control Handbook. McGraw-Hill.

• Tague, N. R. (2005). The Quality Toolbox. ASQ Quality Press.

• Basu, R. (2004). Implementing Quality: A Practical Guide to Tools and Techniques. Thomson Learning.

• ChatGPT: Quality Management Excellence