ITSM voor razendsnelle teams
De evolutie van IT-verandermanagement
Verandermanagement, ook wel "change enablement" genoemd, is een IT-methode die is ontworpen om verstoringen van IT-services te minimaliseren terwijl je wijzigingen aanbrengt in kritieke systemen en services.
Een verandering bestaat uit het toevoegen, wijzigen of verwijderen van iets dat een direct of indirect gevolg kan hebben op services.
Verandermanagementmethoden zijn ontworpen om incidenten te verminderen en aan wettelijke normen te voldoen. De methoden zorgen voor een efficiënte en snelle afhandeling van wijzigingen in IT-infrastructuur en -code. Of je nu nieuwe services uitrolt, bestaande services beheert of problemen in code oplost: moderne benaderingen voor verandermanagement maken een einde aan eilandjes, bieden context en transparantie, vermijden knelpunten en minimaliseren risico's.
Risicobeheer is een gerelateerde ITIL 4-methode, die wordt gevolgd "om ervoor te zorgen dat de organisatie risico's begrijpt en er effectief mee omgaat". Zowel verandermanagement als risicobeheer vereist dat wijzigingen worden bijgehouden en gekoppeld, zodat een controleerbaar record ontstaat. Het vermogen om uit gegevens over eerdere veranderingen en hun slagingspercentages te putten, stelt organisaties in staat hun methoden aan te passen op een manier die risico en snelheid slim in evenwicht brengt.
Adaptieve methoden op basis van gegevens streven naar efficiëntie. Traditioneel verandermanagement is daarentegen vaak onnodig traag, procesbelastend en overbelast. Omdat verandermanagement zich bezighoudt met uitdagingen rond risico en naleving, controleerbaarheid en teamoverschrijdende coördinatie, ontaard het te vaak in complexe, bureaucratische en pijnlijke toestanden.
Toch hoeft dat niet zo te zijn. Denk aan verandermanagement als "de schijf van vijf" voor ITSM: het is niet altijd smakelijk, maar van cruciaal belang. Met de juiste methoden en cultuur kan verandermanagement leiden tot minder incidenten, minder stress onder teams en meer tijd voor het leveren van waarde aan klanten.
De definitie van verandermanagement
Voor ons omvat verandermanagement elk aspect van verandering -van technologie, mensen en processen tot de impact op klanten en systemen. Om duidelijkheid te bieden in de context van ITSM, heeft ITIL 4 een onderscheid gemaakt tussen IT-verandermanagement en organisatorische veranderingspraktijken.
- Organisatorisch verandermanagement is de "methode om ervoor te zorgen dat veranderingen in een organisatie soepel en succesvol worden geïmplementeerd en dat blijvende voordelen worden behaald door de menselijke aspecten van de veranderingen te beheren".
ITIL 4 definieerde het verandermanagementproces daarna opnieuw als de praktijk van "controle over veranderingen".
- De methode voor controle over veranderingen waarborgt dat "risico's goed worden beoordeeld, wijzigingen worden toegestaan om door te gaan, en een wijzigingsschema wordt beheerd om het aantal succesvolle service- en productwijzigingen te maximaliseren".
Deze nieuwe naamkeuze veroorzaakte controverse. Veel IT-teams verwierpen de associatie met "controle". Voor sommigen is het een giftig woord dat gedachten oproept aan de bureaucratie, knelpunten en onnodige stappen waarom traditioneel verandermanagement berucht is.
Axelos luisterde naar de feedback en reageerde. "Na het uitbrengen van ITIL 4 Foundation hebben we van verschillende mensen over de hele wereld gehoord dat 'de praktijk verkeerd werd geïnterpreteerd of verkeerd werd begrepen als gericht op "het beheersen van veranderingen" of "controleren van teams", in plaats van : het beheersen van de snelheid van veranderingen'."
ITIL besloot uiteindelijk om de praktijk "change enablement" te noemen. De nieuwe naam duidt op een oefening die teams helpt en hen de mogelijkheid -en vrijheid- biedt om veranderingen aan te jagen.
Uiteindelijk vinden we het niet zo belangrijk welke term je gebruikt. (In dit artikel, en bij Atlassian, spreken we over "verandermanagement".) Wat wél belangrijk is, is jouw aanpak. Begin met gezonde teams en de juiste cultuur. Daarmee is je organisatie op de goede weg om een effectieve verandermanagementpraktijk te creëren.
De relatie tussen verandermanagement en releasebeheer
Releasebeheer is een andere methode die belangrijk is wanneer het over verandermanagement gaat. Volgens ITIL 4 is releasebeheer bedoeld "om nieuwe en gewijzigde services en functies beschikbaar te maken voor gebruik". Releases kunnen alles omvatten: van wijzigingen in softwarefunctionaliteit tot documentatie en trainingsupdates.
Historisch gezien werden bij releasebeheer veranderingen gebundeld en als één pakket aan klanten gepresenteerd. Traditioneel releasebeheer hanteert strenge normen voor projectbeheer. Dat kan wrijving veroorzaken bij het verzenden van waardevolle updates naar klanten, wat weer leidt tot frustratie bij teams die zich houden aan de Agile-principes.
We kunnen opnieuw naar releasebeheer kijken voor de DevOps-context. Releasebeheer moet loskomen van de traditionele projectmanagementfunctie en gaan over integratie en automatisering. Het begint met het plaatsen van codepijplijnen in een beveiligd systeem dat, waar mogelijk, geautomatiseerde beoordeling omvat en tracking en toezicht biedt. Dit kan een einde maken aan de traditionele verzuilde benadering en een moeiteloze route naar productie bieden. Releasebeheer kan gaan over alles wat het gemakkelijker dan ooit maakt om continu waarde te leveren en het "you build it, you own it"-principe toe te passen.
Waarom is IT-verandermanagement belangrijk?
Moderne organisaties kennen een aantal kritische en concurrerende verwachtingen voor hun IT-team. Ten eerste verwachten ze stabiele, betrouwbare services die ervoor zorgen dat de organisatie productief is en aan de verwachtingen van de eindgebruiker kan voldoen. Ten tweede moet het IT-team regelmatig service-updates implementeren, zodat de organisatie zich kan aanpassen aan beveiligings-, kosten- en bedrijfsvereisten die voortdurend veranderen.
Als je een van beide zaken loslaat, kan dit ernstige gevolgen hebben. Het onvermogen om een betrouwbare service te behouden, kan tot enorme schade op het gebied van productiviteit en kosten leiden. Veel organisaties melden volgens Gartner dat downtime meer dan $ 300.000 per uur kost. Dat getal kan nog hoger zijn bij sommige onlineservices.
Tegelijkertijd zullen organisaties die zich niet op de toekomst voorbereiden geen gelijke tred kunnen houden met de snelheid van het bedrijfsleven. Daardoor gaan ze onherroepelijk achterlopen op hun concurrentie. Het te langzaam implementeren van veranderingen kan ertoe leiden dat werknemers overlopen naar werkgevers met minder onhandige systemen. Ook kunnen je klanten overstappen naar andere organisaties die hen meer waarde bieden.
Hoe ga je om met die tegenstrijdige behoeften? Dankzij verandermanagement kan je organisatie updates uitbrengen en tegelijkertijd stabiliteit garanderen en risico's beperken. Verandermanagement helpt op de volgende manieren om veranderingen tot stand te brengen:
- Het vormt een framework om het veranderingsproces te beheren
- Het geeft prioriteit aan noodzakelijke wijzigingen om bronnen correct toe te wijzen
- Het houdt rekening met relevante informatie voor slimmere besluitvorming
- Het betrekt de nodige belanghebbenden (ontwikkelaars en IT) voor goedkeuringen
- Het gebruikt tests voor veranderingen om incidenten te voorkomen
- Het stroomlijnt en verbetert de stroom van veranderingen om sneller waarde te leveren
Soorten wijzigingen
ITIL definieert drie soorten wijzigingen.
Standaardveranderingen
Standaardveranderingen zijn vooraf goedgekeurd, worden vaak herhaald en dragen weinig risico. Ze worden regelmatig uitgevoerd en volgen een gedocumenteerd, goedgekeurd proces.
Het toevoegen van geheugen of opslag is bijvoorbeeld een standaardwijziging. Het vervangen van een defecte router door een identieke werkende router is een standaardwijziging. Het maken van een nieuwe instantie van een database is een standaardwijziging.
Al deze veranderingen komen veel voor en volgen een goed gedefinieerd proces. En omdat het risicobeoordelings- en goedkeuringsproces van verandermanagement vermoedelijk al één keer is doorlopen, hoeft het proces niet elke keer opnieuw te worden doorlopen wanneer een router moet worden vervangen.
Voor veel bedrijven bieden standaardwijzigingen een uitstekende gelegenheid voor automatisering. Sommige bedrijven melden dat maar liefst 70% van de standaardwijzigingen kan worden geautomatiseerd, waardoor hun teams zich kunnen concentreren op normale en acute veranderingen.
Normale veranderingen
Normale veranderingen zijn niet-urgente veranderingen zonder vaststaand en vooraf goedgekeurd proces.
Upgraden naar een nieuw contentmanagementsysteem is bijvoorbeeld een normale verandering. Migreren naar een nieuw datacenter is een normale verandering. Prestatieverbeteringen zijn normale veranderingen. Ze zijn niet standaard en herhaalbaar. Er zijn risico's aan verbonden. Maar ze zijn ook geen noodgevallen. Dat betekent dat ze in de gebruikelijke wachtrij voor verandermanagement kunnen worden geplaatst voor risicobeoordeling en goedkeuring.
Sommige normale veranderingen, zoals het wisselen van data center, dragen mogelijk een hoog risico met zich mee en kunnen een risicobeoordeling en goedkeuring vereisen van een wijzigingsadviesraad (CAB). Anderen, zoals een websitewijziging, kunnen een laag risico hebben en kunnen sneller tijdlijn worden goedgekeurd door een aangewezen veranderingsautoriteit of via geautomatiseerde controles en peer review.
Noodveranderingen
Deze veranderingen komen voort uit een onverwachte fout of dreiging die onmiddellijk moet worden aangepakt, meestal om de service aan klanten of werknemers te herstellen of systemen te beveiligen tegen een bedreiging.
Het implementeren van een beveiligingspatch is bijvoorbeeld een noodwijziging. Het omgaan met een serverstoring is een noodwijziging. Het oplossen van een groot incident is een noodwijziging.
Door hun urgentie moeten noodwijzigingen binnen veel kortere tijd worden afgehandeld omdat het risico van een uitgebreid beoordelingsproces hoger is dan de risico's van het snel oplossen van de issue.
Hoe je je veranderingen categoriseert is afhankelijk van factoren zoals je organisatie, processen en risicotolerantie. Wij raden aan om de ‘one size fits all’ methode achter te laten, en om iedere verandering anders te behandelen op basis van risicobeoordeling. Naarmate je organisatie meer leert over eerdere incidenten, bepaalde systemen en andere relevante gegevens, moet het mogelijk zijn om een groter deel van de veranderingen als standaard te behandelen, en vooraf goed te keuren. Modern verandermanagement moet aanvragen voor veranderingen zo eenvoudig en gestroomlijnd mogelijk maken.
Wat is een wijzigingsadviesraad (CAB)?
In de meeste traditionele IT-organisaties is een wijzigingsadviesraad (CAB) belast met het beoordelen van de risico's en het goedkeuren (of niet goedkeuren) van elke wijziging. Doorgaans belegt een CAB regelmatig vergaderingen om alle voorgestelde aankomende veranderingen te evalueren. Waar nodig worden experts ingeschakeld om de verandering met uit te leggen, te verdedigen of te beoordelen.
Enerzijds kunnen wijzigingsadviesraden helpen om risico's te verminderen en alarm te slaan wanneer een verandering gewoon niet werkt voor het bedrijf. Aan de andere kant kunnen ze ook een knelpunt creëren –vooral als ze bestaan uit mensen die niet dicht bij de veranderingen staan die worden doorgevoerd. Neem het goedkeuringsproces van de wijzigingsadviesraad (CAB): dat is vaak complex en tijdrovend, wat het proces vertraagt.
Veel IT-teams stappen af van traditionele CAB-vergaderingen of beperken de omvang ervan tot de meest risicovolle veranderingen en belangrijke organisatorische problemen. In dit paradigma kunnen CAB's betrouwbare adviseurs worden die verantwoordelijk zijn voor het volgen van trends, voor het adviseren over methoden om deze aan te pakken, en voor het afstemmen van teams en hun behoeften.
ITIL 4 moedigt ook aan om je wijzigingsautoriteit te decentraliseren naar het niveau van de zakelijke belanghebbende of collega's. Kies niet voor een aparte commissie, maar bouw verandermanagement in normale workflows met relevante belanghebbenden. Voorkom knelpunten door automatisering, virtuele checklists en peer reviews te implementeren: deze oplossingen zijn wendbaarder en meer gericht op samenwerking.
Het verandermanagementproces
Voor wendbare teams met hoge snelheid verschuift het verandermanagementproces weg van langdurige reviews en niet-technische goedkeuringen van belanghebbenden –in de richting van geautomatiseerde samenwerkingsprocessen tussen IT- en ontwikkelingsteams. Hierdoor neemt hun wendbaarheid toe en blijven risico's toch risico's in balans.
Hier volgt een basisoverzicht van een verandermanagementproces, samen met enkele aanbevelingen om je snelheid te verhogen om waarde te leveren.
| Step | Best Practices |
| Wijzigingsverzoek - Iemand vraagt om een verandering en vermeldt daarbij mogelijke risico's, de verwachte implementatie en de betrokken systemen. | Maak een intuïtieve zelfhulpportal waar belanghebbenden en IT-medewerkers eenvoudig een standaard wijzigingsverzoek kunnen indienen. nZorg ervoor dat je ontwikkelingsteams en IT-teams op hetzelfde platform kunnen samenwerken, zodat ze beschikken over volledige context en transparantie tijdens de workflow voor wijzigingsverzoeken. |
| Beoordeling van een wijzigingsverzoek - Een verandermanager of beoordelaar beoordeelt het eerste wijzigingsverzoek. Hoe groot is de kans op succes? Zijn de risico's en beloningen juist? Is het de moeite waard? | Gebruik automatisering om de wijziging automatisch goed te keuren of start een kort goedkeuringsproces voordat de wijziging wordt doorgevoerd. |
| Veranderplan - Het team maakt een draaiboek voor de verandering. Het documenteert verwachte resultaten, bronnen, een tijdlijn, testvereisten en manieren om de wijziging zo nodig terug te draaien. | Breng belanghebbenden snel op één lijn met een kick-off voor verandermanagement. Zorg dat alle neuzen dezelfde kant op staan met kennisdatabasesjablonen om je wijzigingsplannen te documenteren. |
| Goedkeuring van de wijziging -De juiste verandermanager, peer reviewer of CAB beoordeelt het plan en keurt de wijziging goed. | Stroomlijn goedkeuringen met peer reviews. Maak een einde aan eilandjes door gedeelde overzichten van uitgevoerde werkzaamheden en documentatie, zodat mensen gemakkelijk en asynchroon kunnen samenwerken. |
| Implementatie van de wijziging -Het team verzendt de verandering en documenteert onderweg procedures en resultaten. | Gebruik automatisering om je processen en standaarden mogelijk te maken. Workflowautomatisering kan verzoeken routeren en toewijzen aan de volgende geautoriseerde persoon op basis van je bedrijfsregels. |
| Afsluiting van wijziging - Indien van toepassing beoordeelt en sluit de verandermanager de wijziging. Het rapport moet aangeven of de wijziging succesvol en tijdig was, nauwkeurig werd ingeschat, binnen het budget viel, enz. | Zorg dat de artikelen in de kennisdatabase en de tickets toegankelijk blijven, zodat teams kunnen leren van eerdere werkzaamheden. Misschien zijn er mogelijkheden om soortgelijke wijzigingsverzoeken in de toekomst te automatiseren. |
Beproefde methoden voor verandermanagement
Zoals we eerder al zeiden, veroorzaakt verandermanagement dezelfde soort angst die sommigen van ons voelen bij het eten van bladgroenten. We kijken niet altijd uit naar het gerecht, maar weten hoe belangrijk het is. We kunnen stappen ondernemen om beide dingen aantrekkelijker te maken.
Hier zijn enkele beproefde methoden voor modern verandermanagement:
- Begrijp de risicotolerantie en wettelijke verplichtingen van je organisatie
- Vereenvoudig en automatiseer, waar mogelijk, processen voor verandermanagement
- Geef CAB's een meer strategische focus
- Omarm methoden om van standaardveranderingen het nieuwe normaal te maken
- Bekijk verschillende frameworks, zoals ITIL en DevOps, om richtlijnen te vinden die het beste werken voor jouw organisatie
- Geef prioriteit aan samenwerking
- Gebruik chaostechniek om je risico te verminderen
- Stroomlijn de inname van veranderingsaanvragen voor IT, ontwikkelaars en zakelijke teams
- Maak leren mogelijk met veranderingsstatistieken en KPI's
- Omarm een DevOps-gestuurde aanpak voor releasebeheer
Meeliften op de uitdagingen van verandermanagement
Ontwikkelaars willen code snel uitrollen, zónder extra tijd en moeite te besteden aan handmatige documentatie. Operationele IT-teams proberen risico's te verminderen, gedetailleerde gegevens voor audits bij te houden en incidenten te voorkomen. Wanneer je ontwikkelaars vraagt om een extra stap aan hun processen toe te voegen, dingen op te schrijven, in te klokken en uit te klokken, kan dat het gevoel geven dat je hen weerhoudt van de uiteindelijke doelen van hun werk. Het is niet eenvoudig om het ops-team vragen om bestaande processen te herzien, goedkeuringscontroles op te heffen en meer over te laten aan automatisering. Je kunt het gevoel krijgen dat zoiets meer risico met zich meebrengt.
Maar er staat meer op het spel dan ooit. Door de opkomst van softwarematige services hebben klanten steeds hogere verwachtingen en is er steeds meer vraag naar services die altijd beschikbaar zijn en goed presteren. In een steeds dynamischer wordende omgeving blijft het werk dat nodig is om diensten te beheren groeien.
Hoe kunnen we deze uitdagingen het hoofd bieden? Dat begint met het wegnemen van de mythe dat een zwaar proces risico's vermindert. Omarm een cultuur en de bijbehorende methoden en tools die teams helpen samen te werken en resultaat te leveren. En verzamel tot slot voortdurend informatie om de waarde van de vorige stappen aan te tonen en te blijven streven naar verbetering.
Wilje zien hoe Jira Service Management jouw verandermanagementproces kan transformeren?
Atlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
De whitepaper lezenKennisdatabase: jouw oplossing voor betere samenwerking
Ontdek de kracht van een kennisdatabase voor je bedrijf. Verhoog de productiviteit, verbeter de klantenservice en vereenvoudig effectief het gegevensbeheer.
Lees het artikel