Hendelsestyring (Incident Management)

1. Hendelsestyring (Incident Management)

2. Terminologi • Incident, hendelse: En hendelse på et tidspunkt (event) som ikke er en del av den normale utførelsen av tjenestetilbudet, og kan forårsake avbrudd eller redusert kvalitet på en tjeneste. • Hendelse kan være en følge av feil i maskinvare eller programvare, eller alle typer forespørsler fra kundene/brukerne.

3. Formålet med prosessen: • Gi raskt svar til kundene • Gjenopprette en tjeneste så raskt som mulig til normalt tjenestenivå etter en hendelse • Sikre best mulig utnyttelse av tilgjengelige ressurser • Opprette og benytte en standard rutine for håndtering av kundehenvendelser

4. Eksempler på hendelser: • Program har redusert ytelse eller tilgjengelighet • Maskinvare er nede eller delvis nede • Tjenesteforespørsler fra kundene • Brukerstøtte - en nøkkelrolle for service desk • Registrere hendelser • Overvåke progresjon av gjenoppretting av tjenester • Ansvar og eierskap til hendelsene

5. Kundeforespørsler • Forespørsler som ikke skyldes feil i infrastrukturen kan omfatte: • Hjelp • Programvareleveranse • Informasjon • Råd om program- og maskinvare • Dokumentasjon av program- og maskinvare • Hjelp kan inkludere: • Spørsmål om funksjonalitet eller informasjon om et programvareprodukt • Status når det gjelder gjenoppretting av en tjeneste • Passord • Datagjenfinning/datalagring • Registrering av brukere

6. Prioritering • Hendelser skal prioriteres etter visse kriterier: • Konsekvenser for kunden: Graden av avvik fra det normale/avtalte tjenestenivået. Jo alvorligere konsekvenser hendelsen vil ha for kunden, desto høyere må hendelsen prioriteres. • Hvor presserende er hendelsen? Hvilken forsinkelse kan kunden tåle før normalt tjenestenivå må være gjenopprettet? Jo raskere tjenestenivået må gjenopprettes, desto høyere må hendelsen prioriteres.

7. Eskalering, opptrapping • Hvis en hendelse ikke kan løses av første-linje brukerstøtte (service-desk) innen gitte tidsrammer, så må mer ekspertise eller autoritet koples inn. • To typer eskalering: • Funksjonell eskalering: Involver personell med mer spesialisert kompetanse, eller med utvidede tilgangsrettigheter (administrator, superbruker). • Hierarkisk eskalering: Involver personell med mer administrativ eller økonomisk autoritet på ledelsesnivå. Ressurs eskalering.

8. Tjenestestøtte nivåer • Første-linje støtte: Leveres vanligvis av Service desk (kundemottak, skranke, orakel, og lignende.) • Andre-linje støtte: Leveres av de enkelte administrative enhetene, med mer spesialisert kompetanse innenfor sitt tjenesteområde og med autoritet til å omdisponere ressurser. • Tredje-linje støtte: Leveres av IT-utviklingsavdelingen, med spesialisert kompetanse innen bl.a. programvareutvikling, system- og applikasjonsprogramvare, nett og maskinvare. • Fjerde-linje støtte: Leveres av IT-leverandørene.

9. Kompetansekrav • Første-linje støtte: • Like og ha evne til å behandle kunder • Ha inngående kjennskap til organisasjonen • Ha god innsikt i tjenestetilbudet • Ha god erfaring med og like å løse akutte problemer raskt • Ha god kompetanse i bruk av IT-støtteverktøyet. • Andre-linje støtte: • Ha nødvendig administrativ autoritet • Ha spesialisert kompetanse innefor den aktuelle tjenesten • Tredje-linje IT-støtte: • Ha god generell kompetanse i IT: arkitektur, programmering, programvare, maskinvare. • Ha spesialisert kompetanse i programvare utvikling, eller i drift og vedlikehold av IT-infrastrukturen.

10. Støtteprosesser • Konfigurasjonsstyring, CMDB. Viser relasjoner mellom ressurser, tjenester, brukere og tjenestenivå. Angir hvem som kan ta seg av ulike typer hendelser, hvordan nødløsninger kan iverksettes, osv. • Problemløsning. Støtter prosessen med å identifiserer underliggende feil, holde oversikt over problemsituasjoner, kjente feil, nødløsninger, og midlertidige reparasjoner. • Endringsstyring. Problem kan løses ved å implementere endringer. Endringsstyring holder oversikt over planlagte endringer og deres status. Endringer kan medføre hendelser. • Tjenestenivåstyring. Holder rede på kundeavtalene, SLA. SLA brukes ved kommunikasjon med brukeren, og behandling av hendelser.

11. Service desk aktiviteter • Hendelser kan oppdages og rapporteres av: • Bruker/Kunde. Rapporterer til Service Desk via telefon, e-post, post eller oppmøte. • Systemet. Programvare- eller maskinvarefeil. • Andre henvendelser via telefon, e-post eller oppmøte. • Mottak og registrering. Det opprettes en hendelsepost med følgende informasjon: • referanse nummer, tidspunkt, symptomer, bruker, mottaker, lokalisering, berørte tjenester og maskinvare. • Melding til andre berørte brukere og avdelinger.

12. Klassifisering av hendelser • Kategori • Sentral prosesseringsenhet: maskinvare, programvare. • Nett: Router, nettsegment, hub, IP adresse, osv. • Arbeidsstasjon: Skjerm, nett tilkobling, disk, tastatur, mus, osv. • Bruk og funksjonalitet: bruk av tjenesten, kapasitet, tilgjengelighet, kommunikasjon • Organisasjon og prosedyrer: bestilling, forespørsel, støtte, kommunikasjon. • Tjeneste ønske: støtte, leveranse, informasjon, råd, dokumentasjon, og lignende.

13. Prioritering. • Hvem skal behandle hendelsen. • Tid. Anslått max. tid det vil ta å gjenopprette akseptabelt tjenestenivå. • Status: Ny, akseptert, planlagt, tilordnet, aktiv, stanset, løst, lukket.

14. Matching. Sammenlign med tidligere hendelser for om mulig å finne en løsning. • Undersøkelse og diagnose. Hendelsen oversendes deretter en ekspertgruppe for undersøkelse og diagnose. • Løsning og gjenopprettelse (recovery). • Avslutt. Service desken gir tilbakemelding til personen som meldte om feilen, og lukker hendelsen.

15. Prosess kontroll: Hendelsestyring • Rapporter til ulike målgrupper: • Hendelsestyring: • Identifiser manglende ledd i prosessen • Identifiser konflikter med SLA • Identifiser tendenser i håndteringen av hendelser • IT støttegruppe: • Oversikt over løsning av hendelser • Løsningstid i de ulike støttegruppene • Tjenestestyring: • Informasjon om kvaliteten på tjenestene • Måling av faktisk tjenestenivå

16. Måleindikatorer • Totalt antall hendelser. • Gjennomsnittlig løsningstid. • Gjennomsnittlig løsningstid etter prioritet. • Prosentvis andel av hendelsene som er løst innenfor SLA kravene. • Prosentvis andel av hendelsene som er løst av første-linje støtte, service desk. • Gjennomsnittlig kostnad pr. hendelse. • Antall løste hendelser pr. arbeidsstasjon eller pr. ansatt. • Antall hendelser løst uten å gå til brukeren. • Antall hendelser med riktig initiell klassifisering. • Antall hendelser som videresendes riktig.

17. Kostnader og mulige problemer • Kostnader: • Initiell implementasjon av tjenesten • Opplæring og instruksjon • Innkjøp av støtteverktøy • Løpende utgifter til personell og bruk av verktøyet • Problemer • Brukere og IT personell gjør ikke bruk av IM (Incident management) • For mange hendelser, slik at hendelsene ikke registreres nøyaktig. Unøyaktig diagnose fører til at løsningsarbeidet blir mindre effektiv. • Eskalering. Hendelser som ikke løses raskt vil forsterke problemene, som igjen vil kreve mer innsats fra spesialistgruppene. • Mangel på avtaler. Hvis tjenesteavtalen og tjenestenivået er uklart definert, så vil det bli vanskelig for IM å prioritere håndtering av hendelsene. • Mangel på forpliktelse. Det kreves en høy grad av forpliktelse både fra ledelsen og fra de ansatte for å løse hendelser basert på en prosess tilnærming.

18. Oppsummering • Hendelsestyring skal redusere eller fjerne uønskede følger for brukere eller kunder av forstyrrelser i IT-tjenestene. Siktemålet er å få kunden eller brukeren i normal virke så raskt som mulig etter et avbrudd. • Hendelser loggføres, klassifiseres og rutes til passende spesialistgrupper for behandling. • Melding om hendelser mottas av service desk, som fungerer som forkontor til de underliggende spesialistavdelingene. • Hendelser kan løses på ulike nivåer i organisasjonen.