7.3 KiB
Service management projekt
- Mikkel TK
- Remiar PB
- Simon FJ
- Thies PBH
Kan også læses her: https://git.reim.ar/h2/service-management/src/branch/main/projekt.md
System
Vi har lavet et Ticket management system.
https://github.com/mtkonge/ticket-system
https://ticket.reim.ar/ (ikke sat op)
Se eksempler længere nede.
Om vores system
Vi har forsøgt at lave systemet, som vi forestiller os et ticket management system ud fra undervisningen.
Der er 3 roller i vores system: Kunde, Supporter og Admin. (Supporter dækker over og systemet skelner mellel 1st, 2nd og 3rd level)-
Kunder kan oprette tickets. Tickets assignes automatisk til 1st level.
Supportere kan se og håndtere tickets assignet dem individuelle supportere.
Systemet facilitere kommunikation mellem kunder og supportere, og logger alt interaktion. Kommunikation foregår med kommentarer på tickets.
Tickets kan re-assignes og eskaleres.
Med tickets skelnes mellem "Incident" og "Request". Og tickets har en status, herunder "Open" (venter på support), "Pending" (venter på kunde), "Reslved" (closed).
System facilitere en knowledge base, via. dokumenter man interne (supporter og admins) kan oprette, læse og redigere i.
Man kan markere 2 dokumenter, som man vil bruge som SLA og Service catalog. Disse 2 dokumenter kan alle tilgå.
Noter
Kunden vælger selv om en ticket er "Incident" eller "Request". Det burde være en 1st level, som træffer den beslutning. Nuværende kan 1st level ændre det efterfølgende.
Features vi har
Service catalog
Manglende features
Større incidents
I tilfælde af at mange brugere laver den samme slags incident ticket, ville det være smart hvis system kunne genkende større incidents, for så at prioritere den højere eller hvad man ellers kunne finde på.
Prioritering af tickets
Vores nuværende system kan ikke skelne mellem små incidents (f.eks. printer der ikke virker) og store incidents (f.eks. kontor mangler internet). Prioritering af tickets er yderst vigtigt, så man kan prioritere arbejdskraften.
Standardiserede ticket skabeloner
En måde at automatisere tickets på er ved at lave en standardiseret "creation guide", som går igennem de hyppigste problemer, (f.eks. er skærmen slukket, stikket sat i,...). Dette kan reducere mængden af nødvendig arbejdskraft, og afslå tickets som ikke er dækket af Service Cataloge eller SLA'en
Notifikationer
Manglen på notifikationer eller email opdateringer gør at det er svært for en kunde at vide hvornår en ticket er "Pending" (venter på brugeren).
Automatisk lukning af tickets
Hvis tickets ikke bliver svaret af en bruger i en længere periode, f.eks. 7 dage, ville det være smart hvis en blev lukket automatisk.
Sammenligning med Gruppe 1
Vi sammenlignede Gruppe 1's system med vores med et brugseksempel.
De brugte Jira.
Problem: En kunde kan ikke printe. Årsag: John har trådt på kablet og stikket er faldet ud. Løsning: Sæt stikket i igen.
Skabelse af ticket
I vores system har kunden kunde-adgang til system og kan selv lave en ticket, hvor kunden giver ticket'en en tittel og beskrivelse.
Når kunden har oprettet en ticket, bliver den automatisk assignet til en 1st level supporter (specifict den 1st level supporter med færrest åbne sager).
I deres Jira system har kunden ikke adgang, så en ticket skal laves af en intern supporter.
Når supporteren har lavet ticket'et, kommer den i en backlog, og så er det op til 1st level supporterne, selv at tage ticket'en.
Kunde kontakt
I vores system foregår alt kontakt med kunden (ideelt) i system, så det hele er dokumenteret.
Siden kunden ikke er oprettet i deres system, kommer supporteren til at kommunikere med kunden udenfor systemet. Det gør at kommunikationen ikke nødvendigvis er logget og dokumenteret.
Eksempel organisation
Organisationen yder brugeradministration, IT-support, levering af PC og print-service.
Scenarie 1
Kunde kan ikke printe, på grund af mangel på internet.
Kunden har åbnet et Word dokument på deres computer, men når de prøver at printe dokumentet på printeren sker der ikke noget.
Flowchart
Eksempel
Kunden logger ind på systemet og laver en ticket.
Nu er ticket'en blevet oprettet og kunden kan se status på ticket'en.
System vælger automatisk en 1st level supporter, som den assigner ticket'en til.
Nu er en 1st level IT-supporter mødt på arbejder, så de logger ind på systemet.
Og her kan supporteren se de tickets, som er blevet assignet til dem.
Nu svarer supporteren med en besked og sætter ticket'ens status til "Pending", så brugeren ved at de skal svare.
(Her kunne det være smart ved et notifikationssystem, men det nåede vi ikke).
Nu er kunden logget ind igen, og kan se at ticket'en er "Pending".
Nu hvor problemet er blevet fixet, kan supporteren markere ticket'en "Resolved".
Scenarie 2
En kunde kan ikke printe, på grund af drivere.
Kunden vil gerne printe et word dokument ud på den printer, som firmeat (IT-firmaet) har leveret, men når kunden trykker på print, sker der ikke noget.
Kunden har lige fået ny PC, og organisationen er lige skiftet til at bruge Window 11 på alle kunders nye PC'er.
Flowchart
Eksempel
- CustomerJannet er kunde.
- LevelOneTim er 1st level IT-supporter
- LevelTwoAhmed er 2nd level IT-supporter
Kunden logger ind på IT ticket management systemet og opretter en ticket.
Kunden har nu oprettet en ticket i system, som automatisk vil blive assigned til en 1st level IT-supporter (LevelOneTime i dette tilfælde).
1st level vil nu samle information nok fra kunden, så de kan lave en beslutning om de kan løse problemet, skal eskalere eller skal lukke den af andre årsager.
1st level har nu vurderet at de ikke kan løse problemet, og eskalere derfor ticket'en til en bestemt 2nd level supporter (LevelTwoAhmed i dette tilfælde).
2nd level vil nu samle information, og vurdere ticket'en.
De har vurderet ticket'en til løsbar, så de forsøger på at løse problemet.
2nd level finder på en løsning, men opdager at der er et større problem, relaterende til den måde de nye PC'er er sat op på.
2nd level lukker ticket'en.
Eftersom 2nd level har fundet ud af at den der driver skal installeres på alle nye PC'er, laver de en guide i deres knowledgebase.
