Het incidentmanagementproces uitvoeren als een IT-Ops pro

Identificeer een incident en leg het vast

Een incident kan overal vandaan komen. Een werknemer kan je vragen om het te melden, of het valt je letterlijk in de schoot uit het plafond, in het geval van een slecht bevestigde netwerkhub en zwak dak. (Niet dat ik uit ervaring spreek ... *kuch kuch*)

Ongeacht de bron zijn de eerste twee stappen eenvoudig: iemand identificeert een incident en iemand legt het vast.

Als je het incident ontvangt dat al via je servicedesk vastgelegd is, zijn deze eerste twee stappen al voor je gedaan. Als je gebeld wordt of het incident wordt via e-mail, sms of postduif gemeld, is het de taak van het servicedeskteam om deze op de juiste manier in je servicedesk vast te leggen.

Deze incidentlogs (d.w.z. tickets) bevatten doorgaans:

• De naam van degene die het incident rapporteert
• De datum en tijd waarop het incident wordt gerapporteerd
• Een beschrijving van het incident (wat er offline is of niet goed werkt)
• Een uniek identificatienummer dat aan het incident wordt toegewezen om het te volgen

Categoriseer je incident

Deze volgende twee stappen, categoriseren en prioriteiten stellen, zijn cruciaal maar worden vaak over het hoofd gezien. Ze onderscheiden ook de 'verstandigere' servicedesks waarmee ik heb gewerkt van de ... nou ja, niet zo verstandige.

Wijs, als eerst, een logische, intuïtieve categorie toe (en waar nodig een subcategorie) aan elk incident. Als je dat niet doet, heb je later niet de mogelijkheid om je gegevens te analyseren en te zoeken naar trends en patronen, wat een cruciaal onderdeel is van effectief probleembeheer en het voorkomen van toekomstige incidenten.

Dus zorg er gewoon voor dat je het niet vergeet. En kies een ITSM-servicedeskoplossing waarmee je eenvoudig incidentcategorieën kunt aanpassen.

Geef prioriteit aan je incident

Ten tweede moet elk incident prioriteit krijgen.

Om prioriteit te geven aan een incident, moet je eerst de impact ervan op het bedrijf beoordelen. Denk eraan dat het aantal mensen dat beïnvloed wordt en de mogelijke implicaties op financieel, beveiligings- en nalevingsgebied om te bepalen hoeveel impact het incident veroorzaakt en hoe dringend het is dat het bedrijf dit incident oplost.

De aanbevolen werkwijze is het definiëren van de ernst en prioriteitsniveaus voordat een incident plaatsvindt. Zo kunnen incidentmanagers snel en eenvoudig de prioriteit bepalen.

En als je twijfelt over de prioriteit? Kies voor het hogere prioriteitsniveau. Het is beter om te voorzichtig te zijn dan dat je iets ernstigs over het hoofd ziet.

Als je de prioriteiten hebt ingesteld, kun je alle open incidenten behandelen op volgorde van prioriteit. De meeste organisaties hebben duidelijke serviceovereenkomsten ingesteld rondom elk prioriteitsniveau, zodat klanten weten hoe snel ze een reactie en oplossing kunnen verwachten. Ik raad die werkwijze ten zeerste aan.

Reageren

Incidentrespons is een vrij brede term, dus laten we het een beetje verder opsplitsen in de meest waarschijnlijke stappen die je uitvoert zodra je een incident hebt geïdentificeerd, gecategoriseerd en geprioriteerd.

Eerste diagnose
Beschouw dit als de triage die een ziekenhuis uitvoert bij nieuwe patiënten. De werknemer bij de servicedesk formuleert een snelle hypothese bij wat er waarschijnlijk mis is, zodat ze een oplossing kunnen bedenken of de juiste procedures volgen en de juiste bronnen kunnen samenstellen om het op te lossen.

Kennisdatabases en diagnostische handleidingen zijn nuttige bronnen bij deze stap.

Als de eerste servicedeskagent die reageert het incident kan oplossen op basis van hun oorspronkelijke diagnose, beschikbare kennis en tools, wordt het incident opgelost. Anders moet het geëscaleerd worden.

Incidentescalatie
Escalatie klinkt als een negatief woord, maar dat is het niet.

Je supportteam bij de frontoffice moet in staat zijn om veel van de meest voorkomende incidenten op te lossen zonder te escaleren. Maar van wat ze niet kunnen oplossen, moeten ze de juiste informatie verzamelen en vastleggen zodat tweede- en derdelijnssupport (de meer technische personen) snel weer bij kunnen zijn en het incident snel kunnen oplossen.

Onderzoek en diagnose
ITIL noemt dit zijn ene eigen stap. In werkelijkheid gebeurt dit gedurende de hele cyclus van het incident.

De eerstelijnssupportagent onderzoekt tot op zekere hoogte al iets als hij of zij informatie verzamelt. Mogelijk kan diegene zelfs de juiste diagnose stellen en het incident oplossen zonder dat er escalatie nodig is.

In dat geval sla je de volgende paar stappen meteen over: oplossing, herstel en sluiting van het incident.

Anders vinden het onderzoek en de diagnose plaats bij elke stap naarmate je escaleert naar supportniveau 2 of 3 of externe bronnen raadpleegt of andere collega's erbij haalt die kunnen helpen bij het oplossen.

Oplossing en herstel
Uiteindelijk, en bij voorkeur binnen je gevestigde service level agreements (SLA's) kom je tot een diagnose en kun je de nodige stappen uitvoeren om het incident op te lossen. Herstel houdt simpelweg in hoe lang het kan duren voordat de bewerkingen volledig zijn hersteld, aangezien sommige oplossingen (zoals bugpatches, enz.) mogelijk moeten worden getest en geïmplementeerd, zelfs nadat de juiste oplossing is vastgesteld.

Afsluiten van incidenten
Het incident wordt dan teruggestuurd naar de servicedesk (als het was geëscaleerd) om te worden gesloten. Om de kwaliteit te waarborgen en een soepel proces te garanderen, mogen alleen medewerkers van de servicedesk incidenten sluiten en moet de eigenaar van het incident contact opnemen met de persoon die het incident heeft gemeld om te bevestigen dat de oplossing bevredigend is en dat het incident daadwerkelijk kan worden gesloten.

Conclusie: sla geen stappen over

Het proces lijkt misschien onnodig formeel, vooral als je maar een paar analisten van de servicedesk hebt. Maar ongeacht de structuur van je team is de levenscyclus van het incident nog steeds hetzelfde.

Stel dat je maar één servicedesk-analist hebt, dus er is geen support op niveau drie. Maar incidenten die de kennis van je servicedesk-analist te boven gaan, moeten ergens heen, of het nou naar je hoofdengineer of een externe consultant is, of zelfs naar jou, toch?

Voilà! Je hebt inderdaad support van niveau twee of niveau drie, alleen jij en je engineer zijn dat.

Mijn punt? Ook al lijkt het erop dat ITIL helemaal over semantiek gaat, probeer er niet in verstrikt te raken. Zoek naar eenvoudige manieren om je organisatiehiërarchie en procesworkflows aan te passen zodat ze passen bij een eenvoudig framework voor IT-servicebeheer, zoals hierboven geschetst.

Door dat te doen, bied je een veel betere service en krijg je veel meer waarde voor het bedrijf. (Bovendien is het veel minder snel chaos op de afdeling - bonuspunten!)

Tot slot nog een paar herinneringen:

• Leg elk incident vast. Geef het een uniek nummer. En leg belangrijke gegevens (zoals datum, tijd en beschrijving) vast in een centraal helpdesksysteem.
• Als je een groot intern of extern publiek hebt om updates over incident aan te geven, overweeg dan een statuspagina voor incidentcommunicatie.
• Wijs een categorie toe aan elk incident (en indien nodig een subcategorie).
• Geef elk incident een prioriteitsniveau en elk prioriteitsniveau een SLA.
• Zorg voor duidelijk gedefinieerde rollen voor respondenten, zoals incidentcommandant, grootschalige incidentmanager, communicatie lead.
• Geef je eerstelijnssupportteam waar mogelijk artikelen uit de kennisdatabase en diagnostische scripts voor incidenten, zodat ze incidenten snel kunnen oplossen.
• Zorg ervoor dat de servicedesk altijd de controle behoudt over de voortgang, de route en de status van incidenten.
• En leg niet alleen gegevens over incident vast. Analyseer ze ook! Zoek naar trends, patronen en mogelijke onderliggende problemen die het aantal incident kunnen verminderen en het risico kunnen beperken.

Over de auteur