diff --git a/projekt.md b/projekt.md index d866711..b4d3f94 100644 --- a/projekt.md +++ b/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/ -![](project/screenshot.png) +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 + +![](projekt/service-catalog-1.png) +![](projekt/service-catalog-2.png) + +### 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. + + +![](projekt/screenshot.png) ## Eksempel organisation @@ -133,77 +225,6 @@ Eftersom 2nd level har fundet ud af at den der driver skal installeres på alle ![](projekt/scenario-2-14.png) ![](projekt/scenario-2-15.png) -## 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 - -![](projekt/service-catalog-1.png) -![](projekt/service-catalog-2.png) - -### 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. - - -