proces for incident management - regionsyddanmark.dk file3) definitioner 4) roller og ansvar 5)...

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


� 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.


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.


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


Bilag: 004, Incident Management 25.08.2011


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 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.


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.


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


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


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


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.


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.


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


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?


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


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.


Side�11�af�21

5.�Retningslinje�for�indledende�support

Formål At�løse�sagen�mens�brugeren�er�i�telefonen.

Roller og ansvar


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


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�


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


Sager�som�er�tildelt�forkert

Aktiviteten:�Tildeling

Sager�hvor�brugeren�har�afvist�løsningen


Output Output ModtagerPrioriterede�incidents�og�service�requests

Aktiviteten:�Tildel

Iværksættelse�af�Major�Incident�procedure

Major�Incident�Manager

Dokumen-tation

Dokument Placering


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�


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


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.


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


Sager�som�er�tildelt�forkert


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.


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.


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


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.


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


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”.


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 - regionsyddanmark.dk file3) definitioner 4) roller og ansvar 5)...

Documents