INCIDENT & PROBLEM MANAGEMENT en eller to processer? thomas.fejfer@cfnpeople.dk 1
PÅSTAND Mange it-organisationer har vanskeligt ved at adskille Incident management og Problem management, hvilket ofte resulterer i, at organisationerne bliver reaktive. VÆSENTLIGE ÅRSAGER: ITIL good practice komplicerer processerne For meget fokus på processer og værktøjer, og for lidt fokus på praktiske metoder 2
EN ELLER TO PROCESSER? Jeg har et problem Problem Problem resolution INCIDENT MANAGEMENT? PROBLEM MANAGEMENT Jeg har et problem Incident Incident resolution IT ALLE ANDRE Problem PROBLEMLØSNING Midlertidig løsning Permanent løsning 3
MYTER Incidents bliver til problems, hvis de tager lang tid at løse. Incidents, der er vanskelige at løse, skal oprettes som problems. Det er kun i Problem management, at der er behov for at finde årsagen. It-specialister er som udgangspunkt gode til at løse komplekse/usædvanlige incidents og problems. 4
INCIDENT KONTRA PROBLEM MANAGEMENT PERFORMANCE BURDE AFVIGELSE (incident) Undgå en tilsvarende afvigelse i fremtiden (Problem management) Genoprette så sikkert, billigt og hurtigt som muligt (Incident management) FAKTISK FORTID NUTID FREMTID 5
HVORDAN LØSES INCIDENTS OG PROBLEMS? Indledende diagnosticering (support) Undersøgelse og diagnosticering 6
UNDERSØGELSE OG DIAGNOSTICERING - HVORDAN? ITIL Ingen hjælp Beskriver, hvordan incidents og problems kan styres, men ikke hvordan de løses Procesbeskrivelse Ofte baseret på ITIL derfor typisk ingen hjælp ITSM system Ingen hjælp Teknisk viden Lad os se lidt nærmere på den 7
UNDERSØGELSE OG DIAGNOSTICERING BASERET PÅ TEKNISK VIDEN Teknisk viden om løsning af incidents og problems begrænser sig til: teorien om, hvordan det virker, praktikken i at få det til at virke, de typiske måder, det kan fejle, og de typiske måder at løse det på. Det rækker i mange tilfælde, men det rækker ikke til løsning af komplekse/usædvanlige incidents og problems -de grå problemer 8
DE GRÅ PROBLEMER Service Desk 2./3. Level incidents 25 50 % 5 10 % Løst Løst teknisk problemløsning komplekse/ usædvanlige Konsekvens: Frq. af henvendelser fra brugerne om det specifikke problem falder Forretningen må tilpasse sig Skaber en tåge Ofte et forstadie til major incidents Kendetegn: Medium til lav prioritet Ustruktureret indsats (mavefornemmelse) vi skal lige prøve en ting mere det er for dyrt at løse eneste løsning er en opgradering det har ikke noget med os at gøre, fordi 9
ANTAGELSER Thinking, Fast and Slow by Daniel Kahneman 10
ESDH systemet er langsomt Når jeg har indtastet oplysninger i skema XYZ, så forsvinder informationerne, hvis jeg glemmer at gemme det, og så skal jeg indtaste oplysningerne igen. Det er ret irriterende. Hvad er det du oplever, når det er langsomt?.. 11
Netværket duer ikke Hvad er det du oplever, når netværket ikke duer? Jeg kan ikke sende e-mails Fra Outlook på min PC Ja, det kan jeg Hvilket program prøver du at sende e-mails fra? Kan du sende e-mail fra din webmail?.. 12
SITUATIONS- ANALYSE Hvad sker der? Klarhed og prioritet PROBLEM- ANALYSE Hvorfor skete det? Finde årsagen BESLUTNINGS- ANALYSE Hvad skal vi gøre? Træffe et valg ANALYSE AF POTENTIELLE PROBLEMER Hvad venter forude? Styre risici FORTID NUTID FREMTID 13
ITIL KONTRA KEPNER-TREGOE ITIL beskriver reelt intet om, hvordan man får overblik over situationen men det gør Kepner-Tregoe ITIL beskriver reelt intet om, hvordan man løser incidents og problems men det gør Kepner-Tregoe ITIL beskriver hvorfor og hvad, Kepner-Tregoe hvordan I et ITIL perspektiv er Kepner-Tregoe processerne at betragte som metoder Kepner-Tregoe metoderne kan med fordel anvendes til at forbedre alle ITIL processer Hvor ITIL er komplekst, er Kepner-Tregoe enkelt 14
SAMMENFATNING Forstå den grundlæggende forskel på IM & PM Manglende eller ineffektiv IM og PM er dyrt, irriterende, frustrerende At løse vanskelige/usædvanlige incidents hurtigt og effektivt kræver en metodisk tilgang At løse problems kræver ubetinget en metodisk tilgang Anvend Kepner-Tregoe til at skabe overblik og som problemløsningsmetode SPØRGSMÅL? 15