Flowchart for IT-helpdeskproces (incidents og anmodninger)

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.