Processbeskrivning - Incident Management



Relevanta dokument
Processbeskrivning - Incident Management

Processbeskrivning Problem Management

Processbeskrivning Telefoni

Processbeskrivning Avveckling

Processbeskrivning Avrop

Processbeskrivning Systemutveckling

Processbeskrivning Configuration Management

Processbeskrivning Systemutveckling

Processbeskrivning Test

Processbeskrivning Projektstyrning

Processbeskrivning Uppdragshantering

Beskrivning IT- avdelningens processkarta

Processbeskrivning ITIL Change Management

Allmänna villkor. för Mina meddelanden. Bilaga 4 Servicenivåer (SLA) version 1.0 (Gäller fr.o.m )

Processbeskrivning Rekrytering

Processbeskrivning Systemförvaltning baserad på pm 3

Arbetsplatstjänsten / SUA

ÄNDRINGSPROCESS LÄNSTEKNIK

GRUND - SLA. Beslutsdatum Detta dokument syftar till att beskriva grund SLA vid Göteborgs universitet STYRDOKUMENT

Processbeskrivning Kvalitetsstyrning

Bilaga 1. Definitioner

Bilaga 4f Gemensamma processer Dnr: /

Roller och samverkansstruktur Kvalitetsstyrningsprocessen

Bilaga 4f. Gemensamma processer. Upphandling av IT-stöd för hantering av elevdokumentation inom Skolplattform Stockholm UTBILDNINGSFÖRVALTNINGEN

TJÄNSTEBESKRIVNING SERVICEDESK

Processbeskrivning Övervakning inom Operation Center

BILAGA 3 TJÄNSTENIVÅ SLA ÖVERENSKOMMELSE OM TJÄNSTENIVÅ

PIMM PROFECTO INFRASTRUCTURE MANAGEMENT MODEL ETT WHITEPAPER OM PIMM

ServIT ärendehantering och CRM

Processbeskrivning - Informationssäkerhet

Ändringsprocess för driftsättning Länsteknik

Checklista för Driftsättning - Länsteknik

Service Level Agreement mall för kommunalt IT-stöd

Bilaga 9. Överenskommelse om tjänstenivåer (SLA)

Upphandling 1-1 Datorer. Bilaga 4: Service Level Agreement (SLA)

TJÄNSTEBESKRIVNING APPLIKATIONSDRIFT

The Rational IT Model EN ENKLARE VÄG TILL IT SERVICE MANAGEMENT

PROCESSUTVECKLING IT ITIL FÖRBÄTTRAT ÄRENDEHANTERINGSSYTEM ANVÄNDARANVISNING

RUTIN FÖR DRIFTSÄTTNING

Avvikelsehantering statistikproduktion

ISO/IEC 20000, marknaden och framtiden

BILAGA 6 DEFINITIONER. Dokument och Ärendehanteringssystem Dnr: SUN 59/2013 Bilaga 6 Definitioner

Examinering i ITIL Foundation

Mobilt arbetssätt inom vård och omsorg Linköping UH

ITIL Service Management

Instruktion Stöd för processkartläggning i ett processorienterat arbetssätt för Region Skåne. Syfte

Bilaga, Definition av roller och begrepp, till policy för IT-säkerhet. Beslutsdatum (rev )

Bastjänsterna ovan avser driftfasen. Införandet genomförs som ett projekt som drivs av Cygate i samarbete med kunden.

Bilaga 11. Mall för leveransavtal

Uppdaterad Lathund Synpunkten för handläggare och ansvarig chef

Avtal Standard dator arbetsplats (SLA)

RUTIN FÖR PROCESSKARTLÄGGNING

Koncernkontoret Avdelningen för Digitalisering och IT

REFERENSMODELL FÖR IT SERVICE MANAGEMENT

Systemförvaltnings Modell Ystads Kommun(v.0.8)

Systemdrift och Systemförvaltning Centrala verksamhetssystem Service Desk

Serviceavtal, SLA och vad som är avtalat för PCarbetsplats. Kort om serviceavtal för arbetsplatstjänsten PC-arbetsplats

FDT Kundportal. Copyright FDT AB Köpmangatan LULEÅ. Försäljning Support Fax

Tjänsteavtal för ehälsotjänst

Användarhandledning Standardfaktura SEB imail 1.1 Standardfaktura

Bilaga, Definition av roller och begrepp, till policy för IT-säkerhet. Publiceringsdatum Juni 2007 ( rev. September 2011)

FÖRVALTNINGSGUIDE FGUIDE FÖR STOCKHOLMS STAD MODELLFÖRDJUPNING

SLA-användning i kommunerna

Rapport om Tyck till-tjänsten trafik- och utemiljö

Rammeverk: Rutin för intern uppföljning av korrigeringar i levererad statistik felrapportering

IT-tjänst Sammansatt Bastjänst Ekonomiskt Bistånd (SSBTEK)

Moment 3: Att kartlägga och klassificera information

Processer Vad är processer? Processhierarki

Sweden ICT Week. Avtala IT och möjliggör en god relation mellan verksamheten och IT. Anita Myrberg BiTA Service Management.

Service Desk Enkät Årliga kvalitetsundersökning HT07, HT08, HT09, HT10, HT11

TJÄNSTEBESKRIVNING SERVICE MANAGEMENT

RUTIN FÖR. Synpunktshantering. Ciceron. Kansli- och kvalitetschef. Antaget

Bilaga 9 Säkerhet Dnr: /2015 Förfrågningsunderlag

Riktlinjer för klagomål & synpunkter

Avtal om transmissionsprodukter Bilaga 6 Fel i Transmissionsprodukter

Processledningsmodell för Kungälvs kommun

Landstingets ärende- och beslutsprocess

Ärendehanteringssystem för Solna Stads Kundtjänst

effekt nu Kunskapsinitiativet

MMK. Intelligent ärende- och inventariehantering

Om ITSM-barometern. Vi hoppas att även du tycker att rapporten är intressant och att du vill delta även nästa år. Tack än en gång för ditt deltagande!

Modulen Anmälaren i BoWebb

Service management Samverkan och rapportering

Alice i underlandet. - Det beror på vart du vill komma. - Då spelar det heller ingen roll vilken väg du tar

Yttrande över stadsrevisionens rapport "Ensamkommande flyktingbarn (10/2013)

ADDING VALUE CONSULTING AB ITIL FOUNDATION KURS

Ansvar och roller för ägande och förvaltande av informationssystem

MANUAL ADVANIA LEDNINGSSYSTEM

Förstudie: Övergripande granskning av ITdriften

Projektplan: Nilex-projektet

Systemförvaltningshandbok

Bilaga 5 Administration och kontroll

Bilaga 2 Drift och Underhåll

BILAGA 3 - SUPPORT OCH KONTAKTER

Processorienterad arkivredovisning enligt RA-FS 2008:4

Handläggarmanual. Första sidan som öppnas då du öppnar ditt ärendehanteringssystem.

Skolinspektionens processorienterade arbetssätt

Webbformulär och ärendeväxel för Resplus restidsgaranti

Processbeskrivning Driftsättning

Visionen om en Tjänstekatalog

Transkript:

ProcIT-P-009 Processbeskrivning - Incident Management Lednings- och kvalitetssystem Fastställt av 2012-06-20

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[2.0].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, Uppsala universitet. 1.1 Symboler i processbeskrivningarna Nedanstående symboler används i processbeskrivningarna. Start Slut Markerar start resp slut i flöde delprocess s Logiskt avgränsad del av processen, omfattar en eller flera aktiviteter inflöde/ utflöde Inflöde, information, dokument, material som startar eller används i aktivitet/process Utflöde, dvs resultatet av aktivitet/process Aktivitet Beskriver vad som utförs Flödets riktning Parallella vägar i flöde Vägval Här tar flödet olika väg beroende på situationen Funktion/roll Incident_management_processen[2.0].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[2.0].doc 4(15)

Telefon & muntligt Mail Webbformulär Signal från övervakning Incident delprocess Management-processen Åtgärdad incident 2.1 Aktiviteter i Incident Management-processen Incident Management-processen (incidenthanteringsprocessen) består av följande aktiviteter: Telefon & muntligt Mail Webbformulär Tar emot, identifierar incident Loggar ärendet Kategoriserar ärendet Nej Kritisk Beställning? Prioriterar Tilldelar incident? Nej Analyserar tidigare incidenter & kända fel Utarbetar lösning, implementerar & dokumenterar lösning Verifierar lösningen Stänger ärendet Åtgärdad incident Signal från övervakning Ja Beställning delprocess Ja Funktionell eskalering Hanterar den kritiska incidenten Incident_management_processen[2.0].doc 5(15)

Förtydligande av aktiviteter i Incident Management-processen Tar emot, identifierar incident Ärendet tas emot och identifieras. 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 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. Incident_management_processen[2.0].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. 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. 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. Andra och tredje linjens support Incident_management_processen[2.0].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. 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. 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. Incident_management_processen[2.0].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. Telefon & muntligt Mail Tar emot och, registrerar ärendet Identifierar person, söker i behörighetssystemet Kategoriserar, statussätter, prioriterar, tilldelar ärende Kritisk incident? Stänger ärendet Åtgärdad incident Webbformulär Enkla ärenden Frågor - svar Stängt ärende Slut Ja Signal från övervakning Ansökan RFC etc Ja Nej Nej Hanterar den kritiska incidenten Andra linjens support Beställningar delprocess Arkiverade kontoansökningar Felsöker Åtgärdar felet Registrerar åtgärden Återrapporterar ärendet Kan lösa? Ja Verifierar att det fungerar Nej Tar ställning till vem ska hantera frågan Eskalerar ärendet Tredje linjens support Tar emot, felsöker Åtgärdar felet Registrerar åtgärden Återrapporterar ärendet Incident_management_processen[2.0].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[2.0].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[2.0].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 Tekniker Backup tekniker Incidentansvarig Verksamhetsansvarig IT Användarsupport Kundansvarig Användare Kunden 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[2.0].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 Incident_management_processen[2.0].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[2.0].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 s lednings- och kvalitetssystem, Rollbeskrivningar inom PVU (processorienterad verksamhetsutveckling) s lednings- och kvalitetssystem, Processbeskrivning - Kvalitetsstyrning 3 Processbeskrivning - Kvalitetsstyrning Incident_management_processen[2.0].doc 15(15)