Dag 2 – Incident og request fullfillment

Operation support and analysis Event management Incidents Request Fullfilment Servicedesk Problem management Establish root cause Access management Service Operation Functions Technical management IT Operations management Application management Technology and Implementation

Incident Incident Workaround En ikke-planlagt afbrydelse af en it-service eller en reduktion i kvaliteten af en it-service Workaround En måde at reducere eller eliminere Impact ved et Incident eller Problem, der endnu ikke er fundet en endelig løsning på

Incident processen mål At genetablere normal Service så hurtigt som muligt for at minimere en negativ påvirkning på forretningen Foreslå forbedringer af services pba incidents Foreslå yderligere services eller opkvalificering af medarbejdere og/eller brugere. Hvad er det dyreste ved IT? - eller Hvad er det kunden betaler for? IT er dyrest når det ikke virker – tid på udbedring internt, håndtering af kunder, bod, kundeflugt, manglende betaling etc. Kunden betaler for at kunne anvende en service – incident Mng skal hjælpe ham til at kunne det så meget som muligt..

Incident management Omhandler de hændelser der forringer eller truer med at forringe en Service Hvad er forskellen på en event og en incident? Tidsgrænser – hvilke, hvorfor? ITIL startes ofte her – meget synligt og nemt at dokumentere effekt.

Incident management Standard Incidents Major incidents Eskalering Eksempler? Major incidents Eskalering Functional Hierarkisk

Forventet løsningstid Incident management Prioritering Impact Prioritet Forventet løsningstid Urgency Impact Prioritet Løsningstid Høj Medium Lav 1 < 1 time 2 < 8 time 3 < 24 time 4 < 48 time 5 planlagt Urgency

Incident - Processen Incident Identifikation Incident Logging (Id, dato, bruger, kilde, kunde etc.) Incident Kategorisering (hw, sw, etc.) Incident Prioritering (urgency (hvor hurtigt behøves en løsning) og impact (hvor mange/hvilken brugere berøres)) Indledende Diagnose Incident Eskalering (2. level support) – Fkt eller hierark. Undersøgelse og diagnose Resolution og Recovery Incident Closure

Incident Udfordringer: -Opdage incidents så hurtigt som muligt -Alt skal logges -Tilgængelighed til kendte problemer -Samarbejde med SLM Målinger: -Antal i alt/pr. medarbejder -Tid

Incident Snitflader: Problem Mng. Configuration Mng Change Mng Capacity Mng Availability Mng Service Level Mng

Request fullfillment Service Request En anmodning fra en bruger om information eller rådgivning, om gennemførelse af en standard change eller om adgang til en service

Request fullfillment Beskæftiger sig med Service request fra brugerne Foruddefineret godkendelse Planlagt Low cost Low risk High frequency minor changes Giv eksempler Giver info til brugere og kunder om tilstedeværelse af en service og proceduren for at få den

Request fullfillment Tilgås via Service desk Kan håndteres helt eller delvist af Incident management processen Nogle requests kan med fordel lægges i et self service web-interface

Request fullfillment Målepunkter Periodevis Antal Service requests Udvikling i antallet af uløste service requests Gennemsnitlig pris pr Service request Periodevis Kan nedbrydes pr. type service request

opgave Hvordan vil I organisere Incident management og Request fullfillment? Hvilke krav vil I stille til et sagsbehandling system - Begrund valgene Lav en procedure for, hvordan incidents identificeres, logges, kategoriseres, prioriteres, løses, eskaleres og lukkes – herunder: tidsgrænser for hvert step, hvordan identificeres incidents bedst/hurtigst, hvilke informationer skal logges, hvilke kategorier vil I anvende, hvordan vil I prioritere, tidsfrister, hvad kan hjælpe medarbejderne ift løsning af incidents, hvem eskaleres til, hvad skal gøres inden incidents lukkes? Lav procedurer for, hvordan Incident managemet arbejder sammen med Problem management og Configuration management Lav en procedure/ retningslinier for Service request Hvordan sikres at den, der spørger, har rettighed til en service Hvordan vil I lave Request Fulfilment? Hvilke requests skal de varetage? Kan et incident ”vokse” til et Problem?