ProcIT-P-009 Processbeskrivning - Incident Management Lednings- och kvalitetssystem Fastställt av 2011-06-30
Innehållsförteckning 1 Inledning 3 1.1 Symboler i processbeskrivningarna 3 2 Incident Management-processen 4 2.1 Aktiviteter i Incident Management-processen 5 2.2 Beskrivning av den funktionella eskaleringen av ärenden 9 2.3 Hierarkisk eskalering av incidenter 12 2.4 Mätning av Incident Management-processen 12 3 Intressenter 13 4 Roller 13 5 Mallar/Checklistor/Verktyg 13 6 Ordlistor och definitioner 14 6.1 Ordlista för processbegrepp 14 6.2 Ordlista för Incident Management-processen 15 7 Förvaltning av processen 15 8 Referenser 15 Incident_management_processen.doc 2(15)
1 Inledning Detta dokument beskriver en generell incidenthanteringsprocess som stödjer alla som arbetar med incidenter. Mer specifika rutiner för olika grupper av sådana handläggare dokumenteras separat. För ordlistor och definitioner, se avsnitt 6. Syfte med processdokumentet Dokumentets syfte är att beskriva Incident Management-processen (incidenthanteringsprocessen). Målgrupper för processdokumentet Dokumentets målgrupper är alla som arbetar med incidenter. Omfattning för processdokumentet Processdokumentet gäller för avdelningen IT och inköp. 1.1 Symboler i processbeskrivningarna Nedanstående symboler används i processbeskrivningarna. Incident_management_processen.doc 3(15)
2 Incident Management-processen En incident är en händelse som gör att en tjänst är helt eller delvis otillgänglig. Incident Management-processen (incidenthanteringsprocessen) ansvarar för att så snabbt som möjligt hitta en åtgärd som återställer tjänstens tillgänglighet. Syfte Syftet med processen är att hantera incidenterna så att verksamheten påverkas så lite som möjligt av incidenten. Mål Målet med processen är att återställa tjänsten till normalt läge så fort som möjligt. Omfattning Incident Management-processen (incidenthanteringsprocessen) omfattar alla händelser som stör eller kan störa en tjänst oavsett om det är användaren som rapporterar incidenten eller om incidenten upptäcks av en tekniker inom driften. Starthändelser De starthändelser som sätter igång processen är: Mail Telefonsamtal Personliga besök Anmälningar via webb Signaler från övervakning Resultat Processen resulterar i att incidenten har hanterats och normalläget är återställt och att användaren/kunden är informerad. Inflöden Ärenden Dokument Checklistor Beställning t.ex. ansökan om konton Utflöden Löst dokumenterad incident Färdigbehandlad incident Återkoppling till kund Incident_management_processen.doc 4(15)
2.1 Aktiviteter i Incident Management-processen Incident Management-processen (incidenthanteringsprocessen) består av följande aktiviteter: Incident_management_processen.doc 5(15)
Förtydligande av aktiviteter i Incident Management-processen Tar emot, identifierar incident Ärendet tas emot och identifieras. Ansvarig. Loggar ärendet Alla incidenter loggas. I loggningen ingår vem som är användare/kund, beskrivning av ärendet och tidpunkt för mottagningen av incidenten. Detta gäller oavsett om incidenten kommer in via helpdesk eller upptäcks inom driften. Information som ska finnas med i ett ärende: Ärendenummer Kontaktperson och kontaktuppgifter Kategori av ärende Prioritering Datum och tid Ärendebeskrivning Status för ärendet Ansvarig. Kategoriserar ärendet En del i loggningen är att kategorisera ärendet. Kategoriindelningen är en fast lista på de tjänster som huvudsakligen berörs. Kategoriindelningen är viktig för att kunna generera olika typer av statistik. Om ärendet avser små beställningar med låg risk, exempelvis byte av lösenord, installation av ny programvara och frågor tydliggörs detta i delprocessen beställningar. Ärenden kategoriserade som beställningar ska inte komma med i statistik över incidenter. Arbetsgången för att hantera beställningen kommer att se lite olika ut beroende på vad beställningen avser. Den stora skillnaden mellan beställningsärenden och incidenter är att beställningar är något som kan och ska planeras medan incidenter är oplanerade händelser. Ansvarig. Incident_management_processen.doc 6(15)
Prioriterar Prioritering av varje ärende görs efter vilken påverkan incidenten har på tjänsten och hur brådskande det är att lösa incidenten. Prioritering görs i 4 nivåer, nivå 1 är den mest kritiska. 1. Kritisk 2. Hög 3. Medel 4. Låg Prioriteringen styrs utifrån tjänstenivåavtalen (SLA) som finns med kunden. Är det fråga om en kritisk incident ska incidenten hanteras enligt avsnitt 2.3 Hierarkisk eskalering av incidenter. Nedanstående schema illustrerar de 4 prioriteringsnivåerna. Ansvarig. Funktionell eskalering och Hantera den kritiska incidenten Se avsnitt 2.2 med förtydligande av aktiviteterna. Tilldelar Antingen tilldelar mottagaren ärendet till sig själv, om denne inte klarar att lösa incidenten så tilldelas ärendet till någon annan (funktionell eskalering) inom gruppen eller andra grupper. Ansvarig. Första och andra linjens support Analyserar tidigare incidenter och kända fel Om incidenten har kommit in via helpdesk måste en initial analys göras där för att få en så klar bild av incidenten som möjligt. Det är i detta läge den lagrade informationen används på tidigare beskrivna incidenter och deras lösning, information om kända fel samt information om workaround. Ansvarig. Andra och tredje linjens support Incident_management_processen.doc 7(15)
Utarbetar lösning, implementerar och dokumenterar lösning När en lösning har utarbetats ska den implementeras. Att dokumentera incidenten och åtgärden som genomförts för att lösa incidenten ger viktig information när nya incidenter kommer in och bidrar till att man då snabbt kan lösa dem. Det är också ett viktigt inflöde till Problem Management-processen (Problemhanteringsprocessen). Dokumentationen ska vara utformad på ett sådant sätt att den kan återrapporteras till kund och lätt återsökas. Ansvarig. Andra och tredje linjens support Verifierar lösningen Det ska göras en verifiering att ärendet är löst. För användarinitierade incidenter kan det ibland vara svårt att praktiskt göra denna verifiering, då görs det genom att ett automatmail skickas till användaren där man informerar om att ärendet kommer att avslutas inom t.ex. 48 timmar om inte användaren återkommer i ärendet. Övriga incidenter verifieras av den som äger ärendet. Ansvarig. Första och andra linjens support Stänger ärende Användarinitierade ärenden stängs av helpdesk när en avstämning har gjort med användaren att det är ok att stänga ärende. Ansvarig. Incident_management_processen.doc 8(15)
2.2 Beskrivning av den funktionella eskaleringen av ärenden Nedan beskrivs hur den funktionella eskaleringen av ärenden görs mellan första, andra och tredje linjens support. Incident_management_processen.doc 9(15)
Förtydligande av aktiviteter i Beskrivning av den funktionella eskaleringen av ärendet Tar emot och registrerar ärendet Besvarar inkommande telefonsamtal och registrerar nytt ärende i helpdesksystemet eller öppnar ärende som skapats av inkommande e-post eller registrering i webbformulär. Identifierar person, söker i behörighetssystemet Kontrollerar i behörighetssystemet vem som anmält ärendet. Kategoriserar, statussätter, prioriterar, tilldelar ärende Klassificera ärendet utifrån vilken tjänst det gäller, sätter aktuell status, avgör ärendets prioritet och skickar det till lämplig grupp av handläggare. Enkla ärenden Frågor svar Avgöra om ärendet är en enkel fråga som kan besvaras direkt, samt besvara den. Hantera den kritiska incidenten Vidtar åtgärd som åter gör tjänsten tillgänglig. Informerar enligt rutin. Andra och tredje linjens support, incidentansvarig Felsöker Försöker hitta en åtgärd som kan avhjälpa incidenten. Andra linjens support Tar ställning till vem ska hantera frågan Avgör vem i tredje linjen som skall felsöka vidare. Andra linjens support Eskalerar ärendet Skickar ärendet vidare till en grupp handläggare i tredje linjen. Andra linjens support Tar emot, felsöker Öppnar ärendet i helpdesk systemet och försöker hitta en åtgärd som kan avhjälpa incidenten. Tredje linjens support Incident_management_processen.doc 10(15)
Åtgärdar felet Vidtar åtgärd som åter gör tjänsten tillgänglig. Andra och tredje linjens support Registrerar åtgärden Skriver ned åtgärden i helpdesksystemet. Andra och tredje linjens support Återrapporterar ärendet Kontaktar den som anmält incidenten och meddelar att den nu är åtgärdad. Stänger ärendet Verifierar med anmälaren att tjänsten fungerar och markerar ärendet som avslutat. Incident_management_processen.doc 11(15)
2.3 Hierarkisk eskalering av incidenter När det är fråga om en kritisk incident, måste incidentansvarig vara väl informerad. Här är det mycket viktigt att rätt information snabbt når ut till rätt grupper. Den hierarkiska eskaleringen av incidenter kan också komma ifråga om det tar allt för lång tid att lösa ärendena och det kan behöva fattas beslut om att fler resurser ska sättas in för att lösa uppgiften. Vid kritiska incidenter (prioritet 1 incidenter) är det extra viktigt att kommunikationsprocessen fungerar effektivt, dels inom avdelningen men också kommunikationen med kunder och användare av tjänsten som drabbats. Vid kritiska incidenter ansvarar incidentansvarig för att koordinera samtliga incidentaktiviteter. Incidentansvarig ska se till att de tekniker som ska åtgärda incidenten får arbeta i lugn och ro. All kommunikation och information ska gå via incidentansvarig och denne ska säkerställa att alla parter fått relevant information. Informationen till användarna prioriteras för att minska belastningen på användarsupport. Informationsflöde vid en kritisk incident 2.4 Mätning av Incident Management-processen Det görs en uppföljning av antal ärenden av olika kategorier över tiden. Mätningen av processen ska ske på: Genomloppstiden - tiden från ärendet inkommer till det är löst och avslutat Svarstider hur lång tid det tar att få svar via telefon och mail Väntetiden tiden mellan att ärendet inkommit och man börjat arbeta med ärendet Kundnöjdhet Mätningen ger ett underlag för att förbättra processen. Incident_management_processen.doc 12(15)
3 Intressenter För definition av intressent, se ordlista för processbegrepp under avsnitt 6, Ordlistor och definitioner. Studenterna Anställda på universitetet Möjliga studenter Övriga användare av våra system 4 Roller För definition av roll, se ordlista för processbegrepp under avsnitt 6, Ordlistor och definitioner. För rollbeskrivningar, se 1 I dag är 1:a och 2:a linjens support ofta samma person och den som har kontakt med användarna. Incidentansvarig Arbetsledning Andra linjens support Tredje linjens support 5 Mallar/Checklistor/Verktyg Mallar och övrigt stödmaterial finns i ärendehanteringssystemet Easit Manager Suite. Övrig externinformation kring incidenthantering kommer att finnas på webben. Befintligt stöd Wiki FAQ i helpdesksystemet Sharepoint 1 Rollbeskrivningar inom IT och inköp Incident_management_processen.doc 13(15)
6 Ordlistor och definitioner 6.1 Ordlista för processbegrepp Begrepp Aktivitet Delprocess Huvudprocess Intressent Kärnprocess Process Processparameter Processansvarig Roll Rollbeskrivning Starthändelse Styr- och stödprocess Definition Lägsta nivån i processhierarkin. En serie logiskt sammanhängande handlingar som en person eller roll utför, utförs på ett sätt. 2 En delprocess är en logiskt avgränsad del av en huvudprocess, kan finnas på flera nivåer. 2 Huvudprocesser är den högsta nivån av processer i en verksamhet. Kan vara både internt och externt värdeskapande. 2 Någon som tar emot något från processen eller levererar något till processen. 2 Externt värdeskapande process. Kärnprocesser uppfyller verksamhetens övergripande syfte att tillfredsställa kundernas verkliga behov - varför verksamheten existerar. 2 En process är ett flöde av sammanhängande aktiviteter som skapar ett förutbestämt resultat. Processen har alltid kunder - interna eller externa. 2 Processparameter är det mått som används för att mäta och styra processen. 2 En person utsedd av ledningen för att ansvara för att processen som helhet både är effektiv och ändamålsenlig. 2 En roll är knuten till en process. Varje roll har ansvar att leverera ett resultat i processen. En person kan inneha flera roller och samma roll kan innehas av flera personer. 2 En beskrivning av de roller som är knutna till processen. I rollbeskrivningen ingår att beskriva rollens ansvar och befogenhet. 2 Med starthändelser avses händelser som får processen att reagera på ett förutbestämt sätt. Det finns tre typer av starthändelser: tidsstyrd starthändelse, händelsestyrd starthändelse och värdestyrd starthändelse. Internt värdeskapande processer. Har till syfte att styra och stödja kärnprocesserna 2. Värdeskapande, värdeadderande Aktiviteten tillför värde till slutkunden 2. 2 PVU (processorienterad verksamhetsutveckling) Incident_management_processen.doc 14(15)
6.2 Ordlista för Incident Management-processen Begrepp Incident ITIL Känt fel Workaround Hierarkisk eskalering Funktionell eskalering (tilldelning) Tjänstenivåavtal (SLA) Ärende Definition En oplanerad händelse som leder till avbrott eller störning i en tjänst eller en reduktion av kvalitén av tjänsten eller en uppenbar risk att det blir en störning. IT Infrastructure Library (ITIL) är ett ramverk bestående av best practice som beskriver olika IT- processer som kan realiseras inom en organisation för att få en hög kvalitet på IT-tjänsterna och för att effektivisera leveransen och supporten av tjänsterna. ITIL utgår från ett tjänste- och kundperspektiv. Ramverket togs fram av den brittiska myndigheten Central Computer and Telecommunications Agency (CCTA) i syfte att skapa gemensamt arbetsätt inom IT för de för olika myndigheterna. Ett problem som har en känd grundorsak och en workaround En åtgärd som har till syfte att minimera konsekvenserna av en incident eller ett problem där det ännu inte finns någon fullständig lösning. När det är fråga om en allvarlig incident eller där ärenden tar för lång tid, eskaleras ärenden till ansvarig roll som vidtar åtgärder. När incidenten inkommit måste den tilldelas antingen till personer inom helpdesk eller till personer i andra och tredje linjens support. Service Level Agreement. En överenskommelse mellan en IT-tjänsteleverantör och en kund. En överenskommelse om tjänstenivå beskriver ITtjänst, dokument och riktmärke för tjänstenivån samt specificerar IT-tjänsteleverantörens och kundens respektive ansvar. Ett avtal kan täcka flera ITtjänster eller flera kunder. Ett ärende kan vara en incident men det kan också vara en beställning eller en förfrågan. 7 Förvaltning av processen För förvaltning och förbättring av processen och dess dokument se vidare 3. 8 Referenser IT och inköps lednings- och kvalitetssystem, Rollbeskrivningar inom IT och inköp PVU (processorienterad verksamhetsutveckling) IT och inköps lednings- och kvalitetssystem, Processbeskrivning - Kvalitetsstyrning 3 Processbeskrivning - Kvalitetsstyrning Incident_management_processen.doc 15(15)