Het Incident Management proces sluitend maken

Incident Management? Je auto staat in brand. Het brandt echt! De stank is verschrikkelijk. Laten we er iets aan gaan doen!

Eerst een paar basisbegrippen toelichten voor we beginnen met blussen.

• Incidenten zijn ongeplande gebeurtenissen van welke aard dan ook die de kwaliteit van de dienstverlening verstoren of verminderen (of dat dreigen te gaan doen). Een applicatie die uitvalt, is een incident. Het trage SQL query die de productie dwarsboomt. Of erger, vormt een groot risico voor een volledige verstoring.
• Een probleem is de nog niet bekende oorzaak achter een of meer incidenten. In verschillende incidenten waarbij de printer wordt uitgeschakeld en het netwerk vastloopt, kan een verkeerd geconfigureerde router het onderliggende probleem van beide zijn.

Incident Management = Omgaan met incidenten

ITIL® geeft een goed overzicht van een goed Incident Management, maar de meeste andere populaire frameworks beschrijven grofweg vergelijkbare concepten echter met gebruik van een ander jargon. Als ITIL® nieuw voor je is, hoeft je je geen zorgen te maken. Het is een flexibele reeks richtlijnen die je kunt volgen, gebaseerd op de ervaringen van anderen. COBIT, TOGAF of elk ander IT-framework kan je op dezelfde manier gebruiken.

De sleutel tot goed Incident Management is je houden aan het proces

Een van de grootste fouten van drukke, groeiende IT-organisaties is om het wiel opnieuw uit te vinden en nieuwe processen te creëren (zonder te putten uit Best Practices), of zelf tools te bouwen voor het registeren van tickets.

Identificeer een incident en log het

Een incident kan overal vandaan komen. Een medewerker kan je bellen om het te melden. In het geval van een slecht geplaatste netwerkhub en een lekkend dak kan het letterlijk door het plafond vallen en in je schoot landen. De eerste twee stappen zijn eenvoudig: iemand identificeert een incident en daarna logt iemand het. Als het incident via je selfservice-helpdesk is geregistreerd, zijn deze eerste twee stappen al voor je gedaan. Als je een telefoontje krijgt of als men het incident via e-mail of sms meldt, is het de taak van de servicedesk om het correct in het helpdesksysteem te registreren. Deze incident logs (tickets) omvatten meestal:

• De naam van de persoon die het incident heeft gemeld.
• De datum en tijd waarop het incident is gemeld.
• Een beschrijving van het incident (wat is er niet of werkt niet goed).
• Een uniek identificatienummer dat aan het incident is toegewezen, voor tracking.

Categoriseren van incidenten

De volgende twee stappen, categoriseren en prioriteiten stellen, zijn kritisch maar ook vaak over het hoofd gezien.

Ten eerste moet je een logische, intuïtieve categorie toewijzen (en subcategorie, indien nodig) aan elk incident. Als je dat niet doet, lukt het niet om later je data te analyseren. Het zoeken naar trends en patronen is een cruciaal onderdeel van effectief Problem Management voor het voorkomen van toekomstige incidenten.

Prioriteren van incidenten

Ten tweede moet ieder incident een prioriteit krijgen. Als je voorrang wilt geven aan een incident, moet je eerst de impact ervan op de organisatie beoordelen. Zowel het aantal mensen dat last heeft, als de mogelijke gevolgen voor de financiën, de beveiliging en de compliance moeten worden bepaald. Hoeveel pijn doet het incident en hoe urgent is een oplossing voor de organisatie?

Behandel alle openstaande incidenten in volgorde van prioriteit. De meeste organisaties stellen duidelijke SLA’s op rond elk prioriteitsniveau, zodat klanten weten hoe snel ze een reactie en oplossing kunnen verwachten.

Reageren op incidenten

Incidentrespons is een brede term en na het identificeren, categoriseren en prioriteren zijn dit de meest waarschijnlijke stappen die je zult uitvoeren:

Eerste diagnose

Zie dit als de triage die een ziekenhuis op nieuwe patiënten uitvoert. De servicedeskmedewerker formuleert een snelle hypothese rond wat er waarschijnlijk fout is, zodat ze het kunnen oplossen of de juiste procedures kunnen volgen en de juiste middelen kunnen verzamelen om het probleem op te lossen. Kennis en diagnosehandleidingen zijn in deze stap nuttige hulpmiddelen. Als de eerste servicedeskmedewerker in staat is om het incident op te lossen op basis van zijn eigen diagnose, beschikbare kennis en hulpmiddelen, is het incident opgelost. Anders moeten we escaleren.

Incident Management – escalatie

Het servicedesk-team moet een groot aantal van de meest voorkomende incidenten kunnen oplossen zonder te escaleren. Maar als dat niet kan moeten ze de juiste informatie verzamelen en loggen om het tweede en derde niveau van (meer technische) ondersteuning snel te laten werken, zodat die het incident snel kunnen oplossen.

Incidentonderzoek en -diagnose

ITIL® noemt dit als aparte stap. Feitelijk gebeurt dit tijdens de gehele levenscyclus van het incident. Je eerste lijnsondersteuner onderzoekt in zekere mate al als hij informatie verzamelt en kan het incident zelfs met succes diagnosticeren. Hij kan soms zelfs het probleem oplossen zonder dat een escalatie nodig is. In dat geval hebt je een paar stappen overgeslagen: Incident oplossing, herstel en incidentafsluiting.

Incidentoplossing en -herstel

Uiteindelijk kom je, idealiter binnen je bestaande Service Level Agreements (SLA’s), tot een diagnose en voert je de nodige stappen om het incident op te lossen. Herstel impliceert een hoeveelheid tijd die nodig is om de fouten volledig te herstellen. Mogelijk moeten we nog testen en implementeren, zelfs nadat de juiste oplossing is aangebracht.

Incident Management: Sluiting van een incident

De incidentstatus geven we vervolgens door aan de servicedesk om af te sluiten. Om de kwaliteit te behouden en een feilloos proces te garanderen, mogen alleen medewerkers van de servicedesk incidenten sluiten. De eigenaar van het incident en de persoon die het incident heeft gemeld moeten de oplossing bevestigen zodat we het incident kunnen afsluiten.

Discussieer mee op LinkedIn.