service-management

Begreber

5 Why's

Ishikawa

Småopgaver

Opgave A: (adresserer Målpind 1 og 2)

Beskriv roller tæt på 1st level support og lav en detaljeret rollebeskrivelse for hver af dem.

Inspiration:

kapitel 4 i Practical IT Service Management, 2nd Edition (ligger i kataloget Litteratur)

https://www.atlassian.com/it-unplugged/itsm/help-desk-vs-service-desk-vs-itsm

Svar

• ITSM - The end-to-end delivery of IT services to customers, ie. all the processes and activities to design, create, deliver, and support IT services.
• Service desk - The single point of contact between the service provider and the users.
• Help desk - A group of people who provide help and information usually for electronic or computer problems.

Opgave B: (adresserer målpindene 3 og 4)

Undersøg begrebet Service Level Agreement(SLA) og beskriv hvordan en SLA kan gøre 1st level supporterens arbejde nemmere (eller sværere?). (1)

Se Servicedesken udefra:

Beskriv hvilke forventninger du som intern bruger hhv. ekstern kunde vil have til en IT Service Desk. (2)

Hvilke veje vil du gå, hvis du ikke får en tilfredsstillende service fra supporteren/servicedesken ? (3)

Vil de være forskellige efter om du er ekstern kunde eller intern bruger ? (4)

Se servicedesken indefra:

Beskriv hvilke værktøjer du har brug for for at (5)

• kommunikere med og indgå aftaler med kunden/brugeren
• dokumentere den enkelte kundesag (service request eller incident)
• afslutte den enkelte kundesag, hvis du selv kan gøre det
• eskalere/overdrage sagen til andre
• holde snor i sagen så den ikke dør i systemet
• bevare viden om sagstypen til genbrug

En god måde at tænke på kan være, hvilke handlinger eller standardprocesser du skal udføre/gennemløbe for hver sag. Tegn herefter en incidents og en service requests livsforløb som rutediagram(flow chart). (6)

Inspiration:

https://freshservice.com/it-service-desk-software; særligt afsnittene IT Service Desk Best Practices og Software that Support an IT Service Desk

Læs også

http://www.itilfromexperience.com/Why+every+process+flow-chart+should+have+a+swim-lane+for+the+Service+Desk

Til rutediagrammet kan i kigge på

https://www.conceptdraw.com/samples/business-process-diagrams-flow-charts

Tag udgangspunkt i eksempel 1, men husk at tænke over hvad der er rigtigt i jeres miljø.

Brug også eksempel 5 og lav jeres rutediagram med svømmebaner for fx service desk operatør, intern bruger, ekstern kunde, 2nd level person, 3rd level/ekstern leverandør/udviklingsafdeling. (hvis svømmebanerne giver tekniske udfordringer med jeres grafikprogram må i gerne tegne i hånden og scanne ind via mobil)

Og så er det den rene ITIL, kig kort på den til forståelse af at 1st line er en del af en større verden:

https://wiki.en.it-processmaps.com/images/7/73/Incident-management-itil.jpg

Svar

1. En SLA kan hjælpe med prioritering af requests og incidents, men kan også gøre det besværligt at yde service.
2. Vi tænker at forventninger til de to respektive vil være forholdsvis sammenlignelige, men om IT-supporterne er medarbejder eller et seperat firma, kan have en indflydelse.
3. Complain eller skift udbyder.
4. Ja, eksterne kunder kan skifte udbyder
5. Hver function kan selvfølgelig blive udført af et respektivt værktøj, men hvis for at have samling på det, kan man bruge en IT-support platform, som ServiceDesk eller Jira.
6. Se diagram nedenfor. Rhomber er beslutninger. I diagrammet ligger ticket'ens ansvar ved den nuværende supporter, om det så er en 1st, 2nd eller 3rd level. Gennem forløbet bliver information samlet både fra og til intern knowledge, men også information fra kunden. (om pilen til kundeinformation skulle være envejs kan diskuteres). Ticket-forløbet garantere at beslutningen om løsbarhed tages af de mest egnede personer i organisationen og/eller i overenstemmelse med SLA og servicekatalog, (3rd level inkludere også personer med beslutningsanvar). Diagrammet viser det ikke, men alle beslutninger er i overenstemmelse med organisationens SLA.

Opgave C: (vedrører målpinde 5 og 6)

Hvad er forskellen på service request og incident(fejl). (1)

Hvordan skal de to håndteres og hvad er forskellene i håndteringen. (2)

Beskriv hvad du vil gøre hvis en bruger/kunde ikke medvirker aktivt/konstruktivt til at få en sag/ticket lukket. (3)

Inspiration:

• https://itsm.tools/service-desk-basics-what-to-do-when-the-end-user-doesnt-respond/
• https://www.atlassian.com/itsm/service-request-management
• https://medarbejdere.au.dk/institutter/auit/nsp/incident-management-processen/
• https://www.seriosoft.com/blog/introducing-incident-management
• https://www.seriosoft.com/blog/incident-life-cycle
• https://www.seriosoft.com/blog/escalation-incident-management?p=94

Svar

1. En service request er en forespørgsel om en ændring mens en incident er en fejl eller på anden vis noget som ikke burde ske.
2. Incidents er typisk mere akutte og håndteres med højere prioritet, da det kan have en dårlig effekt på firmaet hvis de ikke håndteres, mens service requests er ofte mindre vigtige da de handler om forbedring af noget der i forvejen virker.
3. Jeg vil periodisk sende en rykker til brugeren/kunden hvis vedkommende ikke svarer. Hvis bruger ikke svarer i længere tid, kan man lukke ticket'en.

Opgave D( vedrører målpindene 7 og 8):

Beskriv en procedure for levering af en ny PC til en slutbruger.

Stikord:

• kasseflytning/fysisk logistik
• domæne/AD, VLAN, specielle applikationer
• hvem betaler - hvilken dokumentation er standard
• registrering (asset management)
• gl PC ?

Tegn proceduren som et flowchart(rutediagram).

Svar

Bruger har oprettet en service request ticket om en ny PC. En 1st level supporter har vurderet at ticket'en kan løses af 1st level ud fra SLA'en. 1st level supporteren skaffer en computer fra logistik eller køber en hjem. Når supporteren har fået computeren, sætter personen operativ system, rights management service/AD, netværk og andet op på computeren, så den er klar til brugeren. Supporteren registrerer computeren i systemet. Supporteren leverer computeren til brugeren, og får den gamle. Supporteren registerer PC'erne i system, som afhentet og indleveret respektivt. Kunden betaler i overenstemmelse af SLA og servicekatalog.

Opgave E(vedrører målpind 9):

Udarbejd en skabelon, der kan benyttes til beskrivelse af alle standardiserede service requests.

Eksempler der skal passe ind kunne være

• standard IT-pakke til ny medarbejder
• ændring af kodeord udenfor fast cyklus
• aktivering af stik på kontor

Inspiration:

Litteratur\Bilag_2-_Servicekatalog.pdf

Svar

• Service beskrivelse - Kort forklaring af kundens behov og service'ens formål.
• Hvad er omfattet - Beskrivelser af konkrete ydelser
• Tilgængelighed - Beskrivelse af hvem, hvor, hvornår, osv. i forhold til service'ens relevans og tilgængelighed
• Forudsætninger og afgrænsinger - Bestingelser for service'en
• Afregning - Hvordan kunden skal betale for service'en, hvis relevant.

IT-pakke til nye medarbejdere:

• Service beskrivelse: Anskaffelse af standard IT-pakke til nye medarbejdere.
• Hvad er omfattet: Medarbejder modtager en PC, sat op med Linux, Samba og Libreoffice.
• Tilgængelighed: Tilgængelig for alle nye medarbejdere. Tilgængelig i tidsrummet 8-15 på hovedkontoret.
• Forudsætninger og afgrænsninger: Kun 1 pr medarbejder.
• Afregning: Koster 5.000 kr. pr. gang.

Ændring af kodeord manuelt:

• Service beskrivelse: Ændring af kodeord til konto manuelt.
• Hvad er omfattet: En kunde kan få ændret sit password til et andet.
• Tilgængelighed: 8-15, via mail, telefon eller fysisk på hovedkontoret.
• Forudsætninger og afgrænsninger: Man kan kun skifte password 1 gang dagligt.
• Afregning: Services koster fast 10.000 kr. om måneden.

Aktivering af stik på kontor

• Service beskrivelse: Aktivering af stik på kontor
• Hvad er omfattet: En kunde skal forespørge et specifikt ethernet-stik aktiveret på et kontor.
• Tilgængelighed: 8-12 med aftale. Aftalt via. mail, telefon eller fysisk.
• Forudsætninger og afgrænsninger: Stikket skal være installeret rigtigt på et officielt konter.
• Afregning: Koster fast 5.000 kr. om måneden og 100 kr. pr. gang.

Opgave F: (vedrører målpindene 10 og 12)

Udarbejd en skabelon, der kan benyttes til at beskrive et fejlforhold/incident.

Inspiration: dokumentet Litteratur\Incident-Management-Process-Description-v1.pdf

Svar

• Formål - hvorfor

Skabelon:
---
Nr.: #[id]
Baseret på kundesag: #[ticket id]
Beskrivelse: [kort beskrivelse]
Fix: [fix steps]
Notes: [notes]
===
Eksempel:
---
Nr.: #8
Baseret på kundesag: #914 - "Kan ikke forbinde til internettet"
Beskrivelse: kunden kan ikke få forbindelse til internettet, men kan tilgå lokale services som f.eks. intranet
Fix: 
0. Verificer, at kunden ikke kan tilgå internettet og kan tilgå intranettet
`ping google.com`
Hvis den kan pinge, har problemet løst sigselv.
`ping intranet`
Hvis den ikke kan pinge, se [incident #4 - kan ikke forbinde til services på lokalt netværk]
1. Verificer, om problemet er med dns at gøre.
`ping 8.8.8.8`
Hvis den kan pinge, se [incident #3 - dns konfiguration]
2. Verificer, at client firewall er konfigureret korrekt
Se [incident #5 - windows defender konfiguration]
3. Verificer, at gateway firewall kan kontaktes
`ping 192.168.1.1`
Hvis ikke, se [incident #6 - gateway firewall kan ikke kontaktes]
4. Verificer, at gateway firewall er konfigureret korrekt
Se [incident #1 - pfSense konfiguration]

Opgave G: (vedrører målpind 11)

Internt i hver gruppe skal I få et overblik over problemløsningsmetoderne 5-Whys, Ishikawa, Kepner- Tregoe, Swarming, Pareto Analysis, Brain-storming og Affinity Mapping.

Prøv at gruppere metoderne og se hvilke af metoderne, der kan supplere hinanden. (1)

Overvej hvilke der vil have mest mening i jeres rolle på jeres arbejdsplads. (2)

Overvej også hvor metoderne passer ind i escaleringshierakiet - hvor er hvilken metode mest anvendelig. (3)

I nedenstående inspirationslink er der omtalt endnu flere metoder - dem kan I også med udbytte kigge på.

Inspiration:

• http://www.itilfromexperience.com/Which+problem+management+technique+should+we+use
• https://web.archive.org/web/20150319060500/
• https://kscsma.ksc.nasa.gov/Reliability/Documents/Ganos_comparison_the_Root_Cause_Analysis_Methods.pdf

Svar

1. 5-whys, Ishikawa og Brain-storming er root cause analysemethoder. Kepner-Tregoe, affinity mapping og pareto er til at tage beslutninger ud fra det information man har. Swarming er en methode til løsning af større incidents.
2. Brain-storming og Ishikawa er kan være forholdsvis relevante til software udvikling.
3. 5-whys, Ishikawa og Brain-storming er til samling af information og kan bruges gennem hele forløbet. Kepner-Tregoe, affinity mapping og pareto, er mest promonemt højere i hierakiet. Swarming er mest brugt øverst i hierakiet.

Opgave H (fremlæggelsesopgaven)

Her skal I gå lidt dybere med de to metoder jeres gruppe er tildelt og forberede en fremlæggelse for klassen.

Prøv at få både metodens historie og dens anvendelighed i eller tæt på 1st level med. Hvis I kan argumentere for at en metode ikke er nyttig er det også relevant.

Referencer til og sammenligning med øvrige metoder vil være fint

https://en.wikipedia.org/wiki/Five_whys https://en.wikipedia.org/wiki/Ishikawa_diagram