Het change-proces kan behoorlijk langdradig zijn en de vaart uit je organisatie halen. Hoe maak je het change management proces agile? Door de Change Advisory Board (CAB) opnieuw uit te vinden. Lees verder hoe je dit aanpakt.
Het probleem: De CAB remt jouw organisatie
We weten het allemaal: De CAB is een beetje een probleem.
In theorie is het een geweldige manier om veranderingen in de organisatie te beheren. In de praktijk vertraagt de CAB het hele change-proces. En niet zo’n beetje ook.
In heel wat organisaties duurt het behandelen van requests weken of zelfs maanden. Zoals deze organisatie die altijd een achterstand had van ongeveer 180 change requests. Het duurde daar maanden om de meest eenvoudige wijzigingen door te voeren.
Dit is onacceptabel in een wereld waar agile en flexibel werken extreem belangrijk is voor IT-organisaties. Maar hoe kan jouw organisatie change requests sneller goedkeuren zonder de controle te verliezen?
Hoog tijd om jouw CAB en het change-proces te herzien. Hier gaat het fout:
Verander je mindset: De CAB hoeft niet alle changes te beoordelen
Jouw CAB beoordeelt waarschijnlijk alle requests voor non-standard changes. Netjes volgens de ITIL-richtlijnen. Dit is natuurlijk niet vol te houden.
De meeste organisaties hebben veel meer change requests dan tijdens een CAB vergadering behandeld kunnen worden. Het is onmogelijk om alle aanvragen tijdens een CAB vergadering in detail te behandelen – en dat moet je ook helemaal niet willen. De meeste aanvragen hebben namelijk vrij weinig impact, dus hoeven ze niet te worden beoordeeld door een commissie van zes tot acht personen.
Je moet het kaf van het koren zien te scheiden: Bepaal welke change requests tijd en aandacht van de CAB nodig hebben en welke niet. Dat klinkt misschien een beetje tegenstrijdig, want hoe kun je de gevolgen van een change inschatten voordat je ze hebt geanalyseerd?
Dat doe je zo.
De oplossing: Introduceer een Quick Impact Score
Maak kennis met onze Quick Impact Score: Een simpelere versie van een impactanalyse voor non-standard changes. Het doel is bepalen of een change request goedgekeurd moet worden en zo ja, door wie.
Zo werkt het.
1. Kies je impactcriteria
Begin met het opstellen van enkele criteria om de gevolgen van een change request af te wegen. Je bepaalt zelf welke criteria je kiest, maar gebruik het liefst niet meer dan vijf criteria. De combinatie van de volgende factoren geeft de verwachte gevolgen van een change behoorlijk goed weer:
- Aantal getroffen klanten: Hoeveel mensen worden door de change getroffen als er iets misgaat? Hoe groter het aantal, hoe hoger de impact.
Kosten: Welke kosten zijn er verbonden aan het doorvoeren van de change? Hoe hoger de kosten, hoe hoger de impact. - Aantal betrokken medewerkers: Hoeveel medewerkers zijn er betrokken bij het doorvoeren van de change? Hoe meer medewerkers en partijen er betrokken zijn, hoe hoger de impact.
- Security: Welke security risico’s brengt deze change met zich mee? Als de change een security risico vormt, heb je waarschijnlijk te maken met een change met veel impact.
- Wet- en regelgeving: Heeft de change invloed op de naleving van de wet- en regelgeving? Als het antwoord ja is, is het waarschijnlijk een change met veel impact.
2. Definieer de impact per criterium
Bepaal voor elk van deze criteria een bandbreedte voor lage, gemiddelde en hoge impact.
Bij ‘aantal getroffen klanten’ zou je het volgende kunnen onderscheiden: één persoon of één team is lage impact, één businessunit is gemiddelde impact en de hele organisatie is hoge impact. Doe hetzelfde voor de overige criteria.
Wanneer je een change request beoordeelt op basis van deze criteria, wordt de totale impactscore bepaald door de hoogste score.
3. Wijs voor elke impactscore een verantwoordelijke aan
De volgende stap is bepalen wie er beslist over change requests met een lage, gemiddelde en hoge impact. Dit kun je inrichten zoals je zelf wilt, als je er maar voor zorgt dat er een balans bestaat tussen kwaliteitscontrole en snelle besluitvorming. De truc is alleen de noodzakelijke personen erbij te betrekken.
Je kunt de goedkeuring van change requests als volgt afhandelen:
- Lage impact: Geen goedkeuring nodig. Het request kan worden verwerkt door de betreffende medewerker. Dit gaat meestal om eenvoudige wijzigingen.
- Gemiddelde impact: Heeft iemands goedkeuring nodig. Je kunt dit overlaten aan een changemanager maar ook aan de IT-manager of een andere procesmanager. Stel iemand aan die op tactisch niveau werkt en vertrouwd is met het soort changes dat jouw team afhandelt.
- Hoge impact: Vereist goedkeuring van de CAB. Voor deze change requests is het business as usual.
Normaal gesproken heeft ongeveer 80 procent van alle requests een lage impact en 10 tot 15 procent een gemiddelde impact. Dit betekent dat de CAB nog maar 5 tot 10 procent van alle change request hoeft te behandelen. Ja, je leest het goed: jouw CAB zou nog maar 5 tot 10 procent van hun huidige werklast hebben.
Je weet nu wat er nodig is om een Quick Impact Score voor een change request te berekenen. Laten we het eens uitproberen.
Zo maak je jouw change management proces eenvoudiger. >>
De impact van een change request beoordelen
Stel dat je in de hele organisatie een gratis applicatie zoals Notepad++ wilt updaten. Dat is voor een applicatiebeheerder nog geen dag werk en er zijn ook geen security- of compliance-problemen. Dus, hoe ziet de Quick Impact Score er dan uit?
1. Beoordeel het change request op basis van jouw criteria
Je beoordeelt de criteria als volgt:
• Aantal getroffen klanten: alle medewerkers => hoge impact
• Kosten: gratis => lage impact
• Aantal betrokken medewerkers: 1 => lage impact
• Security: geen security risico’s => lage impact
• Wet- en regelgeving: niet van toepassing
2. De hoogste score is jouw impactscore
Bij een Quick Impact Score wordt de impactscore van een change request bepaald door de hoogste waarde – niet door een gemiddelde. In dit voorbeeld zijn alle impactscores laag, met uitzondering van het ‘aantal getroffen klanten’, dat een hoge impact heeft. Dit betekent dat de impactscore voor deze hele change request hoog is.
3. Kijk of je de impact van je change request kunt verlagen
Bij changes met een gemiddelde of hoge impact is de vraag of je de impactscore kunt verlagen.
In het geval van het updaten van Notepad++, kun je kijken of je het aantal getroffen klanten kunt beperken. Misschien lukt dit door de update buiten werktijd uit te voeren. Of door eerst een kleine testgroep te updaten. Als dat succesvol is, verlaag je de impact van het updaten van de app ook voor de rest van de organisatie.
De CAB overtuigen om de teugels te laten vieren
Deze Quick Impact Score zal niet zonder slag of stoot worden overgenomen.
Misschien krijg je dit wel te horen: “Je voorstel is best logisch, maar ik denk niet dat het in mijn organisatie zal werken.” Meestal is het onderliggende probleem dat CAB-leden de controle deels uit handen moeten geven – en de meeste organisaties zien dat niet zo snel gebeuren.
Begrijpelijk. Het beoordelen van alle change requests met een groep vertegenwoordigers van alle afdelingen is inderdaad een manier om het risico van voorgestelde changes te beheersen. We stellen ook niet voor om de CAB zomaar op te heffen – de CAB heeft een belangrijke functie in het change-proces, en dat zal in de toekomst zo blijven.
Maar: weegt het voordeel van het voorkomen van mogelijke (kleine) risico’s op tegen de nadelen die je huidige processen met zich meebrengen? Alle tijd die CAB- leden aan het change-proces kwijt zijn? De soms belachelijk lange verwerkingstijden van requests? Het gebrek aan agile werken van de organisatie? Het antwoord is nee.
De risico’s van veel changes zijn vrijwel nihil. Sommige CAB’s besteden hun tijd aan evalueren of er wel of geen veld aan een stuk software moet worden toegevoegd. Daar zou een CAB niets mee te maken hoeven te hebben.
Ja, als je overstapt op Quick Impact Scores verliezen CAB-leden een deel van hun invloed op veel van de changes. Maar het is het waard: de organisatie wint aan snelheid en efficiëntie en wordt meer agile. De meeste CAB-leden steken vast en zeker liever energie in werk dat meer waarde aan de organisatie levert in plaats van twee uur per week te besteden aan het beoordelen van alle mogelijke change requests.
Werken naar een agile CAB
Als je jouw draak van een change-proces echt meer agile en sneller wil maken, heb je geen andere keus dan de werkwijze van je CAB te veranderen. Wat als een CAB-lid bezwaar maakt? Benadruk hoeveel tijd ze krijgen om hun talenten op een andere manier te gebruiken, waardoor hun invloed op de organisatie alleen maar groter wordt.
Meer over Agile Service Management
Zoek je naar inspiratie om jouw servicemanagement meer agile te maken? Wie weet vind je de volgende blogs interessant:
• Blog: Hoe je het change management proces meer agile maakt
• Blog: Change management op een agile manier implementeren
• Blog: Agile service desk? Vergeet Scrum, begin met Kanban
• E-book: Agile Service Management: het complete handboek
Of verdiep je verder in Agile Service Management met het gratis e-book.
