Modul Ursachen-Wirkungsanalyse Oder Root-Cause Analysis Oder Cause-Effect Analysis
description
Transcript of 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
Copyright: Dr. Klaus Röber Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Ursachen-Wirkungsanalyse 2
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
Copyright: Dr. Klaus Röber Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Ursachen-Wirkungsanalyse 3
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
Copyright: Dr. Klaus Röber Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Ursachen-Wirkungsanalyse 4
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
Copyright: Dr. Klaus Röber Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Ursachen-Wirkungsanalyse 5
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)
Copyright: Dr. Klaus Röber Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Ursachen-Wirkungsanalyse 6
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
Copyright: Dr. Klaus Röber Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Ursachen-Wirkungsanalyse 7
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:
Copyright: Dr. Klaus Röber Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Ursachen-Wirkungsanalyse 8
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
Copyright: Dr. Klaus Röber Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Ursachen-Wirkungsanalyse 9
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
Copyright: Dr. Klaus Röber Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Ursachen-Wirkungsanalyse 10
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
Copyright: Dr. Klaus Röber Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Ursachen-Wirkungsanalyse 11
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
Copyright: Dr. Klaus Röber Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Ursachen-Wirkungsanalyse 12
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
Copyright: Dr. Klaus Röber Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Ursachen-Wirkungsanalyse 13
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
Copyright: Dr. Klaus Röber Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Ursachen-Wirkungsanalyse 14
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)
Quelle: Hewlett-Packard Journal, R. B. Grady, 1996
Copyright: Dr. Klaus Röber Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Ursachen-Wirkungsanalyse 15
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
Quelle: Hewlett-Packard Journal, R. B. Grady, 1996
Copyright: Dr. Klaus Röber Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Ursachen-Wirkungsanalyse 16
Ü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
Copyright: Dr. Klaus Röber Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Ursachen-Wirkungsanalyse 17
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.
Copyright: Dr. Klaus Röber Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Ursachen-Wirkungsanalyse 18
Ü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