asd
This commit is contained in:
SimonFJ20
parent
63a65df2aa
commit
5c9b5a4e9e
175
projekt.md
175
projekt.md
@ -1,9 +1,9 @@
|
||||
# Service management projekt
|
||||
|
||||
Mikkel TK
|
||||
Remiar PB
|
||||
Simon FJ
|
||||
Thies PBH
|
||||
- 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
|
||||
@ -13,9 +13,101 @@ https://git.reim.ar/h2/service-management/src/branch/main/projekt.md
|
||||
Vi har lavet et Ticket management 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
|
||||
|
||||
@ -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