proces for incident management - regionsyddanmark.dk file3) definitioner 4) roller og ansvar 5)...
TRANSCRIPT
Regionen - It-stabens Kvalitetshåndbog - 7 Drift - 7.01 Incident Management
Proces for Incident Management
Niveau: Proces
Godkendt af: LKH 27.10.2010
Dokumentbrugere: ITS
Forfatter: kah7id
Dokumentansvarlig: Afd. chef
DokumentID / Dokumentnr.69275 / p 7.1.1
Version: 1
1) Indledning2) Formål3) Definitioner4) Roller og ansvar5) Politikker6) Input7) Output8) Procesdokumentation9) Diagram10) Procesaktivitet11) Procesmål12) KPI'er
1) Indledning
Incident Management er den proces (arbejdsgang), som behandler alle Incidents og Service Requests. Disse kan omfatte fejl, spørgsmål eller forespørgsler rapporteret af brugere til service desk, af teknisk personale, eller automatisk opdaget og rapporteret af overvågningsværktøjer.
Incident Management kan sammenlignes med et formel 1 pit stop. Hvis man har et Incident (fejl), så vil man ikke fokusere på, hvorfor den opstod, men i stedet forsøge at fjerne symptomerne så hurtigt som muligt. Fjernelse af årsagen er ikke en del af Incident Management, men henhører under Problem Management.
2) Formål
Formålet med Incident Management er at genoprette aftalt service så hurtigt som muligt og udføre bestillinger.
It-stabens Kvalitetshåndbog Udskrevet er dokumentet ikke dokumentstyret.
Proces for Incident Management, ver. 1, DokID: 69275 Side 1 af 27
3) Definitioner
Ord el. forkortelse
Definition (ITIL)
Bruger En person der anvender en it-service. Impact Et udtryk for hvordan et Incident, Problem eller en
Change påvirker forretningsprocesser. Impact tager ofte sit udgangspunkt i indvirkningen på Service Levels. Impact anvendes sammen med Urgency(se nedenfor) til tildeling af prioritet.
Incident En ikke planlagt afbrydelse af en it-service eller reduktion i kvaliteten af it-servicen. Fejl i et Configuration Item, der endnu ikke har haft konsekvenser for servicen er også et Incident. Som eksempel kan nævnes fejl på én enkelt spejlet disk.
Major Incident Et Incident der har en meget stor påvirkning på forretningen. Se iøvrigt processen for Major Incident for yderligere forklaring.
Prioritet En kategori, der anvendes til at identificere den relative vigtighed af et Incident, Problem eller en Change. Prioritet baseres på Impact og Urgency, og den anvendes til at identificere de tidspunkter, hvor det er nødvendigt at gøre noget. F.eks. kan en SLA fastslå, at et prioritet 2 Incident skal løses indenfor 12 timer.
Security Incident Et Incident som har brudt eller truer it sikkerheden. Dette kan være indenfor følgende områder: 1. Fortrolighed (En PC der forsvinder, mistanke om
utilsigtet adgang til personfølsomme data) 2. Integritet (Hvis der konstateres eller er mistanke
om manipulation med information, fx ændring af indhold på websider)
3. Tilgængelighed (Eksempelvis utilgængeligt e-mail system pga. spam angreb)
Service Request En anmodning fra en bruger om information, rådgivning, eller adgang til en it-service. F.eks. om at nulstille et password eller om at levere en standard it-service til en ny bruger. Service Requests håndteres normalt af Service Desk, og kræver ikke en RFC for at blive iværksat.
Urgency Et mål for hvor lang tid det varer, før et Incident, Problem eller en Change får en væsentlig Impact for forretningen. F.eks. kan et Incident med stor Impact have en lille Urgency, hvis konsekvensen ikke har betydning for forretningen før årsafslutningen. Impact og Urgency anvendes til prioritering.
Workaround Det at reducere eller eliminere Impact af et Incident eller Problem, hvortil der ikke endnu findes en fuldstændig resolution. F.eks. genstart af et fejlramt Configuration Item. Workarounds for Problems dokumenteres i KnownErrorRecords. Workarounds for Incidents, som ikke er associeret med Problem Records, dokumenteres i Incident Records.
4) Roller og ansvar Rolle Ansvar Bruger � Brugeren er ansvarlig for at anvende services i
henhold til gældende bestemmelser, samt melde fejl til superbruger eller Service Desk så snart en sådan konstateres.
Dispatcher
Proces for Incident Management, ver. 1, DokID: 69275 Side 2 af 27
� Prioriterer og fordeler sager. Incident Manager � Kvaliteten i den daglige udførsel af Incident
Management processen. � Følge op på Incidents, agere proaktivt og sikre, at der foretages en korrekt behandling heraf.
� Vurdere Incidents mhp. at overdrage ansvaret for specifikke og specielt kritiske Incidents til Major Incident Manager.
Major Incident Manager
� Major Incident Manager inddrages i tilfælde af et Major Incident og vurderer sammen med Incident Manager, hvorvidt Incidentet skal behandles som et Major Incident.
� Ved Major Incident og ”MI arbejdsgrupper” er Major Incident Manager ansvarlig for den videre koordinering af genetablering af service og den efterfølgende opsamling for det konkrete Major Incident.
Procesejer � Procesejeren er ejer af processen, hvilket indebærer ansvar for processens leverancer iht. aftalte procesmål.
� Procesejeren er ansvarlig for en kontinuerlig procesforbedring uanset om målene er opfyldt eller ej.
� Procesejeren koordinerer procesforbedringsaktiviteter, herunder værktøj og uddannelse med procesejere fra de øvrige organisationer.
Service Desk (funktion)
� Service Desken er brugerens indgang til IT organisationen.
� Det er Service Deskens opgave at håndtere alle brugerhenvendelser i henhold til de aftalte serviceniveauer. Service Desk ejer alle henvendelser gennem hele deres livscyklus og sørger for at holde brugere og kunder orienterede om fremdrift, status, kommende ændringer.
� Endvidere har Service Desk ansvar for at gennemføre (ledelses)rapportering, foretage brugerundersøgelser, samt at eskalere Incidents og Service Requests, der ikke håndteres inden for de aftalte serviceniveauer.
Service Desk Supporter
� Yde en venlig og kvalificeret service.
2. Level Supporter (gruppe)
� Løse tildelte Incidents / Service Requests i prioriteret rækkefølge og inden for aftalt tid.
� Løbende opdatere tildelte sager. � Anmode Service Desk om anden prioritering hvis nødvendigt.
� Tildele til anden support gruppe hvis nødvendigt. � Dokumentere tildelte sager kort og klart
5) Politikker
� Alle henvendelser til it skal registreres. � Alle henvendelser skal løses i den for RGN Syddanmark mest hensigtsmæssige rækkefølge. � Ingen sag må falde mellem to stole. � Hvis en cykelsag identificeres, skal dispatcheren henvende sig til en Incident Manager for at få stoppet og løst cykelsagen.
� Brugerne skal kunne følge status på deres egne sager. � Lukning af sager kan kun ske med brugerens accept. � Den medarbejder som er tildelt en sag, skal selv kontakte brugeren hvis sagen mangler oplysninger. Efterfølgende kan Incident Manager underrettes såfremt der fremover skal spørges efter specifikke oplysninger hos brugeren.
Proces for Incident Management, ver. 1, DokID: 69275 Side 3 af 27
6) Input
Input Leverandør Henvendelser (trigger)
Brugere
Events (trigger) System Management Incidents (trigger) It-personale CI informationer ”Asset & Configuration Management” KnownErrors og workarounds
”Problem Management”
Servicemål Service Level Management Serviceprioriteter Service Level Management
7) Output
Output Modtager Genoprettet service (ved løst incident)
Brugere
Udført service request
Brugere
Rapporter Ledelse og andre processer Sager Problem Management Kommunikation Brugere
8) Procesdokumentation
Dokument Placering
9) Diagram
OBS. For at se billedet i fuld størrelse klik her.
Proces for Incident Management, ver. 1, DokID: 69275 Side 4 af 27
10) Procesaktivitet
Aktivitet Beskrivelse 1 Identificering
2 Oprettelse
3 Validering
4 Klassificering
5 Indledende support
6 Prioritering
7 Tildeling
8 Løsning / Udførelse
9 Lukning
10 Godkendelse af nye løsninger
11 Opfølgning
12 Rapportering
13 Løbende forbedringsmøder
14 Kommunikation ved større- og major Incidents.
11) Procesmål
Mål Ansvarlig Målefrekvens Løbende brugertilfredshedsundersøgelse Procesejer Løbende (pr.
måned)
12) KPI'er Beskrivelse Query Målefrekvens Antal af henvendelser som ikke burde rettes til IT (produktivitet)
Real time
% af det samlede antal sager som registreres via end user interface (produktivitet)
Real time
Antal af sager som løses inden for aftalt tid fordelt på prioriteter (produktivitet)
Real time
% af det samlede antal sager hvor brugeren accepterer løsningen første gang (kvalitet)
Real time
% af det samlede antal sager som gen-tildeles (kvalitet)
Real time
% af de registrerede sager som løses ved første kontakt (produktivitet)
Real time
Antal lukkede sager sammenlignet med antal registrerede sager (kan vi følge med?)
Real time
It-staben - R. 7.1.1 Retningslinje for identificering It-staben - R. 7.1.2 Retningslinje for oprettelse It-staben - R. 7.1.3 Retningslinje for validering It-staben - R. 7.1.4 Retningslinje for klassificering It-staben - R. 7.1.6 Retningslinje for prioritering It-staben - R. 7.1.7 Retningslinje for tildeling It-staben - R. 7.1.8 Retningslinje for løsning / udførelse It-staben - R. 7.1.9 Retningslinje for lukning It-staben - R. 7.1.10 Retningslinje for at godkende nye løsninger It-staben - R. 7.1.11 Retningslinje for opfølgning (kontrol) It-staben - R. 7.1.12 Retningslinje for rapportering It-staben - R. 7.1.13 Retningslinje for løbende forbedringsmøder
Proces for Incident Management, ver. 1, DokID: 69275 Side 5 af 27
Bilag: 004, Incident Management 25.08.2011
Proces for Incident Management, ver. 1, DokID: 69275 Side 6 af 27
Udarbejdet�af: Service�Management
Proces�for�Incident�ManagementVersion:�0.1.5 Igangsat�den: 15/06�2011
Indledning Incident�Management�er�den�proces�(arbejdsgang),�som�behandler�alle�Incidents�og�Service�Requests.�Disse�kan�omfatte�fejl,�spørgsmål�eller�forespørgsler�rapporteret�af�brugere�til�service�desk,�af�teknisk�personale,�eller�automatisk�opdaget�og�rapporteret�af�overvågningsværktøjer.
Incident�Management�kan�sammenlignes�med�et�formel�1�pit�stop.�Hvis�man�har�et�Incident�(fejl),�så�vil�man�ikke�fokusere�på,�hvorfor�den�opstod,�men�i�stedet�forsøge�at�fjerne�symptomerne�så�hurtigt�som�muligt.�Fjernelse�af�årsagen�er�ikke�en�del�af�Incident�Management,�men�henhører�under�Problem�Management.
Formål Formålet�med�Incident�Management�er�at�genoprette�aftalt�service�så�hurtigt�som�muligt�og�udføre�bestillinger.
Definitio-ner
Ord el. forkortelse
Definition (ITIL)
Bruger En�person�der�anvender�en�it-service.Impact Et�udtryk�for�hvordan�et�Incident,�Problem�eller�en�
Change�påvirker�forretningsprocesser.�Impact�tager�ofte�sit�udgangspunkt�i�indvirkningen�på�Service�Levels.�Impact�anvendes�sammen�med�Urgency(se�nedenfor)�til�tildeling�af�prioritet.
Incident En�ikke�planlagt�afbrydelse�af�en�it-service�eller�reduktion�i�kvaliteten�af�it-servicen.�Fejl�i�et�Configuration�Item,�der�endnu�ikke�har�haft�konsekvenser�for�servicen�er�også�et�Incident.�Som�eksempel�kan�nævnes�fejl�på�én�enkelt�spejlet�disk.
Major�Incident Et�Incident�der�har�en�meget�stor�påvirkning�på�forretningen.
Prioritet En�kategori,�der�anvendes�til�at�identificere�den�relative�vigtighed�af�et�Incident,�Problem�eller�en�Change.�Prioritet�baseres�på�Impact�og�Urgency,�og�den�
Proces for Incident Management, ver. 1 Page 7 of 27
Side�2�af�21
Security�Incident Et�Incident�som�har�brudt�eller�truer�it�sikkerheden.�Dette�kan�være�indenfor�følgende�områder:
1. �Fortrolighed�(En�PC�der�forsvinder,�mistanke�om�utilsigtet�adgang�til�personfølsomme�data)
2. Integritet�(Hvis�der�konstateres�eller�er�mistanke�om�manipulation�med�information,�fx�ændring�af�indhold�på�websider)
3. Tilgængelighed�(Eksempelvis�utilgængeligt�E-mail�system�pga.�spam�angreb)�
Service�Request En�anmodning�fra�en�bruger�om�information,�rådgivning,�eller�adgang�til�en�it-service.�F.eks.�om�at�nulstille�et�password�eller�om�at�levere�en�standard�it-service�til�en�ny�bruger.�Service�Requests�håndteres�normalt�af�Service�Desk,�og�kræver�ikke�en�RFC�for�at�blive�iværksat.
Urgency Et�mål�for�hvor�lang�tid�det�varer,�før�et�Incident,�Problem�eller�en�Change�får�en�væsentlig�Impact�for�forretningen.�F.eks.�kan�et�Incident�med�stor�Impact�have�en�lille�Urgency,�hvis�konsekvensen�ikke�har�betydning�for�forretningen�før�årsafslutningen.�Impact�og�Urgency�anvendes�til�prioritering.
Workaround Det�at�reducere�eller�eliminere�Impact�af�et�Incident�eller�Problem,�hvortil�der�ikke�endnu�findes�en�fuldstændig�resolution.�F.eks.�genstart�af�et�fejlramt�Configuration�Item.�Workarounds�for�Problems�dokumenteres�i�KnownErrorRecords.�Workarounds�for�Incidents,�som�ikke�er�associeret�med�Problem�Records,�dokumenteres�i�Incident�Records.
Roller og ansvar
Rolle Ansvar
Bruger Brugeren�er�ansvarlig�for�at�anvende�services�i�henhold�til�gældende�bestemmelser,�samt�melde�fejl�til�superbruger�eller�Service�Desk�så�snart�en�sådan�konstateres.
Dispatcher Prioriterer�og�fordeler�sager.Incident�Manager Kvaliteten�i�den�daglige�udførsel�af�
Incident�Management�processen. Følge�op�på�Incidents,�agere�proaktivt�og�
sikre,�at�der�foretages�en�korrekt�behandling�heraf.
Vurdere�Incidents�mhp.�at�overdrage�ansvaret�for�specifikke�og�specielt�kritiske�Incidents�til�Major�Incident�Manager.
Proces for Incident Management, ver. 1 Page 8 of 27
Side�3�af�21
Major�Incident�Manager
Major�Incident�Manager�inddrages�i�tilfælde�af�et�Major�Incident�og�vurderer�sammen�med�Incident�Manager,�hvorvidt�Incidentet�skal�behandles�som�et�Major�Incident.�
Ved�Major�Incident�og�”�MI�arbejdsgrupper”�er�Major�Incident�Manager�ansvarlig�for�den�videre�koordinering�af�genetablering�af�service�og�den�efterfølgende�opsamling�for�det�konkrete�Major�Incident.
Procesejer Procesejeren�er�ejer�af�processen,�hvilket�indebærer�ansvar�for�processens�leverancer�iht.�aftalte�procesmål.
Procesejeren�er�ansvarlig�for�en�kontinuerlig�procesforbedring�uanset�om�målene�er�opfyldt�eller�ej.
Procesejeren�koordinerer�procesforbedringsaktiviteter,�herunder�værktøj�og�uddannelse�med�procesejere�fra�de�øvrige�organisationer.
Service�Desk(funktion)
Service�Desken�er�brugerens�indgang�til�IT�organisationen.�
Det�er�Service�Deskens�opgave�at�håndtere�alle�brugerhenvendelser�i�henhold�til�de�aftalte�serviceniveauer.�Service�Desk�ejer�alle�henvendelser�gennem�hele�deres�livscyklus�og�sørger�for�at�holde�brugere�og�kunder�ori�enterede�om�fremdrift,�status,�kommende�ændringer.�
Endvidere�har�Service�Desk�ansvar�for�at�gennemføre�(ledelses)rappor�tering,�foretage�brugerundersøgelser,�samt�at�eskalere�Incidents�og�Service�Requests,�der�ikke�håndteres�inden�for�de�aftalte�serviceniveauer.
Service�Desk�Supp
orter
Yde�en�venlig�og�kvalificeret�service.
2.�Level�Supporter�(gruppe)
Løse�tildelte�Incidents�/�Service�Requests�i�prioriteret�rækkefølge�og�inden�for�aftalt�tid.
Løbende�opdatere�tildelte�sager. Anmode�Service�Desk�om�anden�
prioritering�hvis�nødvendigt. Tildele�til�anden�support�gruppe�hvis�
nødvendigt. Dokumentere�tildelte�sager�kort�og�klart .
Politikker Alle�henvendelser�til�it�skal�registreres. Alle�henvendelser�skal�løses�i�den�for�RGN�Syddanmark�mest�
hensigtsmæssige�rækkefølge. Ingen�sag�må�falde�mellem�to�stole.
Proces for Incident Management, ver. 1 Page 9 of 27
Side�4�af�21
Brugerne�skal�kunne�følge�status�på�deres�egne�sager. Lukning�af�sager�kan�kun�ske�med�brugerens�accept. Hvis�en�cykelsag�identificeres,�skal�dispatcheren�henvende�sig�til�en�
Incident�Manager�for�at�få�stoppet�og�løst�cykelsagen. Den�medarbejder�som�er�tildelt�en�sag,�skal�selv�kontakte�brugeren�
hvis�sagen�mangler�oplysninger.�Efterfølgende�kan�Incident�Manager�underrettes�såfremt�der�fremover�skal�spørges�efter�specifikke�oplysninger�før�tildeling�af�sagen.
Input Input LeverandørHenvendelser�(trigger)
Brugere
Events�(trigger) System�ManagementIncidents�(trigger) It-personaleCI�informationer ”Asset�&�Configuration�Management”KnownErrors�og�workarounds
”Problem�Management”
Servicemål Service�Level�ManagementServiceprioriteter Service�Level�Management
Output Output ModtagerGenoprettet�service�(ved�løst�incident)
Brugere
Udført�service�request
Brugere
Rapporter Ledelse�og�andre�processerSager Problem�ManagementKommunikation Brugere
Procesdokumen-tation
Dokument Placering
Proces for Incident Management, ver. 1 Page 10 of 27
Side�5�af�21
Diagram
Proces-aktiviteter
Aktivitet Beskrivelse1 Identificering
2 Oprettelse
3 Validering
4 Klassificering
5 Indledende�support
6 Prioritering
7 Tildeling
8 Løsning�/�Udførelse
9 Lukning
10 Godkendelse�af�nye�løsninger
11 Opfølgning
12 Rapportering
Proces for Incident Management, ver. 1 Page 11 of 27
Side�6�af�21
13 Løbende�forbedringsmøder14 Kommunikation�ved�større-�og�major�Incidents.
Procesmål Mål Ansvarlig MålefrekvensLøbende�brugertilfredshedsundersøgelse Procesejer Løbende�(pr.�
måned)
KPI’er Beskrivelse Query Målefrekvens
Bem.
Antal�af�henvendelser�som�ikke�burde�rettes�til�IT�(produktivitet)
Real�time
%�af�det�samlede�antal�sager�som�registreres�via�end�user�interface�(produktivitet)�
Real�time
Antal�af�sager�som�løses�inden�for�aftalt�tid�fordelt�på�prioriteter�(produktivitet)
Real�time
%�af�det�samlede�antal�sager�hvor�brugeren�accepterer�løsningen�første�gang�(kvalitet)
Real�time
%�af�det�samlede�antal�sager�som�gen-tildeles�(kvalitet)
Real�time
%�af�de�registrerede�sager�som�løses�ved�første�kontakt�(produktivitet)
Real�time
Antal�lukkede�sager�sammenlignet�med�antal�registrerede�sager�(kan�vi�følge�med?)
Real�time
Proces for Incident Management, ver. 1 Page 12 of 27
Side�7�af�21
1.�Retningslinje�for�identificering
Formål At�beskrive�hvordan�der�rettes�henvendelse�til�Service�Desk�samt�i�hvilke�tilfælde�it-personale�skal�oprette�nye�sager.
Roller og ansvar
Rolle AnsvarBruger Kontakte�Service�Desk�såfremt�der�konstateres�fejl�i�it-
services,�eller�der�er�behov�for�anden�support.�Brugeren�skal�rette�henvendelse�til�sin�lokale�Service�Desk.�Henvendelse�til�Service�Desk�kan�ske�via�telefon,�email,�personlig�henvendelse�eller�end�user�interface.�
Service�Desk�Supporter�/�2.�Level�Supporter
Såfremt�en�supporter�observerer�en�fejl�i�et�it-system,�skal�den�registreres�i�værktøjet.
Input Input LeverandørN/A N/A
Output Output ModtagerTelefonisk�henvendelse�fra�bruger
Aktivitet:�Oprettelse
Andre�henvendelser�fra�brugerne
Aktivitet:�Validering
Identifikation�af�incident
Aktivitet:�Oprettelse
Dokumen-tation
Dokument PlaceringN/A N/A
Proces-faser
Trinnummer Beskrivelse1 Se�ansvarsbeskrivelser�under�punkt�2:�Roller og ansvar.
Proces for Incident Management, ver. 1 Page 13 of 27
Side�8�af�21
2.�Retningslinje�for�oprettelse
Formål At�beskrive�hvorledes�henvendelser�oprettes.�
Roller og ansvar
Rolle AnsvarService�Desk�Supporter
Registrering�af�henvendelser.
Service�Desk�og�2.�level�Supporter
Registrering�af�egne�sager.
Input Input LeverandørHenvendelser BrugereIdentificerede�fejl It-personale”CMDB”�detaljer ?
Output Output ModtagerRegistrerethenvendelse�i�form�af�en�incident�eller�service�request
Aktiviteten:�Klassificering
Dokumen-tation
Dokument Placering
Trin Trinnummer Beskrivelse1 Åbn�en�ny�sag.2 Registrer�de�grundlæggende�informationer�om�
brugeren.3 Udfyld�overskrift.4 Beskriv�detaljer,�herunder�symptomet�og�
omstændigheder�omkring�sagen: Hvilken�service�drejer�det�sig�om? Hvad�virker�ikke�(funktionalitet)? Hvordan�viser�det�sig? Hvad�virker? Oplever�andre�brugere�i�nærheden�sammen�
symptom? Hvornår�skete�det? Hvor�skete�det?
5 Sikre�beviser�som�bekræfter�symptomet�og�evt.�hvordan�man�fremprovokerer�symptomet.
Proces for Incident Management, ver. 1 Page 14 of 27
Side�9�af�21
3.�Retningslinje�for�validering
Formål At�beskrive�hvorledes�henvendelser�valideres.�
Roller og ansvar
Rolle AnsvarDispatcher Validering�af�henvendelser�som�er�modtaget�via�email�
og�end�user�interface.
Input Input LeverandørHenvendelser Brugere”CMDB”�detaljer ?
Output Output ModtagerRegistreret�og�valideret�henvendelse�i�form�af�en�incident�eller�service�request
Aktiviteten:�Klassificering
Dokumen-tation
Dokument Placering
Trin Trinnummer Beskrivelse1 Kontroller,�at�de�grundlægende�informationer�om�
brugeren�er�registreret.�Hvis�ikke,�forsøg�da�at�indhente�relevante�info.
2 Kontroller�at�overskrift�er�udfyldt�og�sigende.3 Kontroller�at�symptomet�og�omstændigheder�omkring�
det�er�beskrevet�(Hvis�ikke,�forsøg�da�at�indhente�relevante�info):
Hvilken�service�drejer�det�sig�om? Hvad�virker�ikke�(funktionalitet)? Hvordan�viser�det�sig? Hvad�virker? Oplever�andre�brugere�i�nærheden�sammen�
symptom? Hvornår�skete�det? Hvor�skete�det?
Proces for Incident Management, ver. 1 Page 15 of 27
Side�10�af�21
4.�Retningslinje�for�klassificering
Formål At�klassificere�sagerne,�så�de�kan�genfindes�og�opdeles�i�forbindelse�med�rapportering.
Roller og ansvar
Rolle AnsvarService�Desk�Supporter
Kategorisering�af�sager�som�modtages�via�telefon.
Dispatcher Kategorisering�af�sager�som�ikke�modtages�via�telefon.
Input Input LeverandørRegistreret�henvendelse�i�form�af�en�incident�eller�service�request
Aktiviteten:�Oprettelse
Registreret�henvendelse�i�form�af�en�incident�eller�service�request
Aktiviteten:�Validering
Output Output ModtagerKategoriserede�incidents�og�service�requests�som�ikke�er�løst�ved�første�kontakt
Aktiviteten:�Indledende�support
Kategoriserede�incidents�og�service�requests
Aktiviteten:�Prioritering
Dokumen-tation
Dokument Placering
Trin Trinnummer Beskrivelse1 Vælg�sagstype:
Incident�=�Fejl Request�For�Change�(RFC)�=�Ændringsønske Request�For�Service�(RFS)�=�Alt�andet
2 Vælg�berørte�service,�sub-service�mv.�under�kategorisering.
3 Marker�sagen,�hvis�der�er�tale�om�et�Security�Incident.
Proces for Incident Management, ver. 1 Page 16 of 27
Side�11�af�21
5.�Retningslinje�for�indledende�support
Formål At�løse�sagen�mens�brugeren�er�i�telefonen.
Roller og ansvar
Rolle AnsvarService�Desk�Supporter
Forsøge�at�løse�Incident’en�eller�udføre�Service�Request’en�mens�brugeren�er�i�telefonen.
Input Input LeverandørKategoriserede�sager
Aktiviteten:�Kategorisering
Output Output ModtagerLøst�Incident Aktiviteten:�LukningUdført�Service�Request
Aktiviteten:�Lukning
Sager�som�ikke�kunne�løses�eller�udføres�ved�første�kontakt
Aktiviteten:�Prioritering
Telefonisk�support� Brugerne
Dokumen-tation
Dokument Placering
Trin Trinnummer Beskrivelse1 Forsøg�at�løse�sagen,�mens�brugeren�er�i�telefonen.�Søg�
evt.�efter�tidligere�løsninger�i�vidensbaser.2 Hvis�det�er�muligt�at�løse�sagen�med�det�samme:
Test�løsningen�hvis�muligt Implementer�løsningen Udfyld�sagen�med�de�aktiviteter,�som�er�udført.�
Anvend�om�muligt�”Quick�case”. Opdater�kategoriseringen,�hvis�den�ikke�er�
korrekt Marker�sagen�som�løst
3 Såfremt�der�er�tale�om�en�sag,�som�skal�udføres�til�en�bestemt�dato,�så�vælg�Urgency�=�Planlagt,�og�anfør�datoen.�Tildel�herefter�sagen�til�Dispatcher.�
4 Hvis�det�ikke�er�muligt�at�løse�sagen,�så�informer�brugeren�om�dette�og�tildel�sagen�til�Dispatcher�til�
Proces for Incident Management, ver. 1 Page 17 of 27
Side�12�af�21
6.�Retningslinje�for�prioritering
Formål At�bestemme�den�relative�forretningsmæssige�vigtighed�af�sagen.
Det�er�ligeledes�under�prioritering�at�det�vurderes�om�der�er�tale�om�et�major�incident�og�Major�Incident�processen�skal�aktiveres.
Roller og ansvar
Rolle AnsvarDispatcher Prioritering�af�sager.Incident�Manager Vurdering�om�Incident�skal�håndteres�som�Major�incident�
og�ansvarlig�for�iværksættelse�af�Major�Incident�processen.
Input Input LeverandørRegistreret�henvendelse�i�form�af�en�incident�eller�service�request�som�ikke�er�løst�ved�første�kontakt
Aktiviteten:�Indledende�support
Registreret�henvendelse�i�form�af�en�incident�eller�service�request
Aktiviteten:�Klassificering
Sager�som�er�tildelt�forkert
Aktiviteten:�Tildeling
Sager�hvor�brugeren�har�afvist�løsningen
Aktiviteten:�Lukning
Output Output ModtagerPrioriterede�incidents�og�service�requests
Aktiviteten:�Tildel
Iværksættelse�af�Major�Incident�procedure
Major�Incident�Manager
Dokumen-tation
Dokument Placering
Proces for Incident Management, ver. 1 Page 18 of 27
Side�13�af�21
Diagram
Trin Trinnummer Beskrivelse6.1 Vurder�og�registrer�impact,�dvs.�hvorledes�påvirker�sagen�
forretningen,�såfremt�der�ikke�gøres�noget.
Vurder�og�registrer�urgency,�dvs.�hvor�hurtigt�har�forretningen�behov�for�en�løsning.�Bemærk,�at�Urgency�ikke�skal�ændres,�hvis�der�allerede�er�valgt�”Planlagt”.
6.2 Kontakt�øjeblikkeligt�Incident�Manager�såfremt�der�er�mistanke�om�et�Major�Incident.
Major�Incidents�har�bl.a.�følgende�karakteristika: Har�en�meget�stor�negativ�effekt�på�forretningen Har�stor�ledelsesfokus Hænder�ikke�med�faste�intervaller Hænder�relativt�sjældent• Er�længerevarende Der�er�ofte�flere�organisatoriske�enheder,�som�er�berørte.
6.3 Incident�Manager�vurderer�om�Incident’et�skal�håndteres�som�et�Major�Incident�og�informer�Service�Desk.�Marker�sagen,�hvis�den�skal�håndteres�som�et�Major�Incident.
6.4 Udpeg�og�informer�den�Major�Incident�Manager,�som�skal�koordinere�løsning�af�sagen.
6.5 Iværksæt�initiel�kommunikation�for�at�informere�brugere�og�ledelse�om�den�umiddelbare�konsekvens,�samt�for�at�lette�trykket�på�Service�Desk.�Dette�skal�gøres�således:
Indtal�besked�på�Service�Desk’ens�telefonsvarer Udsend�driftsstatus�meddelelse�på�relevante�medier. Informer�relevante�interessenter�(ledelse�etc.)
Brug�endvidere�retningslinje�14�Kommunikationved prioritet 1 sager og major Incidents�i�forbindelse�med�
Proces for Incident Management, ver. 1 Page 19 of 27
Side�14�af�21
6.6 Iværksæt�Major�Incident�Procedure�parallelt�med�løsning�af�Incident’et.�<LINK>
7.�Retningslinje�for�tildeling
Formål At�sikre�at�sager�tildeles�den�supportgruppe,�som�har�kompetencen�til�at�løse�sagen.
Roller og ansvar
Rolle AnsvarDispatcher Tildele�sager�til�relevante�supportgrupper.�(Modtaget�via�
tlf.,�enduser�eller�mail)
Input Input LeverandørKlassificerede�og�prioriterede�sager
Aktiviteten:�Prioritering
Output Output ModtagerTildelte�sager Egne�supportgrupperTildelte�sager Eksterne�supportgrupper�eller�Service�Desks
Dokumen-tation
Dokument Placering
Trin Trinnummer Beskrivelse1 Tildel�sagerne�til�relevante�supportgrupper,�både�egne,�
eksterne�og�andre�Service�Desks.2 Undersøg�sager�som�er�gen-registreret,�og�fastslå,�
hvorfor�de�er�blevet�tildelt�forkert.�Underret�alle�der�har�rollen�Dispatcher.
Proces for Incident Management, ver. 1 Page 20 of 27
Side�15�af�21
8.�Retningslinje�for�løsning�/�udførelse
Formål At�sikre�at�incidents�løses�og�at�service�requests�udføres.
Roller og ansvar
Rolle AnsvarService�Desk�Supporter,�2.�Level�Supporter.
Løse�incident�/�udføre�service�request,�samt�dokumentere�aktiviteterne.
Input Input LeverandørTildelte�sager Aktivitet:�Tildeling
Output Output ModtagerLøste�incidents Aktiviteten:�LukningUdførte�service�requests
Aktiviteten:�Lukning
Sager�som�er�tildelt�forkert
Aktiviteten:�Prioritering
Eskalerede�sager Aktiviteten:�Løsning�/�Udførelse�(ny�gruppe)
Dokumen-tation
Dokument Placering
Trin Trinnummer Beskrivelse1 Tag�højest�prioriterede�sag�fra�gruppens�liste.2 Kontroller�om�tildelingen�er�korrekt,�og�såfremt�den�
ikke�er,�så�returner�sagen�til�Dispatcher�med�forklaring.3 Hvis�sagen�er�tildelt�forkert,�kan�du�undtagelsesvis�gen-
tildele�sagen�direkte�til�anden�supportgruppe.�Men�du�må�kun�gøre�dette�hvis�du�samtidig�underretter�Incident�Manager�så�Service�Desk�for�fremtiden�kan�tildele�lignende�sager�rigtigt�første�gang.
4 Undersøg�sagen�og�find�en�løsning.5 Såfremt�der�mangler�oplysninger,�så�kontakt�brugeren.�
Sagen�skal�ikke�sendes�tilbage�til�Service�Desk,�men�informer�gerne�Incident�Manager�om,�hvilke�informationer�de�bør�efterspørge.�
Såfremt�brugeren�ikke�svarer�efter�3�kvalificerede�forsøg�på�kontakt,�sæt�status�til�”Afventer�bruger”.
6 Test�om�muligt�løsningen.7 Implementer�løsningen.8 Beskriv�i�sagen,�hvilke�aktiviteter�der�er�udført�for�at�
løse�/�udføre�sagen.
Proces for Incident Management, ver. 1 Page 21 of 27
Side�16�af�21
9 Vælg�Løst�–�med�eller�uden�mail.
9.�Retningslinje�for�lukning
Formål At�sikre�at�brugeren�har�accepteret�løsningen�og�alternativt�gentildele�sagen.
Roller og ansvar
Rolle AnsvarDispatcher Gentildele�sagen,�såfremt�brugeren�ikke�er�tilfreds�med�
løsningen.
Input Input LeverandørLøste�incidents Aktiviteten:�Løsning�/�udførelseUdførte�service�requests
Aktiviteten:�Løsning�/�udførelse
Afvisning�af�løsning.
Bruger
Output Output ModtagerLukkede�sager N/AGen-tildelte�sager Aktiviteten:�Prioritering
Dokumen-tation
Dokument Placering
Trin Trinnummer Beskrivelse1 Gentildel�sag�til�fornyet�prioritering�såfremt�bruger�har�
afvist�løsningen.
Proces for Incident Management, ver. 1 Page 22 of 27
Side�17�af�21
10.�Retningslinje�for�at�godkende�nye�løsninger
Formål At�sikre�kvaliteten�af�løsninger�i�løsnings-DB.
Roller og ansvar
Rolle AnsvarIncident�Manager Udføre�opgaven�ugentligt.
Input Input LeverandørForslag�til�løsninger,�som�kan�bruges�enten�internt�eller�af�brugerne
Supportere
Output Output ModtagerGodkendte�løsninger
Supportere�og�brugere
Afviste�løsninger N/A
Dokumen-tation
Dokument Placering
Trin Trinnummer Beskrivelse1 Godkend�eller�afvis�løsninger2 Gør�godkendte�løsninger�tilgængelige�for�supporterne3 Informer�supporterne�om�nye�løsninger
Proces for Incident Management, ver. 1 Page 23 of 27
Side�18�af�21
11.�Retningslinje�for�opfølgning�(kontrol)
Formål At�opretholde�fremdrift�og�sikre�datakvaliteten.
Roller og ansvar
Rolle AnsvarIncident�Manager Udføre�aktiviteten�dagligt.
Input Input LeverandørIncidents�og�Service�Requests
ITSM�værktøj
Output Output ModtagerIncident�dubletter�der�er�slået�sammen
N/A
Re-prioriterede�sager
N/A
Flyttede�sager Supportgrupper
Dokumen-tation
Dokument Placering
Trin Trinnummer Beskrivelse1 Kontroller�for�ens�incidents�og�relater�disse.2 Kontroller�for�sager�uden�fremdrift�–�undersøg�hvorfor�
fremdrift�mangler�og�iværksæt�initiativer.3 Kontroller�for�fejlplacerede�sager�og�foretag�ny�tildeling.
4 Kontroller�datakvaliteten�ved�stikprøvekontrol�–�er�sagerne�udfyldt�korrekt�og�præcist.
5 Kontroller�for�sager,�som�er�i�fare�for�eller�har�overskredet�tidsfristen�og�revurder�prioriteten.�Eskaler�sager,�hvis�der�er�behov.
Såfremt�Incident�Manager�i�en�Service�Desk�har�behov�for�at�rykke�for�en�sag�som�er�placeret�i�en�anden�it-organisation,�skal�følgende�retningslinjer�anvendes: Imellem�to�sygehuse�skal�Service�Desken�kontaktes. Ved�kontakt�fra�en�sygehus�Service�Desk�til�IT�Stabens,�skal�der�ringes�til�
supportgruppens�vagttelefon,�og�alternativt�Service�Desken.
Proces for Incident Management, ver. 1 Page 24 of 27
Side�19�af�21
12.�Retningslinje�for�rapportering
Formål At�informere�om�hvordan�processen�performer�og�udvikler�sig.
Roller og ansvar
Rolle AnsvarIncident�Manager At�udføre�aktiviteten�månedligt.
Input Input LeverandørDetaljer�om�sager ITSM�værktøj
Output Output ModtagerRapporter Interessenter
Dokumen-tation
Dokument Placering
Trin Trinnummer Beskrivelse1 Udarbejd�rapporter2 Fordel�/�publicer�rapporter
Proces for Incident Management, ver. 1 Page 25 of 27
Side�20�af�21
13.�Retningslinje�for�løbende�forbedringsmøder
Formål At�løbende�at�forbedre�processen�ved�at�besvare�spørgsmålene: Hvad�har�vi�gjort�godt? Hvad�har�vi�gjort�forkert? Hvordan�kan�vi�gøre�det�bedre�fremover?
Roller og ansvar
Rolle AnsvarProcesejer At�gennemføre�aktiviteten�månedligt�eller�oftere.
Input Input LeverandørRapporter Incident�ManagerForslag�til�forbedringer
Personer�involverede�i�processen
Output Output ModtagerMødereferater InteressenterOpgaver�-�forbedringstiltag
N/A
Dokumen-tation
Dokument Placering
Trin Trinnummer Beskrivelse1 Gennemføre�løbende�forbedringsmøde�med�følgende�
dagsorden:
1. Opfølgning�–�på�emner�fra�sidste�møde2. Status�–�KPI’er�og�rapporter3. Foreslåede�ændringsønsker�til�processen�til�
godkendelse4. Problemer�–�processen,�roller,�værktøjer,�
skabeloner,�mål��mv.�–�nye�emner?5. Opdatere�emnelog�–�hvem�gør�hvad�til�hvornår?6. Næste�møde
Andre�opgaver: (Årligt�/�halvårligt)�Kontroller�anvendelsen�af�kategorier�og�fjern�evt.�kategorier,�
som�ikke�anvendes. (Årligt�/�halvårligt)�Kontroller�anvendelsen�af�prioritetssystemet�og�iværksæt�
justeringer,�hvis�fordelingen�er�”skæv”.
Proces for Incident Management, ver. 1 Page 26 of 27
Side�21�af�21
14.�Retningslinje�for�Kommunikationved�prioritet�1�sager�og�major�Incidents.
Formål At�informere�forretningsområder,�ledelser,�servicedeske,�KAM’er�og�andre�interessenter�i�udviklingen�af�prioritet�1�sager�og�Major�Incidents.�
Roller og ansvar
Rolle AnsvarIncident�Manager At�iværksætte�og�styre�kommunikationen.
At�overdrage�kommunikationsopgaven�til�driftsvagten�eller�andet�relevant�personale.�
Input Input LeverandørSager�i�Maximo Brugere�af�systemet.
Output Output ModtagerKommunikation Interessenter
Dokumen-tation
Dokument Placering
Trin Trinnummer Beskrivelse1 Identificering�af�prioritet�1�sager�og�Major�Incidents.2 Klarlæg�modtager�kredsen�af�Informationen,�herunder�
forretningsområder,�ledelser,�servicedeske,�KAM’er�og�andre�interessenter.
3� Udfyld�fast�mail�skabelon�med�følgende�oplysninger:-�Overskrift�vedr.�problemet-�Detaljeret�problem�beskrivelse-�Hvem�berører�problemet�Impact/Urgency-�Årsag�til�driftsforstyrrelse-�Hvornår�er�problemet�opstået-�Næste�opdatering�af�status-�Hvem�opdaterer�næste�gang�hvis�en�anden�overtager-�Senest�opdateret-�Status�på�problemet
4 Iværksæt�kommunikation�via�afsender�mail�DriftsInfo5� Overdrag�relevant�kommunikation�og�dokumentation�til�
Problem�Management�ved�afslutning�på�problemet.
Proces for Incident Management, ver. 1 Page 27 of 27