De 10 belangrijkste best practices voor verandermanagement

Als het gaat om het balanceren van risico en snelheid, is er in verandermanagement geen pasklare oplossing. Elke organisatie heeft zijn eigen cultuur, risicotolerantie en wettelijke vereisten. Daar moet je rekening mee houden in jke verandermanagementpraktijk.

Om risico's te begrijpen, moet je inzicht hebben in de wettelijke verplichtingen en nalevingsverplichtingen van je bedrijf. Wanneer regelgeving in beeld komt, is het niet langer de vraag hoeveel downtime je systeem kan riskeren voordat je opdrachten kwijtraakt of welke middelen het kost om een probleem op te lossen. Het gaat namelijk om een reeks regels waarover niet te onderhandelen valt. Er zijn bepaalde goedkeuringen vereist. Je zult taken scheiden. Regelgeving zoals SOX en GDPR maakt bepaalde activiteiten niet onderhandelbaar, zelfs als ze het proces een beetje vertragen.

Het goede nieuws is dat deze planning niet statisch hoeft te zijn. Bedrijven die kiezen voor een conservatieve aanpak met meer goedkeuringen en rigide workflows, kunnen in de loop van de tijd altijd opnieuw evalueren en dan de strengheid in hun processen aanpassen aan het risiconiveau.

Met Jira Service Management kunnen goedkeuringen en workflows worden aangepast aan de specificaties van een organisatie. Maak processen zo flexibel of geautomatiseerd als je wilt. Automatiseer bijvoorbeeld processen met een laag risico en beveilig meer complexe processen met goedkeuringen.

Het bijhouden van statistieken, met name verbanden tussen wijzigingen en incidenten, vormt een belangrijke basis voor het verbeteren van je veranderingspraktijken. Gegevens zullen trends laten zien voor de soorten wijzigingsbeheer, teamleden en services die het minst waarschijnlijk bij een incident betrokken zijn. Die informatie kan je helpen bij het afstemmen van striktheid en risico's voor verschillende wijzigingsverzoeken.

Dankzij slimme risicobeoordeling kunnen meer wijzigingsverzoeken vaak worden gedegradeerd naar minder rigoureuze goedkeuringsworkflows. Zoals het adaptieve verandermanagementproces van Gartner suggereert, kunnen organisaties ernaar streven om steeds meer normale wijzigingen als "standaard" te classificeren –om ze vervolgens vooraf goed te keuren en te automatiseren.

Hieronder staan enkele praktische stappen om van standaardwijzigingen het nieuwe normaal te maken.

1. Bekijk je wijzigingen in de afgelopen maanden
   • Wat waren de meest voorkomende veranderingen?
   • Welke wijzigingen zijn "standaardwijzigingen"?
   • Op welke services hebben ze invloed?
   • Welke veranderingen waren succesvol?
   • Wat was de gemiddelde tijd om deze wijzigingen door te voeren?
   • Welke wijzigingen werden aangevraagd door ontwikkelingsteams?
2. Selecteer drie tot vijf standaardwijzigingen als kandidaten voor automatisering
3. Bouw soorten zelfhulpverzoeken voor de standaardwijzigingen in je servicemanagementsoftware
   • Voeg tekst toe om het doel en de omvang van het standaard wijzigingsverzoek te verduidelijken
   • Leg belangrijke velden vast, zoals het systeem, de toepassing of de service die wordt gewijzigd
   • Maak automatiseringsregels om de wijziging en overgangsstatussen automatisch goed te keuren, en personeel op de hoogte te stellen van updates
4. Neem de tijd om je IT-medewerkers en ontwikkelingsteams voor te lichten en op te leiden over deze nieuwe mogelijkheden
5. Bewaak de prestaties in de komende maanden
   • Verzamel inzichten om je bestaande aanbod te verbeteren
   • Identificeer aanvullende standaardwijzigingen die je kunt automatiseren

Nadat je de eerdere werkwijzen voor verandermanagement van je team hebt geëvalueerd en het veranderrisico hebt beoordeeld, kan het handig zijn om de documentatie van de risicobeoordeling op één plek te bewaren. Met de Confluence-integratie in Jira Service Management kunnen teams verwijzen naar één bron van waarheid die is ondergebracht in een veranderplandocument. Op deze pagina kunnen bijdragers een sjabloon voor veranderplannen toevoegen, naast risicobeoordelingsinformatie.

Niemand wil extra werk. En daarom wordt verandermanagement vaak als hinderlijk beschouwd. Verandermanagement vraagt mensen vaak om iets te documenteren, vaak in een tool waar ze niet graag in werken, en te wachten op een proces met een aantal extra stappen. Voor ontwikkelaars die code live moeten pushen, kunnen die extra taken aanvoelen alsof ze het echte werk in de weg staan. En hierbij kan een centrale bron van waarheid, zoals een Confluence-pagina met een veranderplan, documenteren eenvoudig maken door het hele team erbij te betrekken.

Het antwoord op deze grote uitdaging is om verandermanagementprocessen zo eenvoudig mogelijk te maken. Beperk goedkeuringen zoveel mogelijk tot een minimum. Kies technische tools die naadloos integreren, zodat ontwikkelaars niet dezelfde informatie in meerdere systemen hoeven in te voeren. En automatiseer waar mogelijk. Deze functies binnen Jira Service Management geven teams de flexibiliteit om op hun eigen tempo en op hun eigen manier te werk te gaan.

Hoe eenvoudiger je het proces kunt maken, hoe gemakkelijker het is om teams aan boord te krijgen en te houden.

In de meeste traditionele IT-organisaties moet een wijzigingsadviesraad (CAB) de technische en zakelijke implicaties van wijzigingsverzoeken beoordelen. Het traditionele proces brengt enkele uitdagingen met zich mee: langzame releases, onhandige processen en soms een gebrek aan communicatie en samenwerking. Daarom houden de best presterende teams het CAB-model nog eens tegen het licht.

Het doel is om de toegevoegde waarde van deze raden aan onze IT-processen te behouden: ze maken communicatie mogelijk en brengen de noodzaak van veranderingen in evenwicht met de risico's van die veranderingen. Tegelijk wordt het gebruikelijke CAB-proces wendbaarder en strategischer. Dit betekent meestal:

• Er wordt alleen om goedkeuring van de CAB gevraagd voor de meest risicovolle wijzigingen (en er worden bewezen tools gebruikt, zoals peer review, virtuele checklists en automatisering om minder risicovolle wijzigingen te beheren)
  
• CAB's worden belast met strategie en teams worden geholpen bij het ontwikkelen van methoden die risico's en de werklast van verandermanagement verminderen dankzij procesefficiëntie en automatisering
  
• CAB's worden virtueel en realtime gemaakt, zodat er niet hoeft te worden gewacht op fysieke vergaderingen om grote veranderingen aan te pakken of vragen te verwerken

De sleutel hierbij is een verschuiving naar strategie. De nieuwe CAB treedt niet meer op als poortwachter, maar maakt verandering mogelijk. Een CAB is dus geen knelpunt meer, maar een strategische hulpbron. Codebeoordeling en technische diepzinnigheden worden voorbehouden voor peer reviews en mensen die het meest geschikt zijn om fouten in de code op te sporen. De CAB wordt op zijn beurt vrijgemaakt om zich te concentreren op proces, strategie en ondersteuning van continue levering.

Van oudsher werden releases gebundeld en allemaal tegelijk gelanceerd. Wat de meesten van ons nu weten, is dat deze aanpak zich leent voor grote incidenten en het moeilijker maakt om de oorzaak van een probleem te vinden wanneer er zich een voordoet. Kleinere, frequentere releases kunnen de omvang van een mogelijk incident beperken. Progressieve implementaties bieden een kleine subgroep van gebruikers de mogelijkheid om de stabiliteit te testen en bewijzen voordat de volledige implementatie wordt uitgevoerd.

Door kleinere, gecontroleerde releases te plannen, is het voor teams eenvoudiger deze releases te coördineren op een veranderplanning. Dit helpt ontwikkelaars conflictgebieden te vermijden en piekdatums te identificeren. De functies voor verandermanagement van Jira Service Management geven teams toegang tot een gecentraliseerd schema met alle informatie die ze nodig hebben om deze gefragmenteerde releases uit te brengen.

ITIL heeft soms een slechte reputatie. De richtlijnen worden beperkend en verouderd gevonden. Maar ITIL heeft IT-teams veel te bieden. Oók degenen die een DevOps-cultuur hebben omarmd. En het probleem hier is niet dat ITIL te rigide is. Het heeft te maken met hoe we de richtlijnen benaderen.

Wanneer je ITIL als een reeks harde en snelle regels benadert, zal de richtlijn beperkend aanvoelen. Benader je hem als een reeks fundamentele richtlijnen waarop je bedrijf kan bouwen, dan zal hij aanvoelen als een voorsprong bij het ontwikkelen van je verandermanagementpraktijk.

Dit geldt voor elk framework en elke culturele benadering. ITIL, lean, DevOps, Agile, CD... geen enkel framework, hoe geliefd ook, zal al je problemen in één klap oplossen. Te vaak kijken we naar een framework of tool om interne problemen op te lossen terwijl we naar de teamcultuur zouden moeten kijken.

Of het nu gaat om CAB's of DevOps-groepen: toonaangevende teams omarmen samenwerking, openheid en realtime updates. Verandermanagement bestaat om teams te coördineren. Veranderingen, incidenten en problemen veroorzaken golven in meer dan één team. Dat merk je naarmate je organisatie complexer wordt.

Goed verandermanagement kan gewoon niet op eilandjes. Organisaties die meer open samenwerking aanmoedigen, zullen waarschijnlijk hun veranderingspraktijk verbeteren.

Heel Jira Service Management is gericht op teams samenbrengen om sneller doelen te behalen, in dit geval om veranderingen sneller en zonder incidenten door te voeren. Het achterliggende mechanisme van samenhangende, snel bewegende teams is samenwerking. Met een transparant platform met tools zoals Confluence, geïntegreerd chatten en videovergaderen en aanpasbare workflows kan iedereen meedoen en hun deel leveren, op hun eigen manier, met volledige context.

"Chaos engineering" heeft pas recent opgeld gedaan. De methode is gericht op het testen van veerkracht door componenten van een product of service af te breken of uit te schakelen. De veerkrachttechniek pakt op zijn beurt opzettelijk alle mogelijke stressoren op een systeem aan, bijvoorbeeld door de grenzen van het systeem op te zoeken met een hoog aantal gebruikers of veel verkeer.

Beide praktijken zijn bedoeld om problemen in kaart te brengen, evenals de veranderingen die nodig zijn om toekomstige incidenten te voorkomen. Deze preventieve aanpak biedt veel voor verandermanagementteams en scheelt incidentmanagementteams aanzienlijk veel tijd, budget en alarmmoeheid.

Goede verandermanagementprocessen moeten worden ingebouwd in en tussen alle tools die je ontwikkelaars gebruiken. Als je teams moet vragen om een nieuwe tool te leren, informatie in te voeren in meerdere tools of onbekende en ongemakkelijke tools te gebruiken, vertraag je de acceptatie. Dat schaadt je vermogen om waardevolle updates aan klanten te leveren.

Bij Atlassian volgen we wijzigingen met behulp van Jira Service Management. Op het Jira-platform kun je gemakkelijk dev- en ops-teams samenbrengen. Daarbij bied je transparantie en traceerbare context –vanaf het moment vóórdat ontwikkelaars zelfs maar beginnen met coderen tot het moment waarop wijzigingen in productie worden geïmplementeerd.