ServiceNow Australia-release: Action Fabric en MCP-server uitgelegd
Ontdek hoe de ServiceNow MCP-server AI-agenten verbindt met beheerde ITSM-workflows, Action Fabric en veilige bedrijfsautomatisering, plus stappen voor 2026.
Read more →ITIL 4-praktijk · Incident management
Incident management: het ITIL 4-proces dat de dienstverlening snel herstelt
Incident management herstelt de normale dienstverlening zo snel mogelijk wanneer er iets stukgaat, en houdt gebruikers ondertussen op de hoogte. Deze pagina legt het ITIL 4-proces voor incident management uit, de prioriteitsmatrix, SLA's en KPI's, en hoe SMC Consulting het inricht in HaloITSM of in de tool die u al gebruikt.
180ITSM-implementaties
40+ITSM-migraties
20jaar ervaring in IT-servicemanagement
Zij vertrouwen ons hun ITSM-projecten toe
Wat is incident management in ITSM?
Incident management is de ITIL 4-praktijk die de negatieve impact van incidenten beperkt door de normale dienstverlening zo snel mogelijk te herstellen. Een incident is een ongeplande onderbreking van een dienst, of een daling van de kwaliteit ervan: de VPN weigert verbindingen, een applicatie is traag, de printers van een verdieping werken niet meer. Het doel is gebruikers weer aan het werk krijgen, nog niet uitzoeken waarom het gebeurde.
Dat laatste punt onderscheidt incidenten van de verwante praktijken:
| Wat het is | Doel | |
|---|---|---|
| Incident | Een ongeplande onderbreking of verslechtering van een dienst | De dienst snel herstellen |
| Probleem | De onderliggende oorzaak van een of meer incidenten | De grondoorzaak vinden en wegnemen |
| Serviceaanvraag | Een geplande vraag: toegang, materiaal, informatie | Afhandelen via de catalogus |
| Major incident | Een incident met grote bedrijfsimpact | De dienst herstellen met een eigen procedure |
Incidenten en aanvragen in Ă©Ă©n wachtrij vertragen beide; zie service request management voor de aanvragen. Incident management is een van de belangrijkste ITSM-processen.
Nagelezen door de ITIL v4-gecertificeerde consultants van SMC Consulting. Bron: de ITIL 4-praktijk Incident Management, ITIL 4 (PeopleCert).
Het incident management proces, stap voor stap
Zes stappen, van het eerste signaal tot het afgesloten dossier. Elke stap wordt in de tool ingericht volgens uw operationele model, niet op de standaardinstellingen gelaten.
Vraagt de oplossing een wijziging in productie, dan verlaat ze incident management en volgt ze change management.
Detecteren en registreren
Het incident komt binnen via het portaal, e-mail, Teams, een oproep of een monitoringalert, en wordt geregistreerd met bron, tijdstip en standaardvelden.
Categoriseren en prioriteren
De categorie volgt uw servicecatalogus; de prioriteit komt uit de matrix impact Ă— urgentie en bepaalt de SLA-doelen.
Diagnosticeren en toewijzen
De eerste lijn raadpleegt de kennisbank en bekende fouten, lost op wat kan en wijst de rest toe aan de juiste oplossersgroep.
Onderzoeken en escaleren
Specialisten onderzoeken met de CMDB en de incidenthistoriek; escalatie gebeurt voordat het SLA-doel wordt overschreden.
Oplossen en herstellen
De oplossing of workaround wordt toegepast, de gebruiker bevestigt dat de dienst terug is, en de oplossingscode en notities worden vastgelegd.
Afsluiten en evalueren
Het dossier wordt afgesloten met correcte data; terugkerende en major incidents gaan naar problem management en voeden de volgende review.
Prioriteitsmatrix, SLA's en escalatie
Prioriteit is geen gevoel. Ze volgt uit twee vragen: hoeveel mensen of welk deel van de organisatie zijn getroffen (impact), en hoe snel groeit de schade (urgentie). Door ze te kruisen krijgt u een prioriteit die elke agent op dezelfde manier toepast.
| Impact \ Urgentie | Hoog | Gemiddeld | Laag |
|---|---|---|---|
| Hoog (een dienst of site ligt plat) | P1 Kritiek | P2 Hoog | P3 Gemiddeld |
| Gemiddeld (een team of afdeling) | P2 Hoog | P3 Gemiddeld | P4 Laag |
| Laag (Ă©Ă©n gebruiker, er is een workaround) | P3 Gemiddeld | P4 Laag | P5 Planning |
Elke prioriteit krijgt vervolgens een doel voor reactie en oplossing. De waarden hangen af van uw diensten, openingsuren en contracten, dus leggen wij ze samen met u vast in plaats van een sjabloon over te nemen. Twee regels doen ze werken: de SLA-klok start bij de registratie van het incident, en escalatie gebeurt vóór het doel wordt overschreden (bijvoorbeeld bij 75% van de verstreken tijd), wanneer er nog tijd is om in te grijpen. Functionele escalatie brengt het ticket naar een meer gespecialiseerd team; hiërarchische escalatie verwittigt een manager wanneer een beslissing of extra middelen nodig zijn.
Major incidents en de link met problem en change
Een aparte procedure voor major incidents
Duidelijke criteria om een major incident af te kondigen, een aangewezen manager, een eigen team en een kortere beslissingslijn. Vroeg afkondigen is beter dan laat escaleren.
Communicatie op een vast ritme
Gebruikers en management krijgen updates op afgesproken tijdstippen, via het portaal, Teams of e-mail, zodat de servicedesk niet overspoeld wordt met "al nieuws?"-oproepen.
Overdracht naar problem management
Zodra de dienst hersteld is, worden terugkerende of major incidents probleemrecords: grondoorzaak, bekende fout, workaround, definitieve oplossing.
Oplossingen via change
De definitieve oplossing is een wijziging: beoordeeld, goedgekeurd en ingepland, zodat de remedie niet het volgende incident veroorzaakt.
Incident management in HaloITSM: zo richten wij het in
Wij werken in vier fasen: het operationele model ontwerpen, de tool configureren, kennis, AI en automatisering toevoegen, en dan opleiden en overdragen. HaloITSM is onze keuze voor de meeste middelgrote organisaties, maar het proces werkt op elk van de 10 ITSM-platformen waarop wij werken: wij richten hetzelfde model in in de tool die u al hebt.
Registratie via elk kanaal
E-mail, selfserviceportaal, Microsoft Teams, API en monitoringalerts, met standaardformulieren en verplichte velden zodat de eerste registratie bruikbaar is.
Triage- en routeringsregels
Categorieën afgestemd op uw diensten, en routering op categorie, getroffen dienst en gebruiker, zodat het ticket meteen bij de juiste oplossersgroep belandt.
SLA-timers en escalatie
Reactie- en oplosdoelen per prioriteit, waarschuwingen vóór de overschrijding en escalatiepaden die met elk team zijn afgesproken.
Kennis op het juiste moment
Relevante artikels voorgesteld aan agents tijdens de analyse en aan gebruikers bij de registratie, plus een herinnering om de kennis bij te werken bij afsluiting.
Impact via de CMDB
Incidenten gekoppeld aan configuratie-items en diensten, zodat agents zien wat er nog getroffen is en problem management de patronen ziet.
Teams en integraties
Tickets aanmaken, opvolgen en goedkeuren in Teams, en koppelingen met Jira, Azure DevOps en PagerDuty wanneer ontwikkel- of wachtdienstteams betrokken zijn.
Incidentoproepen beantwoorden met een AI-helpdesk
Veel incidenten komen nog telefonisch binnen, vaak buiten de kantooruren. AurionAI, een AI-helpdesk voor IT-support van onze partner AurionAI SRL, beantwoordt 24/7 oproepen, chats en e-mails, verifieert de beller, en lost de vraag op of maakt het incidentticket aan in uw ITSM met categorie en prioriteit. Agents starten van een volledig ticket in plaats van een voicemail.
Groeiende backlog of elke maand SLA-overschrijdingen?
In een gratis audit van 30 minuten overloopt een senior consultant met u uw incidentproces, prioriteiten en SLA's, en u krijgt uw drie prioriteiten.
Wat een goed incidentproces u oplevert
- EĂ©n prioriteitsmodel dat elke agent op dezelfde manier toepast
- SLA-overschrijdingen voorzien in plaats van achteraf verklaard
- Minder tickets die heen en weer gaan tussen oplossersgroepen
- Gebruikers op de hoogte zonder dat ze de servicedesk moeten bellen
- Terugkerende incidenten naar problem management in plaats van telkens opnieuw opgelost
- Rapporten die uw management leest, gebouwd op correcte afsluitdata
Verwante praktijken en tools
Servicedesk optimaliseren
Wanneer de backlog blijft groeien, zit de oplossing meestal in triage, SLA-ontwerp en kennis, niet in een nieuwe tool.
Een aanvraag is geen incident
Aanvragen voor toegang, materiaal en informatie horen in de servicecatalogus, met eigen formulieren en goedkeuringen.
Voor wie
Servicedeskmanagers
Die elke dag de wachtrij, de SLA's en de escalaties dragen en een proces nodig hebben dat het hele team toepast.
IT-managers en CIO's
Die minder storingen, sneller herstel en cijfers voor de business willen.
Incident- en probleemeigenaars
Die een levenscyclus, prioriteiten en overdrachten willen die mensen echt volgen.
KPI's voor incident management om op te volgen
| KPI | Wat hij u vertelt |
|---|---|
| Gemiddelde oplostijd (MTTR) | De gemiddelde tijd tussen registratie en oplossing, per prioriteit. |
| Oplossing bij eerste contact (FCR) | Het aandeel incidenten dat bij het eerste contact wordt opgelost, zonder escalatie. |
| SLA-naleving | Het aandeel incidenten dat binnen het doel wordt opgelost, en hoe dicht de andere kwamen. |
| Heropeningsgraad | Incidenten die na oplossing heropend worden: een direct signaal van de kwaliteit van de oplossing. |
| Leeftijd van de backlog | Hoe lang open incidenten al wachten; de oudste tonen waar het proces vastloopt. |
Definities, formules en doelen vindt u in onze gids over ITSM-KPI's.
Incident management: veelgestelde vragen
Wat is het verschil tussen een incident en een probleem?
Een incident is de onderbreking zelf: een dienst ligt plat of werkt slecht en gebruikers hebben hem nodig. Een probleem is de oorzaak achter een of meer incidenten. Incident management herstelt de dienst zo snel mogelijk; problem management zoekt en verwijdert de oorzaak zodat het incident niet terugkomt.
Wat zijn de stappen van het ITIL incident management proces?
Detecteren en registreren, categoriseren en prioriteren, diagnosticeren en toewijzen, onderzoeken en escaleren, oplossen en herstellen, afsluiten en evalueren. ITIL 4 legt geen vaste volgorde op, maar dit zijn de zes stappen die de meeste servicedesks volgen, en elke stap moet zichtbaar zijn in de tool.
Hoe prioriteert u incidenten?
Met een matrix impact Ă— urgentie. Impact meet welk deel van de organisatie getroffen is, urgentie hoe snel de schade groeit; samen geven ze een prioriteit van P1 tot P5, met elk eigen SLA-doelen. De matrix moet eenvoudig genoeg zijn zodat elke agent tot hetzelfde antwoord komt.
Welke KPI's meten incident management?
Gemiddelde oplostijd, oplossing bij eerste contact, SLA-naleving, heropeningsgraad en leeftijd van de backlog, aangevuld met gebruikerstevredenheid. Volg een korte lijst maandelijks op en handel ernaar. Onze gids over ITSM-KPI's geeft de definities.
Wat is een major incident?
Een incident met een bedrijfsimpact die groot genoeg is voor een eigen procedure: een aangewezen major incident manager, een eigen team, regelmatige communicatie naar gebruikers en management, en een evaluatie achteraf. De criteria om er een af te kondigen legt u vooraf vast, niet tijdens de storing.
Hebben wij HaloITSM nodig om incident management te verbeteren?
Nee. Het proces, de prioriteitsmatrix en de SLA's komen eerst, en ze werken in elke ITSM-tool. HaloITSM is onze keuze wanneer een toolwissel op tafel ligt; anders richten wij uw huidige platform in. Een gratis audit van 30 minuten vertelt u wat van toepassing is.
Herstel de dienstverlening sneller, met een proces dat uw team toepast
Boek uw gratis ITSM-audit van 30 minuten. Een senior consultant overloopt uw incidentproces, prioriteiten en SLA's en geeft u uw drie prioriteiten.
Recente artikelen
De HaloITSM CMDB automatisch vullen met Lansweeper discovery-data
Ontdek hoe een HaloITSM Lansweeper-integratie discovery-data koppelt aan HaloITSM voor zuiverdere CMDB-records, snellere triage en betere change-beslissingen.
Read more →
ServiceNow migratie cutover-plan: data, integraties en risicobeheer
Een praktisch ServiceNow migratie cutover-plan helpt risico's te beperken, de servicecontinuĂŻteit te beschermen en een zelfverzekerde ITSM-modernisering te ondersteunen.
Read more →