PROBLEM MANAGEMENT STRUKTURERET PROBLEM ANALYSE

Transkript

1 PROBLEM MANAGEMENT STRUKTURERET PROBLEM ANALYSE

2 UDBYTTE VED STRUKTURERET PROBLEM ANALYSE Metoden er med til at sikre: At vi bliver skarpere på vores problem definitioner At vi undgår at springe til årsagen uden først at have analyseret data At vi løser det rigtige problem 1 5. J A N U A R

3 STRUKTURERET PROBLEM ANALYSE Metoden er udviklet af Charles Kepner and Benjamin Tregoe 1) Definer et Første trin er at få defineret problemet. Dette gøres ved at beskrive den afvigelse som du skal finde årsagen til. Angiv Object(CI) og Afvigelse i beskrivelsen. Vær specifik!! 2) Specificer et Dette gøres via ER og ER IKKE spørgsmål. Vi forsøger her at specificere afvigelsen (problemet) fra normalen. - Stil spørgsmål i 4 dimensioner: - HVAD Identitet - HVOR Sted - HVORNÅR Tid - OMFANG - Størrelse ER Information bruges til at beskrive problemet i detaljer. ER IKKE information bruges til at eliminere årsager til problemet. Oftest er det denne information, der springes over i traditionel løsning J A N U A R

4 STRUKTURERET PROBLEM ANALYSE 3) Identificer mulige årsager Beskriv årsager der forklarer hvordan afvigelsen er opstået. - Brug viden og erfaring. Brainstorm sessions. - Led efter særpræg. Hvad er unikt eller specielt ved hvert ER, når det sammenlignes med ER IKKE - Led efter forandringer (changes). Hvad er forandret i, på eller omkring hvert særpræg? 4) Evaluer mulige årsager Evaluer mulige årsager imod ER/ER IKKE i problem specifikationen. Hvis xxx er årsagen til yyy, hvordan forklarer det så både ER og ER IKKE informationen? Eliminer alle årsager der ikke kan forklare både ER og ER IKKE informationen. Husk at notere hvorfor en mulig årsag forkastes. 5) Bekræft den virkelige årsag Den mest sandsynlige årsag verificeres først. - Observer - Genskab problemet - Eksperimenter. Udfør en korrigerende handling og se om det afhjælper problemet - Hvad fortæller os at vi faktisk har fundet den rigtige årsag? - Vælg altid den sikreste, billigste, hurtigste eller letteste metode til at bekræfte årsagen J A N U A R

5 1. DEFINER PROBLEMET Hvilke services eller CI s har fejlen/afvigelsen? Hvilken fejl/afvigelse er der tale om? Hvad oplever vi, der fortæller os, at der er en fejl/afvigelse? 1 5. J A N U A R

6 2. SPECIFICÉR PROBLEMET ER HVAD Hvilke services/ci s har problemet? Hvad er galt med dem? HVOR Hvor er objektet med fejlen/afvigelsen observeret geografisk? Hvor på objektet ses fejlen/afvigelsen? HVORNÅR Hvornår er fejlen/afvigelsen først observeret? (dato/tid) Hvornår er fejlen/afvigelsen set igen? (dato/tid) Hvornår i objektets levetid ses fejlen/afgivelsen? OMFANG Hvor mange objekter er omfattet af fejlen/afvigelsen? Hvor stort er omfanget? Hvor mange afvigelser er der på objektet? Hvad er trendensen (konstant/voksende)? ER IKKE Hvilke lignende services/ci s kunne også have en fejl/afvigelse, men har det ikke? 1 5. J A N U A R I T S E R V I C E S Hvilke andre tendenser kunne der være, men er 6 det ikke? Hvilke andre lignende fejl/afgivelser kunne også have fundet sted, men gør det ikke? Hvor kunne det også være observeret, men er det ikke? Hvor ellers kunne fejlen/afvigelsen være på objektet, men er det ikke? Hvornår ellers kunne fejlen/afvigelsen være observeret første gang, men er det ikke? På hvilket andet tidspunkt kunne fejlen/afvigelsen være set, men er det ikke? På hvilket andet tidspunkt i objektets levetid kunne fejlen/afvigelsen være set, men er det ikke? Hvor mange objekter kunne have fejlen/afvigelsen, men har det ikke? Hvilken anden størrelse kunne afvigelsen have, men har det ikke? Hvor mange afvigelser kunne der være på objektet, men er der ikke?

7 3. IDENTIFICER MULIGE ÅRSAGER Baseret på faglig viden, erfaring, afsluttede changes/ændringer, samt tilgængelige materialer i logfiler, analyser m.v.. Mulige årsager /hypoteser Identificér mulige årsager Baseret på vores viden, hvad kunne være årsag til fejlen/afvigelsen? Anvend viden og erfaringer.. og/eller Brug særheder og ændringer til at udvikle mulige årsager Hvad er anderledes, specielt eller unikt i sammenligning mellem ER og ER IKKE Hvad er blevet ændret i, på, omkring eller i tilknytning til de enkelte forskelle mellem ER og ER IKKE? tidspunkt for ændring? Hvordan kan hver enkelt ændring have indflydelse på fejlen/afvigelsen? Hvordan kan en ændring + et specifikt særpræg på objektet forklare årsagen til fejlen/afvigelsen? Hvordan kan en ændring + en anden ændring have forårsaget fejlen/afvigelsen? 1 5. J A N U A R

8 4. EVALUER MULIGE ÅRSAGER Evaluer mulige årsager imod ER/ER IKKE i problem specifikationen Evaluer mulige årsager Test mulige årsager mellem ER og ER IKKE specifikationerne Hvis er årsagen til, hvordan forklarer det så både ER og ER IKKE situationen? Hvilke antagelser kan vi gøre? Udvælg den mest sandsynlige årsag Hvilken sandsynlige årsag forklarer bedst ER og ER IKKE informationen? Hvilken årsag har de færreste, mest simple og mest fornuftige antagelser? 1 5. J A N U A R

9 5. BEKRÆFT DEN VIRKELIGE ÅRSAG Den mest sandsynlige årsag verificeres først Bekræft den virkelige årsag Kontroller antagelser, observer og eksperimenter, eller prøv en rettelse og vurder resultatet Hvordan kan vi undersøge den antagelse vi har lavet? Hvordan kan denne årsag observeres når den optræder? Hvordan kan vi demonstrere relationer mellem årsag og effekt? Når korrigerende handling er udført, hvordan kan resultatet derefter kontrolleres? 1 5. J A N U A R