Flowchart for IT-helpdeskproces (incidents og anmodninger)

Hvad er flowchart for it-helpdeskproces (incidents og anmodninger)?

En IT-helpdeskproces er den måde, en servicedesk driver sin hverdag på: én hoveddør for enhver brugerhenvendelse, uanset hvilken kanal den kommer ind ad, og én aftalt vej fra henvendelsen til en lukket sag. Det, der adskiller den fra en procedure med ét formål, er, at den bærer to slags arbejde på samme tid. Nogle sager er incidents, hvor noget, der burde virke, ikke gør. Andre er serviceanmodninger, hvor intet er i stykker, og brugeren beder om et standardstykke arbejde, der på forhånd er aftalt: en licens, en ny computer eller et stykke software. De to har brug for hver sit ur og ofte hver sin godkender, så processen deler dem tidligt i stedet for at lade én kø behandle alt som et nedbrud.

Denne side dækker deskens daglige driftsflow, ikke det indre af den enkelte gren. Har I brug for erklæring af major incidents, en navngiven incident manager, bridgemøder og eskalering ved SLA-brud, hører den detalje hjemme i processen for incident management. Mistanke om kompromittering følger i stedet processen for security incident response. En løsning, der kræver ændring af en driftsservice, overleverer til ændringsstyring, og en anmodning om systemadgang følger processen for adgangsanmodning med sin egen godkendelseskæde og periodiske gennemgang. Rodårsagsarbejdet forlader processen helt: grenen for gentagne fejl opretter en problemsag i stedet for at holde brugerens sag åben, mens en tekniker undersøger sagen.

Diagrammet tegner fem baner (Bruger, Servicedesk, 2. level support, Udstyr og indkøb samt Problem management) fordelt på fem faser fra henvendelse til lukning. Det viser to ting, de fleste deske aldrig får skrevet ned: opslaget i vidensbasen, der afgør, om førstelinjen anvender en dokumenteret løsning eller fejlsøger fra bunden, og indkøbsgrenen, der afgør, om en bestilt vare tages fra lager eller skal bestilles hjem. Og det slutter der, hvor de fleste nedskrevne procedurer stopper for tidligt: med brugerens bekræftelse af løsningen og en genåbningsgren til, når brugeren siger, at det stadig ikke virker.

Hvad dette flowchart dækker

I denne skabelon

• Fem swimlanes med en navngiven ansvarlig på hvert trin (Bruger, Servicedesk, 2. level support, Udstyr og indkøb samt Problem management) fordelt på fem faser: Henvendelse, Registrering og triage, Førstelinje, Eskalering og levering samt Løsning og lukning
• Modtagelse på tværs af kanaler, hvor 'Bruger kontakter servicedesken' fører videre til 'Modtag henvendelse på alle kanaler', så telefon, mail, selvbetjeningsportal, chat og personligt fremmøde lander i den samme kø, før noget bliver registreret
• Forgreningen 'Incident eller serviceanmodning?' lige efter 'Registrer og kategoriser sagen', som sender incidents til 'Sæt prioritet ud fra påvirkning og hast' og anmodninger ned ad en selvstændig leveringsgren
• Et førstelinjeforsøg bygget op om 'Kendt løsning i vidensbasen?', hvor ja anvender den dokumenterede løsning, og nej går til 'Forsøg en løsning i førstelinjen', begge mødes i 'Løst i førstelinjen?' med en eskaleringsgren ind i 'Undersøg og løs i 2. level'
• Anmodningsgrenen: 'Godkender lederen anmodningen?' med en afvisningsgren, der ender i 'Anmodning afvist og lukket', derefter 'Er varen på lager?', som sender en bestilling gennem 'Opret en indkøbsordre', før 'Lever og opdater udstyrsregistret'
• Lukningen i den sidste kolonne: 'Dokumentér løsning og orienter brugeren', beslutningen 'Bekræfter brugeren, at det virker?' med en genåbningsgren tilbage til førstelinjen, og 'Gentagen eller kendt fejl?', der opretter en problemsag inden 'Sag lukket'

Hvornår du skal bruge skabelonen

• I skal dokumentere, hvordan jeres servicedesk faktisk kører, så en ny medarbejder kan se, hvor en sag går hen, og hvem der ejer hvert trin, uden at spørge en kollega
• I skal skille incidents fra serviceanmodninger, fordi begge i dag ligger i én udifferentieret kø, og alt derfor ender med at blive behandlet som hastesager
• I er ved at sætte et servicedesk- eller ITSM-værktøj op, hvor kategorierne, prioritetsmatricen, godkendelsesreglen og opdateringen af udstyrsregistret i diagrammet svarer til felter, I alligevel skal konfigurere
• I skal have afklaret, hvor førstelinjen stopper, og 2. level begynder, hvilket i de fleste teams er sædvane frem for en nedskrevet regel
• I skal briefe en outsourcet eller nyansat desk om de overleveringer, bekræftelser og registreringer, I forventer bliver overholdt

Sådan fungerer det

1. Omdøb banerne til jeres rigtige roller

   Erstat Bruger, Servicedesk, 2. level support, Udstyr og indkøb samt Problem management med de teams, I har. Mindre organisationer lægger ofte udstyr og indkøb ind i servicedeskbanen, og problem management kan være en navngiven person frem for et team. Hold én bane pr. beslutningstager frem for pr. person, så diagrammet overlever, at nogen skifter job.

2. Skriv testen for incident kontra serviceanmodning ned

   Forgreningen 'Incident eller serviceanmodning?' virker kun, hvis en medarbejder kan afgøre den på få sekunder. Skriv testen ved siden af beslutningen: er noget, der burde virke, i stykker, eller beder brugeren om et standardstykke arbejde, der er aftalt på forhånd? List jeres reelle grænsetilfælde (for eksempel en langsom computer over for en anmodning om en ny), og angiv, hvilken vej hver af dem går.

3. Offentliggør jeres prioritetsmatrix

   Hæft jeres definitioner af påvirkning og hast på 'Sæt prioritet ud fra påvirkning og hast', og skriv, hvad hvert prioritetsniveau betyder i antal berørte brugere og forretningsmæssig konsekvens. Netop det at lægge matricen et sted, brugerne kan læse den, gør prioriteten til noget, der udledes, frem for noget, der forhandles sag for sag.

4. Fastlæg førstelinjens grænse, og hvad en eskalering skal indeholde

   Definer, hvad førstelinjen må og kan løse, og hvad en eskalering skal indeholde, før 2. level tager imod den: hvad der allerede er prøvet, hvilken service der er berørt, dokumentation og hvornår brugeren er til at træffe. Beslut, om I også vil have en tidsbaseret bagstopper, der eskalerer en sag uden fremdrift, og angiv, hvem der ejer sagen efter overleveringen.

5. Beslut, hvad der kræver godkendelse, og hvad der er forhåndsgodkendt

   Markér billige katalogvarer med lav risiko som forhåndsgodkendte, så de springer 'Godkender lederen anmodningen?' helt over, og gem godkendelsen til udgifter, licenser og alt, der ændrer, hvad en person har adgang til. Handler anmodningen om systemadgang, skal den overleveres til jeres proces for adgangsanmodning frem for at blive godkendt her.

6. Aftal lukning, genåbning og henvisning til problem management, og udgiv én version

   Angiv, hvad der tæller som brugerens bekræftelse, hvor længe en løst sag venter, før den lukkes automatisk, og hvilke kriterier på 'Gentagen eller kendt fejl?' der udløser en problemsag. Gå derefter diagrammet igennem med hver bane, ret de trin, de reelt udfører, og udgiv det som den gældende version med en dokumenteret godkendelse, så alle læser den samme revision.

Ofte stillede spørgsmål

Hvad er forskellen på en IT-helpdeskproces og incident management?

Helpdeskprocessen er selve deskens driftsflow: enhver henvendelse, der kommer ind på en hvilken som helst kanal, ruttet videre til den rigtige slags behandling. Incident management er én tråd inde i den og handler kun om utilsigtede afbrydelser af en service. ITIL 4 behandler netop derfor service desk, incident management, service request management og problem management som selvstændige praksisser, selvom et lille team i praksis kører dem alle fra én kø med de samme personer. Dette diagram er udsigten på deskniveau, der viser, hvordan trådene deler modtagelse og lukning, og som overlader den dybe incidentdetalje (erklæring af major incidents og eskalering ved SLA-brud) til processen for incident management.

Hvad er forskellen på en incident og en serviceanmodning?

En incident er noget, der burde virke og ikke gør: et login der fejler, en printer der er offline, en applikation der kaster fejl. En serviceanmodning er standardarbejde, der er aftalt på forhånd, uden at noget er i stykker: ny software, en licens, en erstatningsenhed, en postkasse til en ny medarbejder. Skellet betyder noget, fordi det ændrer stort set alt nedstrøms. Incidents får en prioritet ud fra påvirkning og hast og måles på genetablering; anmodninger får en godkendelse og en leveringsvej og måles på levering. Blander I dem, ligger rutineanmodninger enten på et nedbrudsur, eller også står rigtige nedbrud i kø bag computerbestillinger.

Hvornår skal en helpdesksag eskaleres til 2. level?

Eskalér, når opgaven har passeret grænsen for førstelinjens kompetencer, værktøjer eller adgange: det er en funktionel eskalering. Det er noget andet end en hierarkisk eskalering, hvor en leder bliver trukket ind, fordi konsekvensen eller forsinkelsen er blevet en forretningssag frem for en teknisk. Mange deske lægger en tidsbaseret bagstopper ind, så en sag uden fremdrift eskaleres automatisk, hvilket er nyttigt som sikkerhedsnet, men en dårlig hovedregel alene. Uanset hvad der udløser den, skal overleveringen bære det, der allerede er prøvet, ellers bruger 2. level sin første time på at gentage førstelinjens arbejde.

Må en sag lukkes, før brugeren har bekræftet løsningen?

Løst og lukket er to forskellige tilstande, og dette diagram holder dem adskilt. En medarbejder markerer sagen som løst, når rettelsen er udført; den lukkes først, når 'Bekræfter brugeren, at det virker?' giver et ja. Siger brugeren, at problemet stadig er der, genåbnes sagen til førstelinjen frem for at starte en ny, så hænger historikken og det oprindelige ur stadig sammen. Fordi nogle brugere aldrig svarer, sætter de fleste deske en automatisk lukning efter nogle arbejdsdage med en påmindelse først, og skriver den periode ind i servicebeskrivelsen, så lukningen ikke kommer bag på nogen.

Hvordan passer serviceanmodninger, der kræver et indkøb, ind i processen?

De følger leveringsgrenen: godkendelse, hvor kataloget kræver det, og derefter 'Er varen på lager?', som enten udleverer fra lager eller opretter en indkøbsordre inden levering. Det trin, folk springer over, er opdateringen af udstyrsregistret, og derfor ligger den i samme node som leveringen her. Bliver registret ikke opdateret i det øjeblik, varen udleveres, skrider licenstal og planlægning af hardwareudskiftning inden for få måneder. Ved større indkøb eller varer uden for kataloget rejser desken behovet, og den bredere indkøbsordreproces overtager med sin egen leverandørvalg og fakturaafstemning.