Proces for Problem Management

Transkript

1 Udarbejdet af: Service Management Proces for Problem Management Version: Igangsat den: 17/ et er at analysere driftsforstyrrelser (incidents) med den hensigt at finde den tilgrundliggende årsag (root cause) og registrere denne som en kendt fejl (know error). Ved at implementere varige løsninger eliminerer man tilbagevendende incidents, samt known errors, der har givet forstyrrelser på Region Syddanmarks IT platform. Definitioner Ord el. forkortelse Problem (PR) Root cause PPT Impact Urgency Interessent Trendanalyse Definition Er en Problemrecord, der beskriver en fejlsituation, som er omgået/løst, men hvor man har besluttet sig for at finde den egentlige årsag til problemet, hvorefter en permanent rettelse kan implementeres. Skrives herefter som PR. Er den egentlige årsag til en opstået fejl i IT miljøet. Problem Priority Team Angiver kompleksiteten og den forretningsmæssige konsekvens af problemet. Urgency bruges som et udtryk for vigtigheden af at et problem bliver løst. Alle som har en interesse i at vide, når der er opdateringer og fremdrift i en problemsag. Er en proaktiv handling med henblik på at eliminere tilbagevendende incidents. Roller og ansvar Rolle Proces owner Er ansvarlig for og ejer processen Er ansvarlig for omkostninger og investeringer i processen Udpeger Procesmanager Har ansvar for tværgående optimering og sammenhæng mellem processerne Er ansvarlig for godkendelse af procesændringer Proces Manager Rapportering af processtatus og fremskridt til medarbejdere og ledere Håndtering og evt. eskalering af tværgående spørgsmål Formidling af nye og ændrede politikker lig for evaluering af resultaterne af processen Oprettelse af målinger og mål for at forbedre processen og dens effektivitet Problem Initiator Rapportering af en PR ud fra major incidents eller trendanalyser Sikre at al relevant information jf. processen er til stede i recorden. Fastsættelse af urgency og impact

2 Problem Manager Daglig brugersupport Identifikation af afvigelser og efterfølgende initiering af PR er Afvise eller acceptere PR er som kandidat Sikre at standarder og procedurer følges Prioritere accepterede kvalificerede kandidater Udpege Problem owner Udarbejde, analysere og distribuere procesrapporter Er fokuspunkt for eskalation. Følge op på indsatsen fra alle udestående PR er for at sikre fremdriften i fejlløsningen. Sikre review af PR er Lukke alle PR er Identificere og gennemføre procesforbedringer Problem Priority Team (PPT) PPT mødet afholdes 1 gang pr. uge og giver støtte til Problem Manager med at tage stilling til: Prioritering af accepterede PR kandidater Udpegning af Problem owner Derudover opfølgning på alle prioritet 1 og 2 problemer Problem Queue Monitorere sin indkø med de tildelte PR er Manager Styre ressourceallokering, dvs. udpege en Problem analyst Problem owner lig for den overordnede håndtering af et specifikt problem Sikre at der inddrages relevante analysts/specialister efter behov. Følge op på fremdriften på de PR er man ejer. Sikre at problemet bliver løst Problem Analyst Udføre root cause analyser Sikre information til relevante interessenter Ajourføre PR med root cause og permanent løsningsinformation Evt. iværksætte workaround Installere en permanent rettelse af problemet via en RFC Ved lukning sikre at information om årsag, fejlløsning og dokumentation er tilstede i PR. Proces owner Afdelingschef IT, It-Drift Region Syddanmark Side 2 af 12

3 Incident Known error Data fra CMDB Ekstern dokumentation Intern dokumentation Servicemål Prioriteringsliste Incidentprocessen Knowledge base i Problem værktøjet Configuration Management Knowledge base i Problem værktøjet Service Level Management Problem værktøjet Problem record Information til linteressenter Implementeringsplan Dokumentation af procesforløbet af en PR Dokumentation Dokument Problem Processen Instrukser Rapporter PPT-referater Modtager Ledelsesrapportering Ledelsen Opdaterede PR er IT Workaround Incident Management Initering af RFC Change Management Dokumentation af Incident- og Problem Management known error Initering af Ledelsen projekt Placering X:\IT\Fælles\~Kvalitetsstyring - 46 processer - ISO 9001\Processer\Problem Management\Problemprocessen X:\IT\Fælles\~Kvalitetsstyring - 46 processer - ISO 9001\Processer\Problem Management\Instrukser X:\IT\Fælles\~Kvalitetsstyring - 46 processer - ISO 9001\Processer\Problem Management\Rapporter X:\IT\Fælles\~Kvalitetsstyring - 46 processer - ISO 9001\Processer\Problem Management\PPT referater Ligger i værktøj Ligger i værktøj Ligger i værktøj Ligger i værktøj (tidsstempler, brugerid er, mail-dialoger, statusskift) Side 3 af 12

4 Procesfaser Fase Beskrivelse 1 Registrering af PR Problem Initiator udfylder PR. 1. Retningslinje initiering af PR 2 Accept af kandidat Problem Manager foretager en vurdering af den fremsendte Problem kandidat, om det reelt er et problem. Hvis ja, foretages en prioritering og evt. igangsættelse af analyse. I øjeblikket vil opgaven blive udført af et Problem Priority Team (PPT), som består af lederteamet samt Problem Managers. 2. Retningslinje for accept af kandidat 3 Problem assignment Problem Queue Manager overvåger i Problem værktøjet den kø, som vedkommende er ansvarlig for og uddelegerer en PR til en person med de rigtige kompetencer. 3. Retningslinje for Problem assignment 4 Problemanalyse Problem analyst og Problem owner er ansvarlig for forløbet i denne analysefase. Problem owner har det overordnede ansvar. Problem Analyst er den daglige driver på at finde fejlårsagen. 4. Retningslinje for Problemanalyse 5 Problemfejlretning Inden en egentlig fejlrettelse skal analyst, problem owner, problem manager og eventuelt andre vurdere, hvilken fejlløsning der skal bruges. Når det besluttes at gennemføre en fejlrettelse er det Problem analyst og Problem owner, der er ansvarlig for at få rettelsen til en funden root cause implementeret. 5. Retningslinje for Problemfejlretning 6 Lukning af en PR Problem Manager validerer at den fundne og implementerede løsning også har den ønskede virkning, samt at alle nødvendige informationer er til stede i PR en. Herefter lukkes den. 6. Retningslinje for lukning af en PR Side 4 af 12

5 KPI Mål lig Målefrekvens Alle PR er hos en Problem Queue Manager Problem Løbende (pr. KPI01 skal være assigned videre til en Problem Analyst senest tre arbejdsdage efter den er lagt i køen. Manager måned) KPI02 Alle PR er hos en Problem Analyst skal være sat i status Påbegyndt inden tre arbejdsdage fra den er lagt i vedkommendes personlige kø. lige for at det sker, er Problem owner og Problem Analyst Problem Manager Løbende (pr. måned) 1. Retningslinje for initiering af PR Retningslinjen sikrer at en PR oprettes korrekt, bliver klassificeret rigtigt og at Initiator opretter PR en ud fra gældende regler. Definitioner Ord el. forkortelse Utilsigtet hændelse Definition Ved utilsigtet hændelse forstås på forhånd kendte og ukendte hændelser og fejl, som ikke skyldtes patientens sygdom, og som enten er skadevoldende eller kunne have været skadevoldende. En utilsigtet hændelse omfatter en begivenhed, der forekommer i forbindelse med sundhedsfaglig virksomhed. Det kunne f.eks. være en hændelse af It-mæssig karakter. Roller og Rolle ansvar Problem initiator Korrekt udfyldelse af PR en N/A PR i status Kandidat Modtager Problem Manager Dokumen- Dokument Placering tation PR I værktøj Side 5 af 12

6 Trinnummer Beskrivelse 1 Spore (opdage) og logge problem Modtage/opsamle incident input (kvalificering af data) - overvågning / driftsdata - trendanalyser Større incident med prioritet 1 eller 2 - Her skal det nøje overvejes om en PR skal oprettes, så root cause kan blive fundet Undersøge om problemet allerede er registreret i problemværktøjet Oprette en PR 2 Kategorisere og prioritere problem Katagorisere PR en ud fra Impact, urgency og prioritet. Se bilag: Matrix for beregning af prioritet 3 Udfylde problemrecord med relevant information Udfylde fanebladet Problem Udfylde fanebladet Relaterede records - Relatere oprettede incidents, problems eller evt. changes, som har sammenhæng med det aktuelle problem 4 Afslutte oprettelsen af en PR Bruge route workflow i værktøjet: - Sende problemrecord til Problem Manager - Annullere PR (Stop problem) Bilag: Impact tabel Impact tabel Impact High Medium Low Bilag: Urgency tabel Urgency tabel Urgency High Medium Low Betydning Forretningskritisk service ramt eller alle brugere berørt Betydningsfuld service ramt eller større antal brugere berørt Mindre betydningsfuld service ramt eller mindre antal brugere berørt Betydning Stor risiko for at fejl genopstår eller at fejlen stadig resulterer i performancenedgang på kritisk system Lille risiko for at fejl genopstår eller at fejlen generelt har mindre forretningskonsekvens for brugerne Gentagne, - men mindre betydende fejl, hvor der er værdi i at løse dem. Bilag: Matrix for beregning af prioritet Side 6 af 12

7 Urgency Urgency Urgency high medium low Impact high Impact medium Impact low Retningslinje for accept af kandidat Kvalitetssikring af at en oprettet PR reelt er en PR og ikke et incident. Endvidere prioritering og efterfølgende tildeling til en Problem owner. Roller og ansvar Rolle Problem Manager PPT At accptere en PR samt prioritere og tildele det til et funktionsområde At støtte Problem Manager i prioritering og tildeling af PR er. Problem initiator It-drift RSD Kandidat Afvist Kandidat accepteret Godkendt (Problem owner udpeget) Modtager Problem initator Problem Manager og evt. PPT Problem Queue manager Dokumen- Dokument Placering tation PR I værktøj Trin Trinnummer Beskrivelse 1 Godkende eller afvise PR på baggrund af en Side 7 af 12

8 samlet vurdering. Herunder tage stilling til følgende: - Er PR en udfyldt med alle relevante informationer i de krævede felter? - Er Prioriteten korrekt fastsat? - Er det mere end en enlig hændelse? (som ellers udelukkende bør blive håndteret via incidentprocessen) - Har der været nedbrud med konsekvenser for kunden? Hvis der vurderes at PR en opfylder ovennævnte og at der ikke kun er tale om et incident, skal PR en accepteres, ellers afvises den. 2 Foretage prioritering og tildeling af en PR Problem Manager prioriterer og fordeler med evt. støtte fra PPT, som der bliver afholdt ugentlige møder med. Prioriteringen foretages ud fra følgende: - Hvilken prioritet der er sat af initiator - Hvilken impact og urgency ligger bag Tildeling til et område foretages ud fra følgende: - Generel information i PR en givet af initiator - Hvem var fejlløser da fejlen blev håndteret - Anden viden om fejlen fx mail, intranet osv. Når ovenstående er på plads bliver PR en assigned til Problem Queue Manager for det funktionsområde (Problem owner), der skal analysere problemet, og der gives automatisk informationer til Problem owner og Problem initiator. 3. Retningslinje for Problem Assignment et er at få en PR assigned til en Problem Analyst, der skal arbejde videre med Root Cause Analyse. Roller og ansvar Rolle Problem Queue Manager Tildele PR er fra køen til Problem Analyst s med de rigtige kompetencer. Der skal være fokus på køen mindst én gang om dagen på arbejdsdage. PR i status Problem Manager Side 8 af 12

9 Godkendt (Problem owner udpeget) PR i status Tildelt (Problem analyst udpeget) Modtager Problem Analyst Dokumen- Dokument Placering tation PR I værktøj Trin Trinnummer Beskrivelse 1 Problem Queue Manager tildeler en PR på baggrund af en samlet vurdering. En PR skal være tildelt en analyst i henhold til KPI01 Det forventes at der er fokus på denne kø mindst én gang hver arbejdsdag. Herunder tages stilling til følgende: Er PR en rigtigt tildelt af Problem Manager eller er det en fejl. Hvis det er en fejl, så assignes problemet til et andet funktionsområde med begrundelse. Hvis det er korrekt fortsættes herunder: Er nogen specifikke teknikere nævnt i PR en? Hvilke kompetencer er der i området? Hvilke kompetencer har tid, - i forhold til prioriteringen? Herefter tildeles PR en til en Problem Analyst, der kan se sagen i sin personlige kø. 4. Retningslinje for Problemanalyse At finde root cause til det rapporterede problem Roller og Rolle ansvar Problem analyst Er den daglige driver på fejlsøgningen Side 9 af 12

10 Problem owner Har det overordnede ansvar for fremdrift i sagen, samt at de rigtige ressourcer og kompetencer er tilstede. PR i status Tildelt Problem Queue Manager Known error Modtager Known error databasen Dokumen- Dokument Placering tation PR I værktøj Trin Trinnummer Beskrivelse 1 Teknikere skal holde øje med, om de bliver tildelt PR er, hvilke de skal starte analyse på i henhold til KPI02 Acceptere PR en og starte analyse. 2 Undersøgelse og diagnosticering udføres. Der kan være flere gennemløb på de metoder, som den enkelte afdeling har valgt at bruge i deres fejlsøgning. Der undersøges om der allerede findes en Known error med relevans for den aktuelle PR. Hvis problemet under denne fase stadig giver alvorlige incidents, så kan det være nødvendigt at implementere midlertidige løsninger (work-arounds) 5. Retningslinje for Problemfejlretning At sikre at der sker en vurdering af hvilken fejlløsning man vil bruge, og efterfølgende implementere den valgte løsning. Roller og ansvar Rolle Problem analyst Vurderer løsninger og vælger hvilken der skal bruges. Problem owner Vurderer løsninger og vælger hvilken der skal bruges. Problem manager Vurderer løsninger og vælger hvilken der skal bruges. Interessenter Vurderer løsninger og vælger hvilken der skal bruges. Kan evt. være account manager, Side 10 af 12

11 systemejer, ledelsen osv. Fundet Root cause Problem analyst RFC Løst PR Modtager Changeprocessen Problem manager Dokumentation Dokument PR RFC Placering I værktøj I værktøj Trin Trinnummer Beskrivelse 1 De involverede parter vurderer root cause og den fejlløsning, der er foreslået og beslutter om: Der kun skal implementeres en work-around, og lader den blive en Known error Der skal implementeres en permanent løsning - forbehold er dog at løsningen er for dyr og/eller kompliceret, så man lever med work-arounden, hvilket så er beslutningen. 2 Den valgte løsning fra trin 1 implementeres i en RFC 3 Efter implementering af RFC opdateres PR en med status. Herefter gøres følgende: Hvis implementeringen af RFC skete som planlagt, er problemet løst. Hvis implementeringen fejlede, så skal PR sendes tilbage til Problem analyst, der herefter arbejder videre med fejlløsningen. 6. Retningslinje for Lukning af PR At sikre at den valgte løsning er implementeret som planlagt og har den ønskede virkning. Roller og ansvar Rolle Problem manager Vurderer valgt løsning og lukker PR Side 11 af 12

12 PR i status LØST Problem analyst Lukket PR Modtager Problem manager samt interessenter jf. listen i PR. Dokumentation Dokument PR RFC Placering I værktøj I værktøj Trin Trinnummer Beskrivelse 1 Hvis der var foreslået flere løsninger til at håndtere Root cause, - så valideres det om den valgte løsning stadig er den rigtige. 2 Er der gennemført en RFC, skal der tjekkes at den blev gennemført succesfuldt: Viser implementeringskoden at ændringen blev gennemført som planlagt? Har test- og verifiktionsplanen været god nok, så det er sikkert at den/de rapporterede fejl i PR en er elimineret? - Vurdering af om der i beskrivelsen i PR en er basis for at kontakte brugere for yderlige test. - Er der relateret højt prioriterede incidents til PR en, der kræver at man tester med bestemte brugere? 3 Validering af data: Validér beskrivelserne i Symptom, Årsag, Løsning og Workaround, hvis en sådan findes. Bemærk: Hvis PR er markeret som Known error, er beskrivelserne i Årsag og Workaround meget værdifulde, da de vil kunne være grundlag for fremtidige analyser. 4 Videre forløb efter review Hvis der er udestående i trin nr. 1, 2 og 3, forelægges de for Problem Analyst for at få dem afklaret. Hvis/når alt i trin nr. 1,2 og 3 er afklaret positivt, - så kan PR lukkes. Side 12 af 12