asd
This commit is contained in:
SimonFJ20
parent
63a65df2aa
commit
5c9b5a4e9e
175
projekt.md
175
projekt.md
@ -1,9 +1,9 @@
|
|||||||
# Service management projekt
|
# Service management projekt
|
||||||
|
|
||||||
Mikkel TK
|
- Mikkel TK
|
||||||
Remiar PB
|
- Remiar PB
|
||||||
Simon FJ
|
- Simon FJ
|
||||||
Thies PBH
|
- Thies PBH
|
||||||
|
|
||||||
Kan også læses her:
|
Kan også læses her:
|
||||||
https://git.reim.ar/h2/service-management/src/branch/main/projekt.md
|
https://git.reim.ar/h2/service-management/src/branch/main/projekt.md
|
||||||
@ -13,9 +13,101 @@ https://git.reim.ar/h2/service-management/src/branch/main/projekt.md
|
|||||||
Vi har lavet et Ticket management system.
|
Vi har lavet et Ticket management system.
|
||||||
|
|
||||||
https://github.com/mtkonge/ticket-system
|
https://github.com/mtkonge/ticket-system
|
||||||
https://ticket.reim.ar/
|
|
||||||
|
|
||||||
|
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
|
## Eksempel organisation
|
||||||
|
|
||||||
@ -133,77 +225,6 @@ Eftersom 2nd level har fundet ud af at den der driver skal installeres på alle
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
## Om vores system
|
|
||||||
|
|
||||||
### 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.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user