add småopgaver
This commit is contained in:
parent
64397d1325
commit
19406edea3
145
README.md
145
README.md
@ -1 +1,146 @@
|
||||
# service-management
|
||||
|
||||
## 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
|
||||
|
||||
### 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?).
|
||||
Se Servicedesken udefra:
|
||||
Beskriv hvilke forventninger du som intern bruger hhv.
|
||||
ekstern kunde vil have til en IT Service Desk.
|
||||
Hvilke veje vil du gå, hvis du ikke får en tilfredsstillende
|
||||
service fra supporteren/servicedesken ?
|
||||
Vil de være forskellige efter om du er ekstern kunde eller
|
||||
intern bruger ?
|
||||
Se servicedesken indefra:
|
||||
Beskriv hvilke værktøjer du har brug for for at
|
||||
• 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).
|
||||
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
|
||||
|
||||
### Opgave C: (vedrører målpinde 5 og 6)
|
||||
|
||||
Hvad er forskellen på service request og incident(fejl).
|
||||
Hvordan skal de to håndteres og hvad er forskellene i
|
||||
håndteringen.
|
||||
Beskriv hvad du vil gøre hvis en bruger/kunde ikke
|
||||
medvirker aktivt/konstruktivt til at få en sag/ticket lukket.
|
||||
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
|
||||
|
||||
### 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).
|
||||
|
||||
### 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
|
||||
|
||||
### 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
|
||||
|
||||
### 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.
|
||||
Overvej hvilke der vil have mest mening i jeres rolle på jeres
|
||||
arbejdsplads.
|
||||
Overvej også hvor metoderne passer ind i
|
||||
escaleringshierakiet - hvor er hvilken metode mest
|
||||
anvendelig.
|
||||
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+manage
|
||||
ment+technique+should+we+use
|
||||
og
|
||||
https://web.archive.org/web/20150319060500/https://ksc
|
||||
sma.ksc.nasa.gov/Reliability/Documents/Ganos_compariso
|
||||
n_the_Root_Cause_Analysis_Methods.pdf
|
||||
|
||||
### 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
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user