ITSM - Processer og Værktøjer

ITSM (IT Service Management) vedrører organisering af IT Services på en værdiskabende og hensigtsmæssig måde for slutbrugere, forretning og IT-organisation. På AU har vi indført tre ITIL (IT Infrastructure Library) processer samt et ITSM-værktøj, Cherwell, der understøtter denne målsætning:

  • Incident Management (håndtering af pludseligt opståede fejl)
  • Service Request Fulfilment (håndtering af alle former for IT-relaterede forespørgsler)
  • Continual Service Improvement (kontinuerlig fokus på forbedringer af processer og værktøj)

På denne hjemmeside kan du finde følgende:

  • AU Procesretningslinjer - Procesretningslinjerne beskriver de regler og aftaler, som vi på AU overholder, for at agenterne kan levere den optimale service til slutbrugerne.
  • Prioriteringsmatricen - agenternes retningslinjer for prioritering af sager inkl. eksempler.
  • Vejledningsmateriale – To udgaver – et til slutbrugere og et til agenter – begge beskriver AU best practice for brug af Cherwell-værktøjet.
  • CSI Governance dokument - beskriver, hvordan AU’s CSI-proces fungerer i praksis.

De fem principper

1. Beskriv en sag grundigt, inden du sender den videre til andet team eller agent

  • Opret altid en ny journal note, hvor du opsummerer problemstillingen og beskriver, hvad der forudgående er gjort i forsøg på løsning (benyt eventuelt "knappenålsfunktionen" til at fremhæve særligt vigtige journal noter). Hermed hjælper du din kollega med et hurtigt overblik, så denne hurtigere kan igangsætte en løsning. 
  • Inden sagen eskaleres, skal felterne under “Additional Questions” være udfyldt. Indhent nødvendige oplysninger fra brugeren og notér, hvad du har foretaget af fejlsøgning inden eskalation. 
  • Hold altid en god tone i kommentartråden. Vi er 300 agenter, hvoraf mange tilsvarende er slutbrugere, så skriv ikke noget, der ikke kan tåle at blive læst af alle. 
  • Alle handlinger, du foretager dig på sagen, skal du dokumentere med en ny journal note. F.eks. at man har forsøgt at kontakte slutbrugeren, har gentestet fejlen, udstyr er modtaget i supporten, tjekket SDwiki eller lignende. Med andre ord skal det være nemt for en kollega at danne sig et hurtigt overblik over, hvad der er sket på sagen.
  • Ved løsning af en sag, som du returnerer til et andet team eller agent, skal du altid oprette en ny journal note, hvor du beskriver løsningen. En sag overdrages ikke til et team eller en agent ved blot at skrive “done”. 
  • Sagen overdrages med status “In Progress”, hvis den er påbegyndt. Statussen sættes automatisk, hvis der er sendt mail til bruger. 
  • Ved overdragelse af sag med høj prioritet (P1 eller P2), konsultér prioriteringsmatricen, og kontakt enten dispatcher eller teamleder i det modtagende team. 

 

2. Hold slutbrugeren løbende orienteret om sagens status

  • Som udgangspunkt er det supportens ansvar at kommunikere med slutbrugeren. Det gælder ved indhentning af supplerende oplysninger samt ved formidling af løsning. 
  • Driften må dog gerne tage den direkte kommunikation med slutbruger – der kan være mange situationer, hvor det giver god mening. 
  • Hvis sagen eskaleres til andet team, så orienter brugeren om dette.
  • Ingen sager sættes med status “Resolved”, uden at man har kommunikeret dette til slutbrugeren. 
  • Det team/agent, der har fået tildelt sagen, har ansvaret for at kommunikere statusopdateringer ud til slutbrugeren. En statusopdatering til slutbrugeren kan fx være en længere behandlingstid, at sagen overdrages til andet team eller afventer svar fra leverandør. Har du ikke tid at løse sagen med det samme, så noter forventet behandlingstid i en intern journal note, så dine kollegaer kan videregive status til bruger på forespørgsel.
  • Hvis der skal rykkes for status på en sag, der ligger i et andet team, så opret en journal note på sagen. Agenten har ansvaret for hurtigt at reagere og få svaret brugeren med et forventet løsningstidspunkt. 

3. Ved overdragelse af en sag dispatches den altid til et team – ikke direkte til en agent

  • Dispatcheren i det enkelte team har overblikket over ferie og fravær, samt hvem der har tid til at løse problemet. Dette gælder også, når sagen skal retur til supporten efter en løsning er fundet i drift. 
  • Sagen overdrages altid til det primære team, når den returneres til support (BSS IT, Health IT, ARTS IT, FA IT, Nat-Tech IT Team 1 (Aarhus), Nat-Tech IT Team 2 (Lokationer) 
  • Hvis sagen sendes direkte til en agent, må dette KUN ske efter forudgående aftale. Fx hvis der allerede kører en dialog om løsning mellem 2 agenter – brug sund fornuft. 
  • Inden overdragelse kontrolleres det, at den tilføjede kategori matcher sagens beskrivelse. Mangler kategorien, skal denne tilføjes. 
  • Omhandler sagen flere problemer, som skal løses af forskellige teams, er det agentens ansvar i support inden overdragelse at dele sagen op i flere sager (evt tasks). 
  • Ved ferie og fravær har dispatcheren ansvaret for at holde øje med, om der sker updates på sager eller om deadlines overskrides. 
  • Agenten har ansvar for at sætte autosvar op i Cherwell ved ferie og fravær 

4. Sæt altid den korrekte status eller flag på en sag

Vi anvender i alt 6 statuskoder i Cherwell (New, Assigned, In Progress, Pending, Resolved, Closed). Foruden statuskoder arbejder vi med 2 flag (Update flag og Attention flag). Statuskoderne kan ses af slutbrugeren i portalen, så det er vigtigt, at disse benyttes korrekt. Update flag skal også benyttes korrekt, da dispatchere og agenter skal anvende disse til at sikre, at vi reagerer hurtigt på nye brugerhenvendelser.

Typer af status:

New: Alle nye sager, der er oprettet i Cherwell Client eller indkommet fra slutbruger via portalen eller mail. I portalen vil slutbrugeren se sagen med status “New”. 

Assigned: Når du tildeler en sag til en agent, vil statussen stadig stå som “New”. Når sagen er tildelt et team, vil slutbrugeren kunne se i portalen, hvilket team sagen er tildelt. 

In Progress: Så snart en agent påbegynder løsning af en sag, skal man klikke på “Begin Work” så statussen ændres til “In Progress”. Slutbrugeren vil kunne se, at sagen er påbegyndt. 

Pending: Statussen anvendes, hvis man enten venter på svar fra slutbruger eller leverandør. Slutbrugeren vil kunne se, at sagen afventer og årsagen til denne status. 

Resolved: Når drift løser en sag, så sæt altid status “In Progress” og returner til Support Team med en Journal Note, der beskriver løsningen. Support vælger status “Resolved”. Der popper en boks op, hvor man indtaster løsningen. Det indtastede i boksen bliver automatisk sendt ud til slutbrugeren pakket ind i en mailskabelon “Kære bruger”. 

Closed: En sag bliver automatisk Closed efter at have været “Resolved” i 30 dg. En closed sag kan ikke genåbnes. Her er slutbrugeren nødt til at oprette en ny sag. 

Typer af flag:

Update flag: Er grønt (aktiveret) når en sag kræver en reaktion fra agenten. Du skal altid svare brugeren hurtigst muligt og fjerne Update flag, når en bruger har fået svar. Sager må ikke have et aktivt Update flag igennem længere tid. Påtænker man at have en sag liggende mere end et par dage skal man fjerne Update flag og sætte en anden status (eventuelt bruge Attention flag).

Attention flag: Du kan sætte et Attention flag på en sag, du selv vil holde særligt øje med. Tryk på knappen Demands attention som du finder under Actions.

5. Hold al kommunikation i Cherwell - både internt mellem teams, med slutbruger, og eksterne fx leverandører.

  • Vi hjælper hinanden ved altid at holde kommunikationen i Cherwell - tænk på din kollega som i dit fravær skal overtage eller følge op på dine sager. 
  • Notér i sagen i en journal-note, hvad du har foretaget dig i forbindelse med fejlsøgning. 
  • Hvis en slutbruger henvender sig direkte via mail til en agent, så henvis til at sagen i stedet registreres i portalen. Et forslag til ordlyden af en svarmail på en direkte henvendelse kunne være: ” Tak for din mail. Jeg kan desværre ikke tage imod din henvendelse/supporthenvendelse i min personlige indbakke. Du bedes oprette en henvendelse via selvbetjeningsportalen, som du finder via dette link: support.au.dk. Herefter vil din henvendelse blive distribueret til en agent, der løser din sag. Mvh XXXX” 
  • I de tilfælde hvor man indmelder fejl til leverandør via eksternt ITSM system registreres sagsid’et i Cherwell sagen. 

Andre retningslinjer og vejledninger

Procesretningslinjer

AU Procesbeskrivelser - Incident Management og Service Request

Samlet sagsflow for en sag oprettet via Cherwell portalen

  1. Kunde opretter sag i portal eller sender en mail til lokal supportenhed
  2. Dispatcher ser sag i sit teams kø 
  3. Dispatcher tjekker sagen ift. indhold, kategorisering og prioritet
  4. Dispatcheren tildeler sagen til specifik 1. line supporter
  5. 1. line supporter klikker på statusfelt ”Begin work” 
  6. Herefter påbegynder 1. line supporteren sit vanlige arbejde med at løse sagen
  7. Hvis sagen ikke kan løses af 1. line supporteren, så forberedes sagen på eskalation – der laves en opsummering af al korrespondance med brugeren, og formularerne i Cherwell udfyldes. 
  8. Dispatcher ved modtagende team i 2. line modtager sagen, og tjekker den ift. at de rette og tilstrækkelige oplysninger er i sagen.
  9. Dispatcher i 2. line tildeler sagen til specifik 2. line supporter
  10. 2. line supporter kan om nødvendigt kontakte brugeren ift. yderligere oplysninger.
  11. 2. line supporter påbegynder sit vanlige arbejde med at løse sagen.
  12. Når 2. line supporter har fundet en løsning på sagen, så gennemfører 2. line supporteren løsningen.
  13. Løsningen beskrives i sagen i en Journal Note af 2. line supporteren
  14. Sagen sendes tilbage til den helpdesk, hvor sagen var eskaleret fra
  15. Dispatcher tildeler sagen til relevant 1. line supporter
  16. 1. line supporter ændrer status på sagen til ”Resolved”, og udfylder løsningsbeskrivelse i "Resolution details".
  17. Cherwell-systemet sender en notifikation til brugeren, hvor brugeren kan genåbne sagen, svare ind i sagen eller blot lade sagen forblive i ”resolved” i 30 arbejdsdage, hvorefter systemet automatisk lukker sagen.

Prioriteringsmatrice

Her finder du et overblik over hvordan sager med forskellige prioriteter skal håndteres. Samt eksempler på prioriterede sager.

Prioriteringsmatrice og eksempler

Vejledninger

Her finder du vejledninger til henholdsvis agenter og slutbrugere.

Vejledning - Agenter

Vejledning - Slutbruger

CSI Governance

CSI processen på AU dækker forbedringer for processerne Incident Management og Request Fulfilment, samt ITSM-værktøjet Cherwell. Samtlige ændringsforslag oprettes i Cherwell – opret et ændringsforslag i servicekataloget under /Administration/Cherwell/Ændringsforslag.

CSI ændringsforslag behandles først af Procesforvaltningen, hvor den lokale Proces manager vil gå i dialog med forslagsstilleren. Ved antagelse af et ændringsforslag til videre prioritering foretager ITSM Systemforvaltningen en vurdering af opgavens omfang. Sidenhen bliver ændringsforslagene prioriteret, først sammen med Procesforvaltningen, sidenhen endegyldigt i CSI-forum. CSI-forum består af procesejer og CSI-formand. Oplysninger om ændringsforslags status og eventuelle prioritering vil på sigt være tilgængelig i Cherwell værktøjet.

CSI Governance processen for indberetning af ændringer

Procesforvaltningen

Ved indførelsen af de tre ITIL-processer er der også indført en enhed, AU ITSM Procesforvaltning, der varetager ejerskab, vedligeholdelse og udvikling af processerne. Procesforvaltningens deltagere, procesejer og Proces managers, kommer fra alle de parter, der deltager i ITSM-projektet – AU’s supportenheder, AU IT, HR IT, Økonomisystemer og Uddannelse. Ved behov for en snak om ITSM generelt og de AU-processer, der på denne side er beskrevet specifikt, kan I kontakte jeres lokale Proces manager:

Margit Grønborg – procesejer

Susanne Gram – Proces manager – AU IT

Mette Vigen – Proces manager - Økonomisystemer

Tine Vogelius Mikkelsen – Proces manager – BSS IT

Jens Ole Jensen – Proces manager – Nat-Tech team 1

Martin Kruse Olsen – Proces manager – Nat-Tech team 2

Erik Hein Møller – Proces manager – Arts IT

Simon Baghlani Reffsøe - Proces manager – Arts IT

Danny Maikær Christensen – Proces manager – Health IT

Birgitte Schrøder – Proces manager – Uddannelse

Thomas Kvist Nielsen – CSI-formand