230 lines
7.3 KiB
Markdown
230 lines
7.3 KiB
Markdown
# 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 faciliterer 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), "Resolved" (closed).
|
|
|
|
System faciliterer 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 titel og beskrivelse.
|
|
|
|
Når kunden har oprettet en ticket, bliver den automatisk assignet til en 1st level supporter (specifikt 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 firmaet (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 Windows 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|