ITIL in de praktijk: change management
In deze blogreeks, ITIL in de praktijk, ga ik dieper in op de verschillende ITIL-processen. ITIL bestaat in totaal uit 26 complexe processen die allemaal samenhangen. Om wat licht in deze duisternis te scheppen start ik deze blogreeks. Het eerste proces dat ik hier bespreek is change management, omdat ik bij veel van onze klanten merk dat dit het meest complexe proces is om goed in te richten.
Change management wordt vaak gezien als bureaucratisch en remmend. Men roept al snel ‘wéér een extra managementlaag!’. Maar een juiste implementatie van change management biedt juist veel voordelen: stabiliteit, continuïteit en grip op alles wat de klant in de productie aangepast wil hebben.
Het doel van het proces
ITIL zegt het volgende over het doel: de primaire doelstelling van change management is het faciliteren van nuttige wijzigingen waarbij de ict-dienstverlening zo min mogelijk verstoord wordt. Change management zorgt ervoor dat de wijziging op een gecontroleerde manier wordt vastgelegd, geëvalueerd, gepland, getest, geïmplementeerd en gedocumenteerd.
Twee prachtige volzinnen, maar wat betekent dit nu in de praktijk en hoe implementeer je zo'n proces?
De stappen in het proces
Een goed change management-proces bestaat uit de volgende fases:
To do | Hoe? |
---|---|
1. RFC vastleggen | De aanvraag wordt vastgelegd in de servicemanagement-tool. |
2. Wijziging aanmaken | De ict-afdeling zorgt voor een vertaling van de functionele klantvraag naar een goede oplossing. |
3. CAB geeft akkoord voor de start | In het CAB wordt de beslissing genomen of de voorgenomen wijziging binnen het ict-beleid past, de planning haalbaar is en er voldoende budget is. |
4. Wijziging doorvoeren | Tijdens deze stap in het proces wordt de wijziging op de testomgeving gerealiseerd en getest zodat iedereen zeker weet dat deze zonder problemen naar productie gaat. |
5. CAB geeft akkoord voor implementatie | In deze stap zal het CAB de wijziging beoordelen op vlakken als: kennisoverdracht naar beheer, uitvoering van de juiste tests en de vraag stellen of er nazorg geregeld is voor als de wijziging in productie staat. |
6. Evalueren en sluiten | Na het succesvol live-gaan van een wijziging zal deze geëvalueerd worden om te zien of zich geen incidenten hebben voorgedaan. Als alle lichten op groen staan wordt de wijziging gesloten. |
Zoals je in de stappen van dit proces kunt zien worden er ook een aantal afkortingen gebruikt. Daar zijn we binnen de IT heel goed in:
Afkorting | Toelichting |
---|---|
RFC | RFC staat voor request for change en is een gestandaardiseerd formulier waarop alle beschikbare informatie wordt ingevuld. Op basis hiervan wordt een beslissing genomen over de uitvoering van de wijziging. Denk hierbij aan informatie die ook terugkomt in een business case, zoals budgethouder, reden van de wijziging, wat er gebeurt als de wijziging niet uitgevoerd wordt, etc. |
CAB | CAB staat voor change advisory board, en is het overlegorgaan dat beslist of een change uitgevoerd gaat worden. Dit gremium kan afhankelijk van de omvang van de organisatie, hoeveelheid wijzigingen en de complexiteit van deze wijzigingen bestaan uit één persoon, de change manager, of uit meerdere beslissingsbevoegde collega's. |
De implementatie
De implementatie kan behoorlijk moeilijk zijn, dus de beste tijd om dit proces te implementeren is wanneer er net een grote verstoring is geweest. Op zo'n moment is het belangrijk om meer grip te krijgen op de situatie.
Andere goede aanleidingen kunnen zijn:
- Medewerkers klagen over de werkdruk.
- Klanten klagen over het niet nakomen van afspraken.
- Er zijn verstoringen als gevolg van eerdere wijzigingen.
Zorg dat het doel van deze procesimplementatie helder gecommuniceerd wordt. Change management is een middel en géén doel op zich.
Een goede implementatie bestaat uit de volgende stappen:
Stappenplan |
---|
1. Wijs een change manager aan |
2. Beschrijf het proces |
3. Stem het proces af met alle betrokkenen. |
4. Richt de servicemanagement-tool in |
5. Train en begeleid de medewerkers |
6. Vier het succes van de implementatie! |
7. Zorg voor goede rapportages |
Valkuilen
Zoals bij elke procesimplementatie zijn er een aantal valkuilen die gemakkelijk te voorkomen zijn:
Valkuil | Maatregel |
---|---|
Het CAB werkt niet | Zorg dat het CAB geen Poolse landdag wordt. Vaak bestaat het uit een vaste kern met iemand vanuit de business, teamleiders vanuit het beheer en vertegenwoordigers van de servicedesk. Op ad hoc-basis kunnen mensen worden uitgenodigd om hun wijzigingsaanvraag toe te lichten. |
Een wijziging hoeft maar één keer langs het CAB: vóór de livegang van de wijziging | Zorg dat een wijziging altijd twee keer door het CAB wordt beoordeeld. Hierdoor hou je grip op de gemaakte arbeidsuren. In kleinere organisaties waar veel onderling contact wordt onderhouden, kan het volstaan om het CAB slechts één keer te betrekken, maar de voorkeur heeft toch wel om een wijziging zowel voor de start van de bouw als voor de implementatie te laten verifiëren door het CAB. |
De eisen voor een wijziging zijn onduidelijk | Zorg voor een gestandaardiseerde lijst met eisen waar een wijziging aan moet voldoen voordat deze goedgekeurd wordt. |
De toegevoegde waarde van change management
Change management is vanuit de theorie een complex proces. Het heeft echt wel wat voeten in de aarde om dit goed te implementeren, maar met de handvatten in deze blogpost kom je al een heel eind.
Misschien vind je dit leuk
Anderen hebben deze artikelen gelezen