Modul Ursachen-Wirkungsanalyse Oder Root-Cause Analysis Oder Cause-Effect Analysis

Copyright: Dr. Klaus Röber Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Ursachen-Wirkungsanalyse 1

Modul

Ursachen-Wirkungsanalyse

Oder

Root-Cause Analysis

Oder

Cause-Effect Analysis


Ein Guru des Qualitätsmanagements

Was hat er geleistet?

- Vereinfachung statistischer Techniken für Qualitätskontrolle in der Industrie- Verbreitung der 7 Tools- Company Wide Quality Control Movement - Produktqualität - Kundendienstqualität - Managementqualität - Unternehmensqualität - Lebensqualität

Ishikawa, K.: What i s Total Q uality Control? The Japa nese Wa y, Prentice Hall 1985

Dr. Kaoru Ishikawa1915 - 1989


Die 7 Tools des Qualitätsmanagements

Die 7 Tools

Pareto-Diagramm

Ishikawa-Diagramm

Histogramm Qualitäts-Regelkarten

Korrelations-Diagramm

GraphischeDarstellungen

Checklisten

Quelle: H. D. Seghezzi: Integriertes Qualitäts management - Das St. Galler Konzept, Hanser 1996


Ishikawa- oder Fischgrätendiagramm

Maschine

Material

Mensch

Management Methode

Milieu

Wirkung

Visualisierung der Ursachen-Wirkungsanalyse

Quelle: H. D. Seghezzi: Integriertes Qualitäts management - Das St. Galler Konzept, Hanser 1996


Beispiele für Achsenbelegungen (1. Ebene)

Maschine

Material

Mensch

Management Methode

Milieu

Wirkung

Energie

Zeit4M6M6M+

Völlig frei

Schritte des Prozesses, von dem die Probleme herrühren

A)

B)

C)


Beispiel für Achsenbelegungen (1. und 2. Ebene)

Maschine

Material

Mensch

Management Methode

Milieu

WirkungVerantwortung

und

Zielvorgaben

MBO

Kompetenz

Probleme

privat

betrieblich

AusbildungToleranz

Oberfläche

Masse Pflege

Reinigung

Ausstattungdes Arbeitsplatzes

Betriebsklima

Kontrolle

Organisation

Verfahren

Werkzeug

Wartung

Quelle: Seghezzi, Integrier tesQualitätsmanagement, Hanser 1996


Stärken des Ishikawa-Diagramms

Problem definieren

Bestimmung der beteiligten Einflussgrößen

Auswahl der wichtigsten Faktoren

Untersuchung der Faktoren

Beziehungen zwischen den Faktoren prüfen

Erzeugung und Strukturierung von Ideen

Quelle: Qu alitätsmanagement-Methoden, Weka Praxis Handbuch 1997

Das Ishikawa-Diagramm hilft uns bei folgenden Aktivitäten:


Wie konstruiert man ein Ishikawa-Diagramm?

Einigen Sie sich darüber, was der Effekt (das Problem) istSchreiben Sie das Problem in einen Kreis und ziehen eine lange Linie, die auf den Kreis zeigtEntscheiden Sie über die Haupt-UrsachenkategorienSchreiben Sie die Hauptkategorien parallel in einiger Entfernung von der Hauptachse auf und verbinden sie mit der Hauptachse Brainstorming der möglichen UrsachenFügen Sie die Ursachen in das Diagramm ein, gruppiert um die Hauptachsen, die sie beeinflussen. Unterteilen Sie die Ursachen, um zu zeigen, wie sie untereinander zusammenhängen und verbinden sie zusammenhängende Ursachen. Wenn das Diagramm zu voll wird, lagern Sie eine oder mehrere Kategorien auf ein separates Blatt auus.Analysieren Sie die möglichen Gründe und bewerten sie hinsichtlich ihrer BedeutungTreffen Sie Entscheidungen und tun Sie was


Beispiel 1: Mangelnde Anwenderakzeptanz

Maschine

Material

Mensch

Methode

MangelndeAnwenderAkzeptanz

Kein Management der Erwartungen

Management Ressourcennicht verfügbar

Komplexe Log-on Prozedur

Schlechte Antwortzeiten

Regelmäßiger Ausfalldes Servers

Kaum Anwenderunterstützung

Keine On-Line Hilfe

Kein Anwendertraining

Keine Trainings-unterlagen

Unzureichende Einweisung in das neue System

Keine Richtlinien fürFehlerverfolgung

Quelle: Tex as Instruments, The Qua lity System for Information Engineering, 1995


Beispiel 2: Instabile Softwareanforderungen

Mensch

Mensch

Mensch

Maschine Methode

Milieu

Software-anforderungen

sindinstabil

Keine Versions-verwaltung

Keine Prüfung

Texteditor

Verfügbarkeit

Schrumpfung

Konkurrenz-druck

MangelhaftetechnischeÜbersicht

UnrealistischePlanung

Keine Standards

unmotiviert

Bezahlung

Förderung

PsychologischesGeschick

(Systemanalytiker)(Software Management)(Markt)

Hoher Aufwand

(Analysemethoden)(Auftraggeber)(Analysewerkzeuge)

Ungeeignet fürdie Problemstellung

Konsistenznicht prüfbar

Unpräzise

StrukturierterText

WidersprüchlicheAngaben

HäufigeÄnderungen

SchlechterKenntnisstand

KeineSchulung

WenigErfahrung

Quelle : H . Balzert, Lehrbuch der Software-Tec hn ik, Spektrum 1998


Beispiel 3: Anwender-Schnittstelle mangelhaft

UnterschiedlichePerspektiven

Au weiah!(vergessen)

MangelhafteRichtlinien

Richtlinien wurden nicht befolgt

Keine Konsistenzzwischen denDivisionen

Zu vieleKombinationen

von Eigenschaften

Wir warenin Eile

Folge von

Anwender-Schnittstelle

Veränderungen

Entscheidung basiertauf nicht repräsentiver

Kundenauswahl

Zu vieleDetails

Einige Komponentendes Produktspassen nicht zueinander

Keine Zeit

Mangel anRessourcen

Kein Prozeß etabliert,der frühzeitigesFeedback liefert

Einige Panelswerden nichtoft benutzt

Anwender nichtauf neues Produkt

fokussiert

Die Tests modellierendie Anwenderumgebung

nicht adäquat

Keine Ästhetik Wir sind zubeschäftigt, um unsdanach zu richten

Kein gutesModell

Sie werdennicht gelesen

Nicht zentralverfügbar

BegrenzteRessourcen

Interne Kundenentscheiden nur auf

Basis der FunktionalitätEin Prototypreicht nicht

MangelhaftesFeedback

Quelle: Hewlett-Packard Journal, R.B.Grady, 1996


Beispiel 4: Spezifikationsmängel

Spezifikations-mängel

Systemarchitektur Veränderungender Umgebung

HardwareÄnderungen

Externe Referenz-Spezifikation (ERS)

MangeldesVerständnis

Keine Konsis tenzzwischen den

Divis ionen

Managementtraf keine

Entscheidungen

Die ERSpassen nichtzusammen

Technologie

UngenügendesTraining

InterneGründe

Veränderungder Regeln

Reorganisationdes Bereichs

ExterneGründe

Operationg SystemVeränderungen

Schnittstellenzum OS nicht

klar dokumentiert

Existenzunbekannt

Mangelndes Ver-ständnis /Interpretation

der Anwenderbedürfnisse

Interne “Köche” nicht immer dieselben

wie externe

Neue Technologien

UngenügendesTraining

Rückwärts-kompatibilität

nicht verstanden

SchlechteOrganisation

Kein Standardformat

KeineHardware-

spezifikation

Spezifikationzu kompliziert

UnvorhergeseheneNebeneffek te

Spezifikationzu kompliziert Nicht aktuell

InformellerKontroll-

mechanismus

FalschesTraining

Dokumentations-standard fehlt

ERS wurde nicht erstel lt

Keine ERS für Altsystem

Prozeß für Ablösung vonAltsystemen nicht def iniert

Dokumentations-standard fehlt

ÜngenügendeKommunikation

Quelle: Hewlett-Packard Journal, R.B.Grady, 1996


Lernen aus Erfahrungen der Vergangenheit - Spezifikation der Anwenderschnittstellen verfolgen, insbesondere wenn Änderungen eintreten

Wenn neue Funktionalität hinzugefügt werden soll, immer die Konsequenzen für Anwenderschnittstellen bedenken und spezifizieren

Andere Anwendungen analysieren

Checkliste beim Oberflächen-Design verwenden

Das Caseworks Design Tool einsetzen

Wenn die Realisierung neuer Funktionalität begonnen wird, muss diese auch vollständig erstellt werden

Neue Funktionalität dem Anwender zur sofortigen Erprobung übergeben

Erreichen, dass durchdachtes Feedback gegeben wird, Richtlinien für Feedback aufstellen

Anwender beobachten, wie sie die Oberfläche bedienen

Walkthroughs hinsichtlich der Nutzbarkeit durchführen

Training durchführen

Standardmodule verwenden (z.B. einheitliche Dialog-Boxen)

Beispiel 4: Lösungsvorschläge

Quelle: Hewlett-Packard Journal, R. B. Grady, 1996


Beispiel 4: Planung der Verbesserungsaktivitäten (Muster)

1. Arbeitsgruppe einrichten (8/10)2. Treffen und erwartete Ergebnisse definieren (15/10)3. Ziele vorstellen und Feedback sammeln (1/11)4. Veränderungsprozess definieren und Ergebnisse

erstellen (1/12)5. Prozess und Ergebnisse inspizieren und verbessern

(15/12)6. Projektabschluss feiern (16.12.)7. Neue Richtlinien verwenden und Ergebnisse messen

(1/2)



Beispiel 4: Planung der Verbesserungsaktivitäten (Beispiel HP)

1. Patty wird eine Checkliste zum Oberflächendesign erstellen (erster Entwurf 17/12)

2. Der Projektmanager wird festlegen, dass in Zukunft erwartet wird, dass neue Funktionalität grundsätzlich Design und Spezifikationskonsequenzen zur Folge haben wird (es soll überlegt werden, ob ein neues Format für Spezifikationen verwendet werden soll)

3. Art wird für das Team eine Präsentation über Caseworks geben

4. Nach der Präsentation wird das Team eine Diskussion über die Verwendung von Prototyping führen



Übung 1: Erstellen eines Ishikawa-Diagramms

Der Kopiergerätehersteller Copyking stellt gerade das Handbuch für sein neuestes Kopiergerät fertig. Das letzte Kapitel sollmögliche Funktionsstörungen des Geräts behandeln. Um diese möglichen Funktionsstörungen oder Bedienungsfehler heraus-zufinden, setzen sich die Produktmanager zu einem Brainstorming zusammen. Ziel ist es, die potentiellen Ursachen für Fehleroder schlechte Kopien zu sammeln. Folgende Aussagen der Produktmanager werden in einem Sitzungsprotokoll festgehalten:

- Das Netzkabel steckt nicht im Gerät.- Das Netzkabel steckt nicht in der Steckdose.- Das Papierfach ist leer.- Es ist nur noch wenig oder kein Toner vorhanden.- Das Original ist falsch positioniert.- Das Papier ist nicht zum Kopieren geeignet.- Das Netzteil am Gerät ist defekt.- Das falsche Papierformat wurde eingestellt.- Die Anzahl der Kopien stimmt nicht.- Das Netzkabel i st gebrochen.- Die Steckdose ist nicht am Stromnetz.- Der Deckel des Kopiertisches ist nicht zugeklappt.- Die Zoomeinstellung ist falsch.- Kopierwalze ist verschmutzt.- Papiereinzug ist defekt.- Original ist ungeeignet (zu wenig Kontraste).- Die Helligkeit ist zu hoch.- Belichtungseinheit/Lampe ist defekt.- Kopierwalze ist defekt.

Erstellen Sie ein Ishikawa-Diagramm der Zusammenhänge. Wie können die Ergebnisse konkret in die Erstellung des Benutzungshandbuches eingebracht werden?

Jeder arbeitet allein, Zeit 30 MinutenQuelle : H . Balzert, Lehrbuch der Software-Tec hnik, Spektrum 1998


Musterlösung:

Verbrauchsmittel

Bedienung(Fehler)

Stromversorgung

Gerät(Defekte)

Keine/schlechte

Kopie

Kabel nicht inder Steckdose

Kabel gebrochen

Papier

Zu wenig Kontrasteauf dem Original

Anzahl derKopien falsch

Deckel nichtzugeklappt

Original falschpositioniert

Zoomeinstellungfalsch

Papierformatfalsch eingestellt

Kein TonerSteckdose nichtam Netz

Walze verschmutzt

Defekt

Walze

Netzteil Einzug

Belichtung

Zu niedrigeingestellt

Helligkeit

Zu hocheingestellt

Kabel nichtim Gerät

Papierstau

Papierfachleer

Papier nichtgeeignet

Das Diagramm kann zur Gliederung des Kapitels„Funktionsstörungen“ verwendet werden.


Übung 2:

Sie sind bei einer Mathe-Klausur durchgefallen.Analysieren Sie die Gründe dafürBenutzen Sie die 6M Version des Ishikawa-Diagramms für die Analyse (Milieu, Mensch, Maschine, Management, Material, Methode)Arbeit in Gruppen, Zeit 30 Minuten

Documents

Modul Ursachen-Wirkungsanalyse Oder Root-Cause Analysis Oder Cause-Effect Analysis