# projekt

## System

Vi har lavet et Ticket management system.

https://github.com/mtkonge/ticket-system

## Scenarie 1

Systemet er sat om til ekstern support. Organisationen yder IT-support og print-service.

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

![](projekt/scenario-1-flowchart.png)

### Eksempel

Kunden logger ind på systemet og laver en ticket.

![](projekt/scenario-1-1.png)
![](projekt/scenario-1-2.png)
![](projekt/scenario-1-3.png)
![](projekt/scenario-1-4.png)
![](projekt/scenario-1-5.png)

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.

![](projekt/scenario-1-6.png)

Nu er en 1st level IT-supporter mødt på arbejder, så de logger ind på systemet.

![](projekt/scenario-1-7.png)
![](projekt/scenario-1-8.png)

Og her kan supporteren se de tickets, som er blevet assignet til dem.

![](projekt/scenario-1-9.png)
![](projekt/scenario-1-10.png)
![](projekt/scenario-1-11.png)

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".

![](projekt/scenario-1-12.png)
![](projekt/scenario-1-13.png)

Nu hvor problemet er blevet fixet, kan supporteren markere ticket'en "Resolved".

![](projekt/scenario-1-14.png)

## Scenarie 2

System er sat om til ekstern support. Organisationen yder IT-support, levering af PC og print-service.

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

![](projekt/scenario-2-flowchart.png)

### 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.

![](projekt/scenario-2-1.png)
![](projekt/scenario-2-2.png)
![](projekt/scenario-2-3.png)

Kunden har nu oprettet en ticket i system, som automatisk vil blive assigned til en 1st level IT-supporter (LevelOneTime i dette tilfælde).

![](projekt/scenario-2-4.png)

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.

![](projekt/scenario-2-5.png)
![](projekt/scenario-2-6.png)
![](projekt/scenario-2-7.png)
![](projekt/scenario-2-8.png)

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).

![](projekt/scenario-2-9.png)
![](projekt/scenario-2-10.png)

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å.

![](projekt/scenario-2-11.png)

2nd level lukker ticket'en.

![](projekt/scenario-2-12.png)

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.

![](projekt/scenario-2-13.png)
![](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.

### 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.






