ITIL: Hendelseshåndtering – Incident Management

Da den britiske regjering satte seg ned på 80-tallet for å skru sammen rammeverket som i fremtiden skulle bli kjent som ITIL, så visste de allerede to ting:

1. Datamaskiner er fremtiden, og vi må legge et sett med anbefalinger for standardisering av prosesser og verdikjeder rundt dette.
2. Datamaskiner har en tendens til å bryte ned, og det kommer de til å gjøre i en god stund fremover.

En hendelse er definert som et uplanlagt avbrudd eller reduksjon i kvaliteten på en IT-Tjeneste. Lettere forklart, når ting ikke nødvendigvis har gått deres vei og det koker godt på telefonen.

Selv om vi gjør referanser til endring og tjenestehåndtering vil denne artikkelen hovedsakelig ta for seg hvordan Pureservice kan støtte under hendelseshåndtering i deres organisasjon.

Hendelseshåndtering eller Incident Management, er en sentral ITIL praksis som befinner seg under “Leveranse og Support”.

Vi har skrevet syv tips til ITIL her om du ønsker å lese mer om de andre praksisene.

Hva er hendelseshåndtering?

Praksisen for hendelseshåndtering tar for seg hvordan vi behandler en hendelse fra den blir identifisert til den løses. Det gjelder å få tjenesten tilbake i normal drift. Rent teknisk sett skal brannen slukkes så raskt som mulig. Undersøkelsen for hvorfor brannen oppstod gjøres i en annen praksis; problemhåndtering.

Hver organisasjon har ofte sin egen smak på hendelseshåndtering, og det kan være en del forskjeller fra bedrift til bedrift. En generell prosess vil ha steg og livssyklus som ligner dette:

• Identifisering
• Logging
• Klassifisering
• Respons og diagnose
• Løsing og lukking

Basert på prioritet og omfang vil dere gjerne også ha et steg for rapportering og gjennomgang.

En livssyklus på en hendelse kan ofte være vanskelig å holde oversikt over. Heldigvis har Pureservice funksjoner som kan hjelpe både ditt operative personale, deres prosesseier og deres ledelse få full kontroll.

Hendelseshåndtering: identifisering

Identifisering skjer når noen oppdager et unormalt tjenesteavbrudd. Dette kan for eksempel være når deres løsning går ned og deres kunder ikke lenger får logget inn. Det kan også være når en printer tar fyr (igjen) eller et nøkkelkort ikke lenger åpner døren til datasenteret. Det oppdages at noe som har fungert før ikke lenger fungerer like godt. En hendelse har startet og det oppstår gjerne et ønske om å utbedre dette fra de som identifiserer den.

Identifisering faller fort utenfor hva Pureservice gjør, men når hendelser oppstår skal det komme klart frem hvor man skal henvende seg.

Hendelseshåndtering: logging

Logging skjer når hendelsen blir rapportert inn til riktig kanal og registrert for utbedring. For deg på IT betyr dette kanskje telefon eller e-mail, eller mye mulig du allerede ser flammene nede i korridoren. Uansett hvordan vi mottar meldingen, så må hendelsen registreres og logges.

Det er tross alt en av servicedeskens hovedoppgaver å ta imot ønske om å utbedre hendelser. Dette leverer Pureservice på.

Med Pureservice er det veldig enkelt å opprette en sak direkte eller via e-mail. Det er også mulig å rapportere inn hendelser ved et effektivt skjema på den innebygde selvbetjeningen. Saksmaler for hendelser kan hjelpe hvis det blir meldt inn via telefon og du må samle en del informasjon så klassifisering av hendelsen kan utføres.

Det er flere veier til Roma. Så lenge vi får rapportert en potensiell hendelse kan prosessen starte og utbedringen skje.

I Pureservice har vi tre inntak for logging av hendelse:

1. Direkte opprettelse av sak

Du får en telefon, en melding på Hangouts eller teams eller noen møter opp direkte.
I dette inntaket kan man i Pureservice sette opp enkle saksmaler for å gjøre jobben til saksbehandlerne dine litt enklere.

Snakker vi om en hendelse som har en easy-fix og kan gjøres direkte uten mye arbeid, kan du ha en saksmal som er forhåndsdefinert med klassifisering, tildeling og løses med en gang den opprettet. Alt du trenger å gjøre er å legge til sluttbruker så er dere ferdig.
Dette kan f.eks være «Re-installere Outlook» eller «Gjenoppretting av maskin».

Hvis saker ikke opprettes, så danner det seg heller ikke et datagrunnlag for analyse og rapportering. Saksregistrering bør være en enkel rutine. Enkle rutiner øker sjansen for at alle hendelses registreres. Vi kommer til hvorfor dette er viktig senere, men det er uhyre viktig å logge alle hendelser som oppstår.

Samme konsept kan gå igjen om dere vil registrere en hendelse som er noe mer kritisk.
Dere kan lage en saksmal for kritiske hendelser som inneholder hjelpetekst for deres saksbehandlere. Her kan dere hente ut viktig informasjon av de som tar kontakt.

Det kan oppleves som stressende å ta imot telefon eller melding fra en enda mer stresset person som forteller i stor grad at det er krisesituasjon hvor alt er nede og ingen får gjort jobben sin. Det gjelder å holde hodet kaldt og samle inn nok informasjon. Da har dere et godt grunnlag for å gjøre neste steg klassifisering, så effektivt og korrekt som mulig. I samme mal kan du også sette direkte tildeling om du allerede vet hvilket team som tar hånd om kritiske hendelser.

En ting som går igjen i slike situasjoner er behovet for å ringe opp sluttbruker og spørre om mer informasjon. Kan vi unngå uklare situasjoner, sparer vi oss for mye hodebry og frustrasjon.

2. E-post

E-post vil kanskje være standard måte for inntak av saker til deres Pureserviceinstans. For mange kan e-post være et kjent og naturlig sted å rapportere hendelser.

Selv om e-post er traust og solid, så er det tross alt to fritekstfelt. Emne og innhold. Det er ikke ukjent at hvis en sluttbruker ikke gir klar og tydelig informasjon per e-post, kan henvendelsen bli skummet over og en potensiell hendelse «falle imellom stolene». Det er få ting som er kjipere enn å finne ut at en hendelse har pågått en stund, men ingen har plukket det opp. Dette vil vi unngå. Du kan sette opp egendefinerte arbeidsflyter som leter etter ord i saker som blir opprettet via mail. Slik sender arbeidsflyten varsler eller e-post når søkeord blir funnet.

Med nye OG/ELLER funksjonaliteten vil dere kunne samle flere ord i samme arbeidsflyt. Vi må være obs enda en gang på at e-post er fritekst, og man må ha «tunga rett i munnen» hvis vi ønsker å gjøre dette på denne måten.

Det kan også være en idé å lære opp sine sluttbrukere å følge en standard for å rapportere via e-post eller be de enten ringe eller bruke selvbetjening hvis det er en kritisk hendelse på gang.

Skulle uhellet likevel være ute, så kan dere i Pureservice ha en meldingsmal klar for å hente inn mer informasjon når noen rapporterer en kritisk hendelse uten å gi nok info. Den kan for eksempel se slik ut:

3. Selvbetjening

Selvbetjening med Pureservice er et solid verktøy for inntak av saker. Med selvbetjening kan dere opprette FAQ artikler, vise lenker, sine siste saker og legge ut ut driftsmeldinger. Men det viktigste når det kommer til logging er skjemaer.

Selvbetjening: skjema

Et skjema er en kvalitetssikring av data før det sendes inn. Bruk av skjema er en ypperlig metode for å registrere henvendelser der hvor du trenger et standardisert sett med informasjon. Enkle scenarioer er for eksempel bestillinger av utstyr og software. Du fyller inn den påkrevde informasjonen og fyrer av skjemaet, så fikser resten seg selv. Det er den ideen du vil sette i deres sluttbrukere. «Hjelp oss hjelpe deg» er mantraet. Legg litt ansvar på brukerene for å gi god info, så løser ting seg raskere og smidigere.

Dette konseptet kan vi også legge på registrering av hendelser. Som nevnt over er det viktig å samle riktig informasjon så tidlig som mulig. Med et skjema og en arbeidsflyt kan dere innhente nok informasjon for å kunne gjøre klassifiseringsteget automatisk. Da kan dere hoppe direkte på respons og diagnose uten menneskelig innblanding. Dette kan spare dere for tid, bry og faren for menneskelig feil.

Vi kan være fristet til å lage lange skjema med 100 påkrevde felt som nevner all slags teknisk fagspråk. Da er det er viktig å huske at selvbetjeningen har en uhyre viktig rolle som er enkel å overse. Nemlig å oversette sluttbrukers språk og behov over til saksbehandlers språk og behov. Det gjelder å tenke på hvilke ord og uttrykk deres sluttbrukere er kjent med og hva de vil kunne forstå.

Deretter legges listen slik at dere vil finne frem enkelt og likevel gi nok informasjon så vi kan gå videre. Istedenfor å skrive setninger som «Register a demand for Incident resolution», tenk på setninger som «Meld en kritisk feil som hindrer deg eller andre å jobbe effektivt».

Om du ønsker at dine sluttbrukere skal ta seg bryet og gjøre sin del av samarbeidet, så må du gjøre det så enkelt og intuitivt som mulig. Fremfor å be om veldig presis og detaljert informasjon som “subnet” og “driver versjoner”. Ha litt større marginer som et kompromiss for at sluttbrukere bruker skjemaene. Tenk i baner som brukeropplevelse og jobb derfra. Hjelp de hjelpe deg.

Selvbetjening: arbeidsflyt

Med selvbetjening og skjema kan dere ha arbeidsflyter som klassifiserer, tildeler, og varsler basert på valg og info i skjema. Dette gjør at dere utfører klassifiseringsteget i samme slengen, og gjør det mye enklere å gå direkte på respons og diagnose-steget.

Selvbetjening: FAQ

I selvbetjeningsportalen kan dere publisere en FAQ som inneholder informasjon om hva en hendelse er, hva som skiller en hendelse fra en supportforespørsel, og hvordan en effektivt rapporterer en hendelse via skjema eller telefon.

Selvbetjening: driftsmeldinger

Driftsmeldinger gjør at dere kan informere på selvbetjeningen om at en kritisk hendelse er i gang, og det kan bidra til at dere får mindre saker på en hendelse som allerede er i respons- og diagnosesteget.

Hendelseshåndtering: klassifisering

Klassifisering utføres når hendelsen er rapportert, et ønske om forbedring er registrert og vi må kategorisere. Deretter prioriterer vi hendelsen.

Vi vil ofte ha forskjellige kår, responstider og løsningstider basert på blant annet kategori og prioritet. Gjelder hendelsen en tjeneste dere leverer til 100.000 sluttbrukere, eller er det en printer som har behov for en omstart?

Gjelder det en bruker, et helt kontor, eller et helt land? Basert på informasjon fra loggingsteget vil vi ofte tildele en kategori og en prioritet til hendelsen.

Saksklassifisering i Pureservice består av følgende:

• Kilde – hvor saken kom inn fra.
• Sakstype – hvilken praksis eller prosess som brukes for saken.
• Kategori – hva saken omhandler eller rører ved.
• Prioritet – hvilket omfang og deretter hastegrad saken vil ha
• Egendefinerte felter – hvis vi ønsker fritekst, dato eller tall i eget felt på en sak.

Pureservice har ingen dyr og komplisert “Incident-modul” som dere må betale konsulenter for å bygge.

Sakstyper

Det vi trenger for å gjøre klart til å starte klassifisering av hendelser er å stable på bena en sakstype med navn «Hendelse» eller «Incident». Denne vil være reservert for hendelseshåndtering og vil være det første steget i klassifiseringen.

Kategorier

Deretter vil vi benytte oss av kategoritreet for å tildele hva hendelsen rører ved. Dette kan for eksempel være Printer, Citrix, DHCP, API, Klient. Så lenge det forteller hva hendelsen er på, så er vi i boks.

Prioritering

Basert på informasjon tilgjengelig fra loggingsteget, vil vi tildele en prioritet til den nå kategoriserte hendelsen. Har din organisasjon en klar matrise og definisjon av hva som er og ikke er kritisk, vil denne delen av klassifiseringen bli enkel. Et eksempel kan være om hendelsen rører en kritisk tjeneste, hvor mer enn 10 sluttbrukere berøres. Hendelsen vil da få en prioritet betegnet som «høy» eller «kritisk». Hvis hendelsen for eksempel omhandler en printer som gjør at 1 eller 2 sluttbrukere må gå ned i gangen til en annen enhet, så vil vi tildele en lavere prioritet. Alt kommer an på deres egen organisasjon og hva som er viktig for dere.

Prioriteringsmatrise og hvordan det gjenspeiles i Pureservice

Eksempel på en prioriteringsmatrise:

Hvordan dette kan gjenspeiles i Pureservice:

Resultatet er at du kan enkelt, men effektivt klassifisere en sak ved opprettelse eller rett i saksbilde:

Dersom dere har tatt i bruk en saksmal eller kanskje har et selvbetjeningsskjema, kan dette steget automatiseres og dere kan gå videre.

Feilklassifisering

En sak som kommer inn kan bli feilklassifisert. Kanskje det viser seg i dette steget at saken ikke omhandler en hendelse, men en bestiling eller supportforespørsel. Da er det enkelt å forandre sakstype, sette en annen prioritet, og levere saken over til annet område som for eksempel tjenestebehandling.

Interessert i å lese mer i dybden om klassifisering? Her finner du klassifisering Masterclass.

Hendelseshåndtering: respons og diagnose

Til nå har vi identifisert hendelsen, samt registrert, kategorisert og prioritert. Vi vet altså at en hendelse er på gang, vi vet hva den handler om og hvilket omfang den har. Basert på dette har vi også tildelt en hastegrad. Vi har utført klassifiseringen og er nå godt på vei.

For å tildele hendelsen til en ressurs eller et team som kan starte en diagnose, vil vi bruke informasjonen vi har samlet.

I dette steget må dere fort lene dere på kompetanse og ekspertise i deres organisasjon, men det er ting i Pureservice som kan gjøre jobben enklere. Dere kan kjøre arbeidsflytregler som varsler team og ressurser i teamene når en sak med spesifikk klassifisering opprettes og blir eskalert til et team.

Hvis dere har et alarmhåndteringsverktøy som opsgenie eller pagerduty, så kan dere legge til rette for at varsling sendes til dette via email eller HTTP kall. Hvis dere har en vaktordning vil de da kunne hoppe rett på sak.

Diagnose

Dersom hendelsen er tildelt og en ressurs er på saken, ønsker vi å diagnostisere.
Hvis deres organisasjon kjører endringshåndtering, så er det enkelt å bla opp de siste endringene som er utført og se hva som kan være årsaken. Får dere en hendelse i fanget om et helt kontor som mister nettverk og det var utført en endring kvelden før om å bytte ut en brannmur eller en switch, så er det lett å putte 2 og 2 sammen, knytte en relasjon fra sak til endring og hoppe rett på løse hendelsen.

Dere kan søke i eldre saker etter lignende problemstillinger som vi har løst tidligere. Dere kan enkelt filtrere sakslisten på sakstype «hendelse» og se eldre saker med lik kategori og prioritet. Det gir dere mulighet til å se tidligere løsninger som kan gi en løsning på den aktuelle saken.

Hendelseshåndtering: løsing og lukking

Hendelsen er identifisert, registrert, kategorisert og prioritert. Dere vet at en hendelse er på gang, dere vet hva den handler om og hvilket omfang den har. Basert på dette har dere også tildelt en hastegrad.

Dokumentasjon

Ressurs har søkt igjennom tidligere endringer og saker, og funnet feilen som har skapt hendelsen. For å løse og lukke hendelsen, så gjenstår det kun å dokumentere det arbeidet dere har utført.

I dette steget har dere en sak som dokumenterer den aktuelle hendelsen og arbeidet dere har utført. Det er også mulig at dere har opprettet en relasjon til en endring eller en annen sak. Det kreves en løsning i saken før den kan lukkes. Da er dere klare til å løse hendelsen og lukke saken.

På denne måten tvinges vi til å dokumentere løsningen slik at neste person som opplever en lik hendelse kan vurdere om relaterte saker, endringer og løsninger bidrar til å finne svar på aktuell hendelse.

Rapportering

Saken vil bli en del av det voksende datagrunnlaget når dere lukker saken. Ved rett klassifisering vil saken være tilgjengelig for rapportering etter den lukkes.

Den registrerte saken er en fortelling av hendelsen. Dere har registrert dato og tid, hvem som har gjort hva, løsningen, og eventuelle relasjoner til tidligere hendelser og endringer. Det gjør saken til en naturlig kilde for data til en hendelsesrapport.

Sakslister

Sakslister i Pureservice er ikke bare bare arbeidslister, men også suveren måte å skape rapporter på hendelser registrert.

Med sakslister kan dere lage lister som for eksempel:

• Alle åpne hendelser med «høy» eller «lav» prioritet.
• Åpne hendelser på kategori: Nettverk – Kontor.
• Lukkede hendelser med høy prioritet de siste 14 dagene med brutt SLA.

I tillegg hvis vi bruker et egendefinert felt så er det mulig å briljere med avanserte lister som:

• Alle hendelser meldt på overvåkning som er lukket de siste 30 dager med kategori: “Nettverk: Kontorfiber” der SLA ikke er brutt, men advarsler er sendt og lokasjoner påvirker (egendefinert felt) er “Stavanger” samt at totalt timer ført for å løse er høyere enn 4 timer.

Med sakslister er rapportjobben for deres Incident Manager gjort enkel. Det er ikke behov for tunge rapportmoduler eller påkobling av analyseverktøy for å finne dataen, den ligger klart i grensesnittet.

Ønsker dere å ta ut dataen er CSV eksport lett tilgjengelig.

Lyst til å vite mer?

Dette er bare noen måter Pureservice kan støtte under hendelseshåndtering i deres organisasjon. Det finnes andre ting som blant annet SLA og arbeidsflyter som legger inn rutiner som internt notat, bruk av FAQ, automatisk eskalering ved bruk av kategori og prioritet – pluss mye mer.

Lyst til å vite mer? Kontakt din Customer Success Manager for en hyggelig prat om hendelseshåndtering.

– Marius Eldor Børseth.
Customer Success Manager, Pureservice.