ITSM-leveranciersevaluatiecriteria (Gids 2026)
Een leveranciersonafhankelijk kader voor het evalueren van ITSM-platforms. Behandelt functionele fit, TCO, NIS2-compliance, integraties en een gewogen scorekaart om de juiste tool te kiezen.
Read more →Change Management ITSM
ITSM Change Management: stabiliteit, snelheid en minder risico
De meeste IT-incidenten zijn niet willekeurig. Een aanzienlijk deel wordt veroorzaakt door slecht gecontroleerde wijzigingen — een configuratie-update die zonder goedkeuring is doorgevoerd, een patch die is geïmplementeerd zonder impactanalyse of een release zonder rollback-plan. Change management is er om precies dit te voorkomen.
SMC Consulting ontwerpt en implementeert ITIL v4 change management-processen die uw organisatie de governance bieden om snel te schakelen zonder de stabiliteit in gevaar te brengen.
Wat is Change Management in ITSM?
Change Management, in ITIL v4 nu Change Enablement genoemd, is het proces dat de levenscyclus beheert van alle wijzigingen in de IT-infrastructuur, diensten en applicaties. Het doel is om gunstige wijzigingen mogelijk te maken en tegelijkertijd de verstoring van operationele diensten tot een minimum te beperken.
Een wijziging is elke toevoeging, aanpassing of verwijdering van zaken die invloed kunnen hebben op IT-diensten. Dit omvat infrastructuurupdates, applicatiereleases, configuratiewijzigingen, beveiligingspatches en netwerkaanpassingen.
Drie soorten wijzigingen die u verschillend moet beheren:
- Standaardwijzigingen zijn vooraf goedgekeurde wijzigingen met een laag risico en een gedocumenteerde procedure
- Normale wijzigingen vereisen beoordeling, autorisatie en planning voorafgaand aan de implementatie
- Spoedwijzigingen moeten onmiddellijk worden geïmplementeerd om een kritiek incident of een beveiligingsrisico op te lossen
Onduidelijke grenzen tussen deze drie typen zijn de meest voorkomende oorzaak van falend beheer.
De levenscyclus van Change Management: 7 fasen
Change Request (RFC)
Elke wijziging begint met een Request for Change — het vastleggen van wat er moet veranderen, waarom, wat de impact is en wat het rollback-plan is. Geen RFC, geen wijziging.
Beoordeling en classificatie
De wijziging wordt beoordeeld op risico, impact en urgentie. Classificatie als standaard, normaal of spoed bepaalt het goedkeuringstraject, de betrokkenheid van de CAB en de planningsvereisten.
Wijzigingsplanning
Normale wijzigingen en noodwijzigingen vereisen een gedetailleerd implementatieplan: wie wat doet, wanneer, welke systemen worden beïnvloed, de testaanpak en rollback-triggers. De CMDB is hierbij essentieel — inzicht in welke configuratie-items worden beïnvloed en hun afhankelijkheden bepaalt rechtstreeks de nauwkeurigheid van de impactanalyse.
Beoordeling door de Change Advisory
Board (CAB)
De CAB beoordeelt normale wijzigingen voorafgaand aan de autorisatie. Een goed functionerende CAB is geen bureaucratische bottleneck, maar een gestructureerde risicobeoordeling met de juiste personen aan tafel. Het CAB-lidmaatschap dient IT-operations, service-eigenaren en, bij wijzigingen met een grote impact, vertegenwoordigers van de business te omvatten.
Een veelvoorkomend knelpunt: CAB-vergaderingen die wekelijks worden gehouden, ongeacht de urgentie. Een volwassen proces omvat een Emergency CAB-mechanisme voor tijdgevoelige wijzigingen.
Autorisatie
De wijziging wordt formeel goedgekeurd of afgewezen door de bevoegde autoriteit op basis van het risiconiveau. Het autorisatieniveau moet overeenkomen met het risiconiveau. Standaardwijzigingen zijn vooraf geautoriseerd. Normale wijzigingen vereisen goedkeuring van de CAB. Voor noodwijzigingen wordt een versneld autorisatietraject gevolgd.
Implementatie
De wijziging wordt geïmplementeerd volgens het goedgekeurde plan, binnen een vastgesteld onderhoudsvenster waar van toepassing. Incidentbeheer blijft in stand-by. Als de wijziging een verstoring veroorzaakt, wordt de rollbackprocedure onmiddellijk geactiveerd zonder discussie.
Post-Implementation
Review (PIR)
Elke significante wijziging wordt na de implementatie geëvalueerd: is de doelstelling behaald, was er sprake van onbedoelde impact en wat kan er worden verbeterd? PIR’s vloeien direct voort in de kennisbank en continue serviceverbetering.
Change Management KPI's
| KPI | KPI Wat het meet | Doelstelling |
|---|---|---|
| Percentage succesvolle wijzigingen | % wijzigingen doorgevoerd zonder incidenten | >95% |
| Percentage wijzigingsgerelateerde incidenten | % van het totaal aantal wijzigingen geclassificeerd als spoed | <10% |
| M365 / Teams-integratie | % van het totaal aantal wijzigingen geclassificeerd als spoed | <5% |
| CAB-cyclustijd | Gemiddelde tijd van RFC-indiening tot autorisatie | Gedefinieerd per SLA |
| Percentage ongeautoriseerde wijzigingen | % wijzigingen gedetecteerd na implementatie zonder RFC | 0% |
De meest voorkomende fouten bij verandermanagement
Geen RFC-discipline. Wijzigingen worden informeel doorgevoerd, zonder registratie. Wanneer er een incident optreedt, is er geen wijzigingslogboek om te raadplegen.
Het is ook te onderscheiden van service request management. Een aanvraag voor toegang tot nieuwe software of een hardwarevervanging is geen incident. Het mengen van deze twee in dezelfde wachtrij verslechtert de afhandelingskwaliteit van beide.
Welke integraties verkorten de tijd om de dienstverlening te herstellen?
Integraties verminderen het wisselen van context, elimineren handmatige duplicatie en houden incidentwerkzaamheden gesynchroniseerd tussen teams.
Microsoft Teams
Realtime meldingen, goedkeuringen, chatbot-interacties en portaal-integratie binnen Teams kunnen de adoptie van self-service en de reactiesnelheid van agents verbeteren.
Jira software
Tweerichtingssynchronisatie tussen HaloITSM-incidenten en Jira-issues houdt de servicedesk en engineering op één lijn wanneer incidenten code-oplossingen of gestructureerd ontwikkelwerk vereisen.
Azure DevOps
Tweerichtingssynchronisatie met Azure DevOps-werkitems ondersteunt gestructureerde samenwerking met engineeringteams en consistente statusrapportage.
Wat incident-
management niet is
Incidentmanagement gaat niet over het vinden van de bronoorzaken — dat is problem management. Het enige doel is herstel van de dienstverlening. Bedrijven die de tijd voor het oplossen besteden aan het diagnosticeren van het ‘waarom’ in plaats van het repareren van het ‘wat’, halen consequent hun SLA’s niet.
Het is ook te onderscheiden van service request management. Een aanvraag voor toegang tot nieuwe software of een hardwarevervanging is geen incident. Het mengen van deze twee in dezelfde wachtrij verslechtert de afhandelingskwaliteit van beide.
Veelgestelde vragen over HaloITSM incidentmanagement
Wat is het verschil tussen incidentmanagement en probleemmanagement in ITIL 4?
Incidentmanagement herstelt de dienstverlening snel na een onderbreking. Probleemmanagement identificeert de bronoorzaak en voorkomt herhaling. Incidenten en terugkerende patronen vormen vaak de input voor verbeterinitiatieven en change controls, waaronder changemanagement in HaloITSM.
Is het incidentmanagement van HaloITSM afgestemd op ITIL 4?
Ja. HaloITSM ondersteunt incidentcategorisering, prioritering, SLA-beheer, escalaties en afsluitingscontroles. SMC stemt de configuratie af op ITIL 4-praktijken via ITIL v4-gecertificeerde engineers en uw volwassenheidsniveau.
Kunnen gebruikers incidenten indienen en volgen in Microsoft Teams?
Ja. HaloITSM kan ondersteuning bieden voor intake via Teams, meldingen, goedkeuringen en selfservice-toegang. Dit verbetert de adoptie en vermindert het schakelen tussen contexten voor zowel gebruikers als agenten.
Hoe ondersteunt HaloITSM het beheer van grote incidenten (major incident management)?
Workflows voor grote incidenten kunnen worden geconfigureerd met specifieke prioriteitsniveaus, gespecialiseerde escalatiepaden, sjablonen voor communicatie met belanghebbenden en rollen. Integraties zoals PagerDuty kunnen on-call escalatie ondersteunen met gesynchroniseerde updates.
Hoe vermindert kennisbeheer het aantal incidenten?
Een gestructureerde kennisbank maakt selfservice mogelijk, verbetert de oplossingsgraad bij het eerste contact en vermindert herhaalde probleemoplossing. SMC configureert dit via de HaloITSM-kennisbank en selfservice en kan de kennisbasis uitbreiden met Document360.
Hoe is incidentmanagement in HaloITSM verbonden met wijzigingsbeheer (change management)?
Incidenten die configuratiewijzigingen vereisen, kunnen change management-workflows activeren, zodat wijzigingen de juiste goedkeuringen en controles volgen in plaats van informeel onder druk te worden toegepast.
Hoe lang duurt de configuratie van HaloITSM-incidentmanagement?
De typische doorlooptijd hangt af van integraties, volwassenheid en de gereedheid van de data. Veel incidentmanagement-trajecten gaan live binnen 4 tot 8 weken, met verdere optimalisatie in de eerste 90 dagen.
Wat kost incidentmanagement in HaloITSM?
De kosten zijn afhankelijk van de licenties en de omvang van de implementatie. Prijsinformatie is beschikbaar op HaloITSM pricing, en SMC verstrekt een gerichte schatting tijdens de inventarisatiefase.
Los incidenten sneller op met HaloITSM, met minder handmatige triage
HaloITSM geeft uw servicedesk de structuur om incidenten consistent te beheren en de automatisering om repetitief werk te verminderen. SMC Consulting configureert incidentbeheer zodat routing, SLA’s, kennis en integraties samenwerken als één besturingssysteem.
Recente artikelen
Van procesontwerp tot configuratie: hoe gecertificeerde engineers ITIL 4 vertalen naar ServiceNow-workflows
Leer hoe ITIL 4 naar ServiceNow-workflows best-practice richtlijnen omzetten in praktische, geautomatiseerde ITSM-processen, met behulp van slim ServiceNow-procesontwerp en gecertificeerde experts.
Read more →
AI-governance voor de servicedesk: beleid, goedkeuringen & audit trails (Benelux)
Een AI-governance servicedesk helpt Benelux IT-teams om AI verantwoord te gebruiken met een duidelijk beleid, human-in-the-loop controles, gedetailleerde audit trails en naleving van de AVG en de EU AI-verordening voor veiligere ITSM-operaties.
Read more →