Close

Neem een duik in Jira Service Management en andere krachtige tools bij Atlassian presenteert: Razendsnel ITSM.

Meld je gratis aan

Klaar voor ITSM met hoge snelheid?

Hoe teams de rollen en verantwoordelijkheden bij verandermanagement delen

Het kerndoel van elke verandering is om incidenten te verminderen terwijl je werkt aan updates die de klanttevredenheid vergroten en een voorsprong op de concurrentie opleveren. Die praktijk heeft gevolgen. Klanten hebben steeds hogere verwachtingen en willen services die altijd beschikbaar zijn en goed presteren. In een steeds dynamischer wordende omgeving is het van cruciaal belang om diensten zorgvuldig te beheren en frequente verbeteringen door te voeren. Moderne teams hebben methoden omarmd die risicobeperking mogelijk maken en die tegelijkertijd op de meest gestroomlijnde en flexibel mogelijke manier waarde toevoegen voor klanten.

Om die doelen te bereiken, hebben organisaties verschillende rollen en verantwoordelijkheden benoemd rondom verandermanagement. In een grote onderneming kunnen deze rollen en verantwoordelijkheden worden gedeeld tussen verschillende functies en teams.

In kleinere organisaties kan één persoon de verantwoordelijkheden op zich nemen náást andere elementen van zijn baan. Iemand die verantwoordelijk is voor verandermanagement kan tegelijkertijd ontwikkelaar of teamleider zijn. In andere gevallen kunnen processen langzaam worden ingebouwd in en worden gedeeld tussen bestaande teams.

Er is niet één goed model voor het toewijzen van verantwoordelijkheden op het gebied van verandermanagement. Organisaties moeten de opstelling bedenken die het beste bij hun behoeften past. Toch kunnen alle teams profiteren wanneer een aanpak wordt heroverwogen waarbij afgevaardigden verantwoordelijkheden voor veranderingen delegeren aan mensen met specifieke functies die vaak op grote afstand zitten van de projecten die ze beoordelen.

Door nieuwe mogelijkheden te omarmen om bestaande processen te automatiseren en stroomlijnen, kunnen we zorgen dat iedereen die bij verandermanagement betrokken is meer strategische rollen op zich kan nemen. Ook kunnen we teams daardoor de tijd te geven om zich te concentreren op hun belangrijkste prioriteiten.

Veelvoorkomende rollen voor verandermanagement

De rollen die bij verandermanagement betrokken zijn, zijn afhankelijk van tal van factoren, waaronder de omvang en het type IT-organisatie. Hier zijn enkele van de meest voorkomende functies.

Manager/coördinator verandering

Verandermanagers, ook wel veranderingscoördinatoren genoemd, zijn doorgaans verantwoordelijk voor het beheer van alle aspecten van wijzigingen in de IT. Ze geven prioriteit aan wijzigingsverzoeken, beoordelen de impact ervan en accepteren of verwerpen wijzigingen. Ze documenteren ook processen voor verandermanagement en veranderingsplannen. Belangrijk is dat ze zich voorbereiden op CAB-vergaderingen en deze vergaderingen beleggen en voorzitten. Het succes van een verandermanager wordt doorgaans beoordeeld aan de hand van de vraag of hij of zij aan de timing- en budgetdoelstellingen voldoet.

Veranderingsautoriteiten/goedkeurders

Een veranderingsautoriteit is een persoon die de beslissing neemt om al dan niet toestemming te geven voor een wijziging. Soms is dit één persoon, zoals een manager of leidinggevende. Soms is het een groep mensen in een adviesraad. Soms is het een collega-beoordelaar. ITIL 4 schrijft: "In organisaties met een hoge snelheid is het gebruikelijk om de goedkeuring van wijzigingen te decentraliseren, waardoor de collegiale beoordeling een belangrijke voorspeller van hoge prestaties is."

Verandermanagers werken doorgaans nauw samen met de veranderingsautoriteit om wijzigingen goed te keuren en deze binnen een organisatie uit te rollen. In sommige gevallen, met name in kleine organisaties, is de verandermanager de veranderingsautoriteit. Hij of zij heeft de bevoegdheid om deze beslissingen te nemen zonder extra mensen of teams in te schakelen.

Zakelijke belanghebbenden

Zakelijke belanghebbenden zijn vaak betrokken bij verandermanagement en kunnen in het autorisatieproces worden betrokken. Dit komt vanwege het cruciale belang van software voor de meeste ondernemingen steeds vaker voor.

Als een wijziging bijvoorbeeld van invloed is op de koppeling tussen de betalingsregistratiesoftware van het financiële team en de CRM van het verkoopteam, moeten belanghebbenden van het financiële team en verkoopteam mogelijk bij CAB-vergaderingen worden betrokken en de uiteindelijke beslissingen over een wijziging.

Engineers/ontwikkelaars

Ontwikkelingsteams dienen doorgaans wijzigingen in ter goedkeuring. Ze documenteren ook de noodzaak ervan. Zodra een wijziging is goedgekeurd in bedrijven die een you-built-it-you-run-it-aanpak hanteren, implementeren deze teams de wijziging. Daarna controleren ze deze en reageren ze op incidenten of problemen die door de wijziging worden veroorzaakt. In andere gevallen staat het incidentmanagementteam, dat verantwoordelijk is voor eventuele incidenten die door de wijziging worden veroorzaakt, los van de ontwikkelaars die de wijziging doorvoeren.

Servicedeskmedewerkers

Servicedeskmedewerkers kunnen een uniek eerstelijnsperspectief bieden op incidenten en veelvoorkomende serviceproblemen die door een wijziging kunnen ontstaan.

Ops-managers

Omdat operationeel managers verantwoordelijk zijn voor het dagelijks draaiende houden van systemen, dragen zij risico's en afhankelijkheden aan.

Klantrelatiebeheerders

Om ook de stem van de klant te laten horen, kunnen klantrelatiebeheerders kennis delen over de klantmentaliteit, frustraties en steeds veranderende behoeften.

Functionarissen voor informatiebeveiliging en netwerktechnici

Experts op het gebied van netwerkbeveiliging en cloudinfrastructuur dragen belangrijke inzichten aan over bedreigingen en kwetsbaarheden.

De transformerende rol van CAB's (wijzigingsadviesraden)

Wat is een CAB?

Wijzigingsadviesraden (CAB's) roepen personen met de hierboven beschreven verantwoordelijkheden bijeen. Ze zijn belast met het beoordelen van de risico's van elk wijzigingsverzoek en goedkeuring (of afkeuring) ervan. 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. Traditionele CAB's staan bekend als poortwachters die het vrijgeven van wijzigingen controleren.

Daarom –en vanwege de saaie vergaderingen, lange achterstanden in wijzigingsverzoeken en afstand tot het werk zelf– worden CAB's vaak met minachting bekeken. Gelukkig evolueren veel CAB's om agile softwarelevering beter mogelijk te maken. Ook nemen ze een meer strategische adviserende rol in. CAB's veranderen in adviseurs die verantwoordelijk zijn voor het volgen van veranderingstrends, die methoden aanbevelen om deze trends het hoofd te bieden, en die zoeken naar manieren om teams beter in staat te stellen waarde te leveren aan klanten en om risico's te verminderen.

De uitdaging van CAB's

De clichés rond slechte vergaderingen gelden ook voor CAB's. We noemen ze vaak tijdverspillers omdat ze niet genoeg hebben bereikt, te veel willekeurige mensen betrekken en hun zaken ook per mail hadden kunnen afhandelen. Dit is deels te wijten aan de manier waarop traditionele CAB's werden bedolven onder verantwoordelijkheden.

Laten we de uitdaging eens bekijken aan de hand van een metafoor uit de luchtvaartindustrie. Je zou een CAB kunnen zien als een verkeerstoren op een luchthaven. Die verkeerstoren heeft één taak: de vliegtuigen vertellen wanneer ze kunnen landen. Het personeel op de toren zou nooit de taak krijgen om te beoordelen of de vliegtuigen structureel veilig zijn of dat de piloot de juiste papieren heeft. Die factoren zijn immers al zijn bevestigd door de FAA en anderen.

Ondertussen verzamelen veel te veel CAB's tal van belanghebbenden en moeten ze brede veiligheidsbeslissingen nemen over allerlei verschillende veranderingen. Dit gebeurt bovendien vaak aan het einde van de week, wanneer vermoeide mensen graag aan hun weekenden beginnen. De CAB is simpelweg niet opgezet om te slagen.

Bovendien houden CAB's zich vaak vooral bezig met het risico van incidenten die door veranderingen worden veroorzaakt. Dat is natuurlijk een belangrijke taak, maar CAB's moeten ook het risico afwegen van de vertraging van waardevolle veranderingen. Wanneer er te langzaam wordt bewogen, kan dat klanten pijn doen –en in een ultracompetitieve software-as-a-service-wereld de nekslag zijn voor een organisatie.

Het is mogelijk om de CAB een betere en gerichte rol te geven. Met de juiste methoden kunnen veel wijzigingen worden geautomatiseerd. Op deze manier kan de CAB een belangrijke adviseur worden, trends volgen en samenwerken met teams om snellere veranderingen mogelijk te maken waarvan klanten profiteren.

Je CAB positioneren als strategisch adviseur

Om de CAB te herpositioneren, moet je eerst het idee wegnemen dat zwaar verandermanagement positieve resultaten oplevert. Uit gegevens uit het State of DevOps-rapport 2019 bleek dat processen die de goedkeuring van een CAB vereisen een negatieve invloed hadden op de prestaties van softwarelevering. Respondenten die deze processen volgden, hadden 2,6 keer meer kans om slecht presteerden. Bovendien was er geen bewijs dat een formeel goedkeuringsproces tot lagere mislukkingspercentages leidde!

Daarom nemen moderne teams deze stappen om hun CAB's te verbeteren.

Stop met het behandelen van wijzigingsverzoeken als eenheidsworst

Elk wijzigingsverzoek biedt een kans om informatie te volgen en te verzamelen. We kunnen meer te weten komen over slagingspercentages, gerelateerde incidenten en de factoren die daarmee verband houden. Na verloop van tijd zou het, met gebruik van gegevens, mogelijk moeten zijn om steeds meer wijzigingen vooraf goed te keuren en te automatiseren. Alleen de meest consequente en risicovolle wijzigingen moeten persoonlijke goedkeuring vereisen.

Breng veranderings- en releasebeheer dichter bij elkaar

Van oudsher werden releases gebundeld en allemaal tegelijk gelanceerd. Aan CAB's vervolgens de tak om enorme pakketten met wijzigingen nauwgezet te controleren en goed te keuren. Die aanpak kan helpen bij grote incidenten, maar maakt het moeilijker om de oorzaak van een probleem te vinden. Hij vertraagt ook de snelheid waarmee teams waarde kunnen leveren aan hun klanten. Daardoor kunnen veranderings- en releasemanagers minder tijd besteden aan hun projectmanagementtaken.

Gebruik progressieve releases om te testen en te herhalen

Progressieve implementaties bieden een kleine subgroep van gebruikers de mogelijkheid om de stabiliteit te testen en bewijzen voordat de volledige implementatie wordt uitgevoerd. Dit beperkt de omvang van een mogelijk incident en bewijst het succes van een implementatie voordat deze in alle omgevingen wordt uitgerold.

Gebruik automatisering en tools om verandermanagement te stroomlijnen

Teams die snel werken denken steeds kritischer na over eerdere goedkeuringsmodellen. Het is mogelijk om virtueel samen te werken in plaats van een lange backlog aan wijzigingsverzoeken te behandelen tijdens een fysieke wekelijkse vergadering. Dat kan al in de vorm van een e-mail met wijzigingsverzoeken die voorafgaand aan een CAB-vergadering kunnen worden beoordeeld. In andere gevallen kunnen Jira-tickets en Confluence-pagina's beoordelaars de context bieden die ze nodig hebben om asynchroon samen te werken en wijzigingen goed te keuren. Teams kunnen met behulp van Jira Service Management op deze manieren samenwerken en zelfs deelnemen aan een videovergadering of een speciaal Slack-kanaal aanmaken. Afhankelijk van hoe je team het liefst in contact met elkaar blijft, staat alles nog steeds op dezelfde plek, zodat alle neuzen dezelfde kant op staan.

Oude ITSM-tools maken het moeilijk voor infrastructuur-, operations- en ontwikkelingsteams om een wijzigingsverzoek in te dienen. Overweeg automatisering en moderne software om minder handmatig wijzigingsinformatie te hoeven invoeren. Het laatste wat een ontwikkelaar wil is tickets invullen in een onhandig en gescheiden systeem, als dat werk automatisch kan worden gevolgd. Teams kunnen binnen Jira Service Management gebruikmaken van automatisering om veranderingsprocessen te stroomlijnen, risico te minimaliseren en downtime te verminderen.

Schuif naar links en breng verandermanagement dichter bij de praktijk

Een van de meest voorkomende strategieën die vaak CAB-goedkeuringen vervangt of vermindert, is peer review. Daarbij wordt de verantwoordelijkheid voor het identificeren van problemen in de code overgeheveld naar degenen die de code het beste begrijpen. ITIL 4 wijst erop dat het in organisaties met een hoge snelheid "gebruikelijk [is] om de goedkeuring van wijzigingen te decentraliseren, waardoor de collegiale beoordeling een belangrijke voorspeller van hoge prestaties is". Evenzo adviseerde het State of DevOps-rapport 2019 dat "organisaties tijdens het ontwikkelingsproces 'naar links moeten opschuiven' naar goedkeuring op basis van peer reviews".

Om aan de regelgeving te blijven voldoen, moet deze aanpak zorgvuldig worden gedocumenteerd. Daar kunnen systemen zoals Bitbucket een rol spelen: ze houden automatisch auteurs en peer reviews bij en voorkomen dat wijzigingen live worden gepusht zonder dat het vereiste proces wordt gevolgd.

Peer review is bij Atlassian een belangrijk onderdeel van het goedkeuringsproces. Zoals een van onze experts op het gebied van IT-risico en compliance uitlegt: "Alle Atlassian-code wordt opgeslagen in Bitbucket. Wanneer een ontwikkelaar een wijziging wil aanbrengen, wordt de code uit Bitbucket en op zijn laptop gecontroleerd. Het systeem is zo geconfigureerd dat een peer review wordt vereist wanneer de code weer wordt teruggecheckt in de Bitbucket-repository in plaats van dat deze wordt bijgewerkt. Pas nadat die review is voltooid en goedgekeurd, wordt de code weer in de repository geplaatst. En als de code niet wordt goedgekeurd? Dan wordt deze teruggestuurd naar de oorspronkelijke ontwikkelaar met de aantekeningen van de beoordelaar. Die herstelt de fout en dient de code in voor een nieuwe peer review."

Deskundigen bijeenroepen om beproefde methoden mogelijk te maken

Naarmate organisaties complexer worden, wordt het faciliteren van de informatiestroom en coördinatie tussen teams steeds belangrijker. CAB's kunnen zich richten op verbetering in de praktijk in plaats van individuele wijzigingsverzoeken goed te keuren. In dit paradigma kunnen ze aanbevelingen voor praktische verbetering geven, betere capaciteiten implementeren en (hulp)middelen verstrekken die betere prestaties opleveren. Dit vergroot de bevoegdheid van de CAB om het risico van een te grote traagheid bij het leveren van waarde aan de markt aan te pakken.

Zelfs in meer traditionele IT-organisaties kan de CAB een plek worden voor het bedenken van creatieve oplossingen. Een risicomijdende universiteit die verouderde ITSM-tools en -methoden gebruikte, zocht een oplossing om studenten te informeren over een belangrijke service die niet beschikbaar zou zijn. De CAB werd een forum om te brainstormen over nieuwe communicatietactieken. Er werd gekozen voor het uitdelen van snoep en ophangen posters. Die campagne slaagde erin inkomende verzoeken over een geplande systeemupgrade af te buigen.

Verantwoordelijkheden toewijzen in de verandermanagementpraktijk van je organisatie

Als het gaat om het definiëren van rollen en verantwoordelijkheden in je verandermanagementpraktijk, moet je allereerst begrijpen dat er geen eenduidig antwoord is. Je moet rekening houden met de cultuur van je bedrijf, teamstructuren, beschikbare vaardigheden, wettelijke vereisten, etc.

Om echte steun te krijgen voor alle rollen en verantwoordelijkheden die je bedrijf nodig heeft, raden we ons "rollen en verantwoordelijkhedenspel" aan. Daarbij komt iedereen samen om te leren wat elk lid aan het team bijdraagt en wat iedereen nodig heeft om succesvol te zijn.

Om je rollen en verantwoordelijkheden in het kader van verandermanagement scherper te krijgen, raden we je aan om eerst met je team te vergaderen en de onderstaande vragen te bespreken.

  • Wat betekenen verschillende frameworks voor ons team? DevOps, CI/CD, ITIL, etc.
  • Hebben we frameworks holistisch omarmd? Is ons begrip beperkt tot tactische zaken als automatisering?
  • Hoe beïnvloeden deze frameworks, met name DevOps en ITIL, onze veranderings- en releasepraktijken en hoe werken ze samen?
  • Hoe ziet ons huidige veranderingsproces eruit?
    • Wie is erbij betrokken?
    • Waar kunnen we verbeteren?
    • Wat kunnen we doen om meer normale wijzigingen te verschuiven naar standaard of vooraf goedgekeurd?
      • Wat waren de meest voorkomende veranderingen?
      • Welke wijzigingen zijn "standaardwijzigingen"?
      • Op welke services hebben ze invloed?
      • Welke veranderingen waren succesvol?

Verandermanagement is een belangrijke methode, die niet snel zal verdwijnen. Hoe jouw werkwijzen voor verandermanagement er ook voor staan, er is altijd ruimte om te verbeteren. Of dat nou betekent dat je veranderingen gaat volgen of risicobeoordeling en automatiseringssystemen gaat implementeren. Ontdek hoe de mogelijkheden voor verandermanagement van Jira Service Management je IT-teams ondersteunt.