Een uitgebreide handleiding voor wijzigingsbeheer in ITIL®

Het ondernemingsklimaat en de verwachtingen van de klant veranderen voortdurend, en digitale transformatie is een belangrijke bijdrage geworden aan het succes van bedrijven in verschillende sectoren. Bij digitale transformatie gaat het allemaal om profiteren van beschikbare technologie voor het aanpakken van zakelijke uitdagingen en het grijpen van kansen. Wanneer u het analyseert, is digitale transformatie in feite een betere versie van IT-beheer voor het wegnemen van probleemgebieden en het uitrusten van uw IT-infrastructuur voor het onder ogen zien van zakelijke uitdagingen. En dit betreft het implementeren van IT-wijzigingen die uw organisatie helpen bij het toepassen van nieuwe technologie in bestaande bedrijfs- en IT-processen.

Deze wijzigingen kunnen zo eenvoudig zijn als het verplaatsen van collaboratieve apps naar de cloud voor betere operationele efficiëntie, of het nemen van een ‘mobile-first’-benadering voor een betere consumentenervaring. Ondanks hun eenvoud aan het oppervlak hebben deze wijzigingen hun eigen logistieke uitdagingen. Het niet goed implementeren van een wijziging kan ertoe leiden dat uw organisatie één stap vooruit en twee stappen terug zet.

De mislukte upgrade van een mobiele app van een populaire bank in december 2018 is een goed voorbeeld van hoe een wijziging niet te implementeren. Het plan van de bank om een nieuwe en verbeterde app voor mobiel bankieren te introduceren, was een goed idee en was ook hard nodig. Maar vanaf het moment dat de nieuwe app werd gelanceerd, had het problemen. De bank introduceerde de nieuwe app nadat het de oude al had opgeheven. Toen de nieuwe app niet werkte, hadden duizenden klanten geen toegang tot hun bankrekening via de app. En om het nog erger te maken, de communicatie over een correctie voor de nieuwe app was minimaal, waardoor klanten gefrustreerd raakten. De mobiele app was vier dagen buiten werking voordat de bank besloot om de oude app weer terug te brengen.

We kunnen zien dat de bank heeft gefaald in diverse fasen van de voorgestelde wijziging: de nieuwe app uitbrengen toen het niet klaar was om geïmplementeerd te worden, niet transparant zijn en niet met eindgebruikers communiceren van uitvaltijd verbonden aan de update, en geen alternatief plan naar voren brengen in geval van mislukking. Zeker niet de manier waarop u uw wijziging zou willen implementeren.

Dit is het moment dat wijzigingsbeheer naar voren komt; het helpt u bij het beheren van de verschillende wijzigingen in uw organisatie en het geeft u een proces voor het efficiënt implementeren van wijzigingen zonder dat dit van invloed is op de rest van uw organisatie. Wijzigingsbeheer reduceert de kans op verstoringen vergelijkbaar met waar de bank voor stond.

In deze handleiding behandelen we het wat, waarom en hoe van wijzigingsbeheer. U zult leren hoe uw organisatie te helpen om op de hoogte te blijven van trends in de sector met effectieve wijzigingen.

Laten we er meteen mee beginnen!

ITIL omschrijft wijzigingsbeheer als het proces van volgen en beheren van een wijziging gedurende de gehele levensduur, van start tot sluiting, met als doel om het risico te minimaliseren.

Het instellen van een systematisch proces van wijzigingsbeheer helpt uw organisatie bij het implementeren van wijzigingen zonder incidenten met een hoog succespercentage.

Volgens ITIL is een wijziging "de toevoeging, aanpassing of verwijdering van alles dat een direct of indirect effect kan hebben op services."

Eenvoudig gezegd wordt elke wijziging aan de IT-infrastructuur van een organisatie die van invloed kan zijn op de activiteiten van de organisatie, een IT-wijziging genoemd. Dit omvat het vervangen van printers, projectors, servers en meer.

Vad är skillnaden mellan en incident, ett problem och en förändring?

Waarom hebben organisaties wijzigingsbeheer nodig?

Nu we weten wat wijzigingsbeheer is, laten we dan nu eens kijken naar waarom organisaties het nodig hebben, te beginnen met de doelstellingen van wijzigingsbeheer.

Organisaties het vermogen geven om de controle te nemen en hun wijzigingen te beheren:

Wijzigingsbeheer geeft u een betere controle over uw wijzigingsproces en helpt u bij het implementeren van wijzigingen met een minimaal risico. Door het volgen van standaard processen, zorgt wijzigingsbeheer ervoor dat alle aspecten van elke wijziging, zoals planning, risicobeoordeling en volgen van de implementatie, effectief worden beheerd. Gebruik maken van een hulpprogramma van de servicedesk voor het volgen van wijzigingen van begin tot eind kan wonderen doen en het voor een organisatie mogelijk maken om haar IT-infrastructuur beter te beheren met goed geplande en uitgevoerde wijzigingen.

Organisaties helpen om wijzigingen beter te implementeren:

Door het volgen van het gehele wijzigingsproces, maakt wijzigingsbeheer het voor organisaties mogelijk om alle wijzigingsaanvragen de baas te blijven. Het maakt het ook gemakkelijker om het aantal onbevoegde wijzigingen te identificeren en te beperken. Door gebruikers toe te staan om alleen via het hulpprogramma van de servicedesk een wijzigingsaanvraag (RFC) in te dienen, kunnen organisaties direct aan het begin alle noodzakelijke informatie over de wijziging verzamelen en vervolgens besluiten of de wijziging moet worden geïmplementeerd. Een robuust goedkeuringsmechanisme zorgt ervoor dat wijzigingen alle noodzakelijke toestemmingen ontvangen voordat ze worden geïmplementeerd.

Voortdurende verbetering mogelijk maken:

Wijzigingsbeheer is niet slechts voor een regenachtige dag; het is erop gericht om organisaties te helpen met het voortdurend verbeteren van hun infrastructuur en processen, alsook het bijhouden van trends in de sector door ervoor te zorgen dat ze de noodzakelijke wijzigingen soepel kunnen implementeren zonder de huidige service-activiteiten te beïnvloeden.

Aan de organisatie:

• Minder wijzigingsconflicten dankzij effectief beheer van wijzigingen.
• Het vermogen om upgrades te implementeren zonder de bedrijfsactiviteiten te beïnvloeden.
• Minder mislukte wijzigingen.
• Nauwkeurige classificatie van wijzigingen.

Aan eindgebruikers:

• Betere communicatie over uitvaltijd en onbeschikbaarheid van services vanwege geplande wijzigingen.
• Soepelere service-activiteiten met minder verstoringen veroorzaakt door slecht geplande wijzigingen.

Laten we nu eens kijken hoe u wijzigingsbeheer kunt implementeren in uw organisatie. Het eerste is het instellen van een effectief wijzigingsproces waarmee u wijzigingen kunt plannen, de noodzakelijke goedkeuring kunt krijgen en wijzigingen kunt implementeren. Hier vindt u een proces van wijzigingsbeheer dat u kunt volgen voor het effectief omgaan met wijzigingen.

Stap 1: Indiening

De eerste fase is het initiëren van de wijziging, Dit betreft het verzamelen van basisinformatie over wijzigingstickets, zoals het soort wijziging en de prioriteit.

• Aanmaken: Wijzigingstickets worden geïnitieerd met het hulpprogramma van de servicedesk. De noodzakelijke informatie wordt direct aan het begin verzameld met gebruik van een wijzigingsformulier dat verplichte velden bevat.
• Wijzigingsrollen definiëren: Door het gebruik van wijzigingsrollen kunnen organisaties verantwoordelijkheden voor wijzigingen delegeren naar diverse belanghebbenden en het toegangsniveau controleren dat elke rol heeft voor elke fase van een wijziging.

Stap 2: Planning

De volgende fase is waar de planning van de gehele wijziging plaatsvindt. Een goed geplande wijziging is het geheim voor een succesvolle implementatie van de wijziging. Het is tevens van essentieel belang om de nodige goedkeuringen te krijgen die vereist zijn voor het implementeren van de wijziging. Details zoals de impact, implementatieplannen, herstelplannen en verbonden uitvaltijd worden gedocumenteerd voor het overbrengen van het wijzigingsplan aan belanghebbenden en om ze over te halen dat de wijziging de moeite waard is.

Stap 3: Goedkeuring

Daarna moet het plan worden goedgekeurd door de wijzigingsadviescommissie (CAB), adviescommissie voor spoedwijzigingen (ECAB), en enige andere autoriteit die een belang heeft in de wijziging of in de organisatorische infrastructuur die wordt beïnvloed door de wijziging. Het aanmaken van aangepaste CAB’s helpt organisaties bij het groeperen van relevant personeel voor het eenvoudig beheren van goedkeuringen. Het automatiseren van het goedkeuringsproces versnelt de gehele wijziging en zorgt ervoor dat geen goedkeuringsaanvragen over het hoofd worden gezien.

Opmerking: De CAB is een combinatie van diverse functierollen en teams. Het kan leidinggevenden op C-niveau, teammanagers, technische teams, financieel personeel en meer omvatten, afhankelijk van de ernst en schaal van de wijziging.

Stap 4: Implementatie

Wanneer de noodzakelijke goedkeuringen zijn verkregen, kan de wijziging worden geïmplementeerd. Organisaties kunnen de implementatie van wijzigingen volgen en beheren door het aanmaken van taken of met gebruik van een project.

• Delegatie van werk door middel van taken: Taken worden aangemaakt en toegewezen aan verschillende technici uit verschillende teams voor het eenvoudig beheren van het werk dat is gedaan door iedereen die is betrokken bij de implementatie van de wijziging. Bovenliggende en onderliggende taken kunnen worden gebruikt voor het instellen van taakafhankelijkheden en ervoor zorgen dat taken in een specifieke volgorde worden uitgevoerd en dat geen taken worden overgeslagen.
• Profiteren van projectbeheer: Organisaties kunnen projecten gebruiken voor het beheren van grootschalige wijzigingen, zoals het verplaatsen van de gehele infrastructuur van de organisatie naar de cloud. Projecten ondersteunen een groter toepassingsgebied en kunnen beter omgaan met een groter aantal taken, personen en mijlpalen. Een sterke integratie tussen wijzigingsbeheer en projectbeheer kan zeer gunstig zijn voor organisaties.

Stap 5: Controle

Vervolgens wordt er een controle na de implementatie uitgevoerd om ervoor te zorgen dat er geen afwijkingen zijn in de implementatie en dat enige problemen worden gecorrigeerd voordat de wijziging wordt gesloten.

Stap 6: Sluiting

Dit is de laatste stap in het proces van wijzigingsbeheer. De aard van de voltooide wijziging wordt geregistreerd als succesvol, mislukt of onvolledig. Het registeren van de juiste sluitingscodes maakt de metrieken van een organisatie veel nauwkeuriger en nuttiger.

Niet alle wijzigingen zijn gelijk, aangezien sommige andere vereisten hebben. Sommige wijzigingen moeten zo spoedig mogelijk worden geïmplementeerd, sommige hebben goedkeuring nodig van hogere managers van de organisatie, en sommige zijn gewoon normale wijzigingen die op wekelijkse basis worden geïmplementeerd.

Volgens ITIL kunnen wijzigingen globaal worden onderverdeeld in drie soorten: standaard, normale en spoedwijzigingen.

Standaard wijzigingen:

Dit zijn vooraf goedgekeurde wijzigingen die een lage impact hebben, welbekend en gedocumenteerd zijn. Standaard wijzigingen vereisen een risicobeoordeling en autorisatie wanneer ze voor de eerste keer worden geïmplementeerd, maar volgende implementaties kunnen plaatsvinden zonder deze voorzorgsmaatregelen zolang de wijziging niet is aangepast.
Bijvoorbeeld: Het inktpatroon van een printer vervangen

Normale wijzigingen:

Een normale wijziging moet het gehele wijzigingsproces volgen; het moet worden gepland, het risico moet worden beoordeeld en het moet worden geautoriseerd. Normale wijzigingen omvatten zowel kleine (lage tot gemiddelde impact en urgentie) als grote wijzigingen (hoge impact en urgentie). Alle wijzigingen die geen standaard of spoedwijzigingen zijn, moeten worden behandeld als normale wijzigingen en het wijzigingsproces naleven.

Spoedwijzigingen:

Spoedwijzigingen hebben een hoge impact en urgentie, waarbij versnelde beoordeling, goedkeuring en implementatie is vereist om de services zo spoedig mogelijk in werking te stellen. Aanpassingen aan componenten die van invloed zijn op bedrijfsactiviteiten, en daardoor uitvaltijd veroorzaken, worden behandeld als spoedwijzigingen.
Voorbeelden: Storing van primaire server, verstoring van datacenter, noodpatch voor kwetsbaarheid van de beveiliging

Eigenaar van wijziging:

De eigenaar van de wijziging is verantwoordelijk voor het gehele proces van wijzigingsbeheer, inclusief de verbetering. Aangezien zij verantwoordelijk zijn voor wijzigingsbeheer bij hun organisatie, zijn zij doorgaans hooggeplaatst.

Beheerder van wijziging:

De beheerder van de wijziging behandelt de implementatie van de wijziging en de activiteiten die daaraan zijn gerelateerd. Zij beheren tevens de CAB en de diverse betrokken teams en belanghebbenden, en coördineren met hen.

Initiator van wijziging:

De initiator van wijziging is degene die de wijziging initieert en de wijzigingsplannen, implementatieplannen en andere vereiste details toevoegt. Zij organiseren tevens het implementatieplan voor de wijziging. De initiator van een wijziging kan een technicus of een eindgebruiker zijn.

CAB:

De CAB is een verzameling van diverse leden uit verschillende teams en functies. Samen analyseren zij de voorgestelde wijziging en geven hun goedkeuring en aanbevelingen met betrekking tot de wijziging en de implementatie ervan.

Aanvullende rollen:

Sommige organisaties gebruiken aangepaste rollen naast deze vier hoofdrollen voor het delegeren van werk en het opsplitsen van verantwoordelijkheden. In staat zijn om aangepaste rollen te creëren, helpt u bij het afstemmen van uw wijzigingsbeheer op de behoeften van uw organisatie. Een paar veel gebruikte aanvullende rollen zijn:

• Goedkeurder van wijziging
• Uitvoerder van wijziging
• Beoordelaar van wijziging
• Planner van wijziging

Hier vindt u vier algemene uitdagingen die wijzigingsbeheer kunnen belemmeren.

1. Mislukte wijzigingen:

   Wijzigingen nemen een vrij grote hoeveelheid hulpmiddelen in beslag, aangezien veel tijd en onderzoek wordt gestoken in het plannen van wijzigingen. Een groot aantal mislukte wijzigingen kan snel duur worden als ze niet worden gecontroleerd. In het geval van infrastructurele wijzigingen kan een hoog mislukkingspercentage leiden tot grotere problemen tijdens de implementatie of tijdens het implementeren van herstelplannen. Vele mislukte wijzigingen is tevens een indicator van een slecht proces van wijzigingsbeheer.

   Bijvoorbeeld: Zylker plande om haar primaire netwerkinfrastructuur te upgraden, dus het bedrijf stelde een alternatief netwerk in met een derde netwerkaanbieder; het plande om de wijziging in een weekend te implementeren. Tijdens de implementatie ontving Zylker tickets over services die niet werken, wat verrassend was gezien het feit dat het bedrijf een alternatief netwerk had ingesteld. Wat bleek was dat de alternatieve netwerkaanbieder dat weekend ook gepland onderhoud uitvoerde, wat betekende dat zowel het primaire als het alternatieve netwerk van Zylker niet functioneerde, waardoor de services van Zylker onbeschikbaar waren. Aangezien de wijziging niet goed werd gepland, mislukte het uiteindelijk.

2. Onbevoegde wijzigingen:

   Onbevoegde wijzigingen zijn het gevolg van een glansloos goedkeuringsmechanisme en het niet opnemen van de juiste belanghebbenden in de goedkeuringsfase. Deze wijzigingen gaan voorbij aan de noodzakelijke toestemmingen en kunnen uiteindelijk worden geïmplementeerd als ze niet op tijd worden aangegeven. Onbevoegde wijzigingen kunnen leiden tot wijzigingen die uw organisatie niet hoeft te implementeren of waarvoor het niet klaar is. Het komt erop neer dat onbevoegde wijzigingen slecht en een onnodige kostenpost zijn.

3. Teveel spoedwijzigingen:

   Zoals eerder toegelicht, vereisen spoedwijzigingen versnelde goedkeuring zodat ze zo spoedig mogelijk kunnen worden geïmplementeerd. Teveel wijzigingen behandelen als spoedwijzigingen kan leiden tot vertragingen in het geval van een ernstige spoedwijziging die moet worden geïmplementeerd. Het is altijd goed om voorzichtig te zijn bij het classificeren van een wijziging als spoedwijziging.

   Opmerking: Het populaire verhaal van de jongen die waarschuwde voor de wolf is een goede analogie voor de reden waarom het behandelen van teveel wijzigingen als spoedwijzigingen een averechts effect kan hebben. In het geval van een werkelijk noodgeval, neemt uw organisatie de wijziging wellicht niet met de ernst die het vereist, en u hebt wellicht niet de vereiste hulpmiddelen om het noodgeval aan te pakken.

4. Wijzigingsconflicten:

   Slechte planning kan leiden tot wijzigingsconflicten. Een wijzigingsconflict is wanneer twee of meer wijzigingen per ongeluk worden gepland om tegelijkertijd te worden geïmplementeerd, waardoor de implementatie van elke afzonderlijke wijziging wordt verstoord. Gebruikmaken van een wijzigingsagenda om uw wijzigingen beter te plannen kan helpen bij het voorkomen van wijzigingsconflicten.

Hier vindt u de beste manieren om wijzigingsbeheer te benaderen.

1. 1. Identificeer de soorten wijzigingen:

   Niet alle wijzigingen zijn gelijk. Wijzigingen hebben verschillende prioriteit en verschillende vereisten, als toegelicht in het gedeelte over soorten wijzigingen. Daarom is het belangrijk om eerst de soorten wijzigingen te identificeren die uw organisatie zou kunnen uitvoeren, en vervolgens verschillende soorten wijzigingen aanmaken om ze effectief te implementeren.

2. Ontwerp processen voor verschillende soorten wijzigingen:

   Aangezien verschillende soorten wijzigingen hun eigen unieke vereisten hebben, moet u unieke processen ontwerpen om te voldoen aan die behoeften. Het gebruiken van hetzelfde wijzigingsproces voor alle soorten wijzigingen zal alleen maar leiden tot onnodige vertragingen en onvolledige implementaties van wijzigingen.

   Opmerking: U kunt verschillende workflows voor wijziging aanmaken voor elk van uw soorten wijzigingen.

3. Definieer belangrijke rollen en verantwoordelijkheden:

   Door het definiëren van rollen kan de beheerder van wijziging activiteiten en verantwoordelijkheden delegeren naar anderen. Rollen maken het gemakkelijker om wijzigingen te beheren, en ze definiëren duidelijk de activiteiten die elke persoon kan uitvoeren.

4. Registreer, beheer en prioriteer wijzigingsvoorstellen:

   Het is een beste werkwijze om een georganiseerde manier te hebben om uw wijzigingen te registreren, alsook om ze op één plek te beheren en prioriteren. Met een beter zicht op de wijzigingen van uw organisatie, kunt u prioriteren welke wijzigingen voorafgaand aan andere moeten worden uitgevoerd.

5. Verkrijg duidelijke inzichten in de risico’s en impact van wijzigingen:

   Alle wijzigingen moeten risico- en impactanalyse doorlopen voor een beter inzicht in de wijziging en om de nodige hulpmiddelen toe te wijzen. De risico- en impactdetails moeten worden toegevoegd aan de planningsfase zodat CAB een duidelijk beeld heeft van de wijziging en een aanbeveling kan doen.

6. Zorg voor een effectief goedkeuringsmechanisme:

   Het definiëren van het goedkeuringsproces maakt het gemakkelijk om de nodige toestemmingen te krijgen zodat een wijziging kan worden geïmplementeerd. Het zorgt ervoor dat alle belangrijke belanghebbenden zich bewust zijn van wijzigingen en hun aanbeveling geven voordat een wijziging wordt geïmplementeerd. Dit helpt bij het beperken van onbevoegde wijzigingen.

7. Communiceer planningen en uitvaltijd met belanghebbenden:

   Belanghebbenden geïnformeerd houden over geplande wijzigingen reduceert het aantal incidenten veroorzaakt door wijzigingen. Leveren van directe informatie zorgt er tevens voor dat geen services worden beïnvloed als gevolg van wijzigingen, en dat de wijziging effectief kan worden uitgevoerd. En als bonus: het management is tevens tevredener wanneer ze gedurende de gehele levenscyclus van de wijziging op de hoogte worden gehouden.

8. Meet de voortgang en effectiviteit van de implementaties van wijzigingen:

   Een wijziging in de gaten houden gedurende de gehele levenscyclus van de wijziging, zorgt ervoor dat er niets fout gaat en dat de wijziging wordt geïmplementeerd volgens het wijzigingsplan. Het meten van belangrijke metrieken geeft u een duidelijk beeld van hoe effectief uw wijzigingsproces is en het laat u tevens verbeterpunten identificeren.

9. Onderhoud rampenplannen:

   U bent nooit te goed voorbereid, dus het is altijd een goed idee om u voor te bereiden op het slechtst denkbare scenario en een herstelplan te bedenken gedurende de planningsfase van de wijziging. Deze diepgaande planning kan het verschil betekenen tussen een nietszeggende mislukte wijziging en onomkeerbare schade aan uw IT-infrastructuur.

10. Implementeer voortdurende serviceverbetering:

    Hoewel brandbestrijding een cruciale functie is van wijzigingsbeheer, hebben wijzigingen een breder toepassingsgebied in uw organisatie. Het gebruiken van wijzigingen voor het verbeteren van technologie en processen, en daarbij het voortdurend verbeteren van het vermogen van uw organisatie om betere services te leveren, wordt een belangrijke functie van wijzigingsbeheer.

Wijzigingsbeheer eindigt niet bij slechts het uitvoeren van een wijziging. Het vermogen van wijzigingsbeheer om wijzigingen effectief te implementeren kan in sterke mate profiteren van informatie die is verzameld in andere ITSM-processen, en vice versa. Het vermogen om incidenten te verbinden aan de wijzigingen die ze hebben veroorzaakt of waardoor ze werden veroorzaakt, of om de CMDB bij te werken gebaseerd op wijzigingen van IT-infrastructuur, is slechts het begin van het creëren van een heilzame ITSM-werkwijze die samenwerkt om te helpen uw organisatie beter te beheren.

Op de volgende manier kan wijzigingsbeheer samenwerken met uw andere ITSM-processen:

1. Incidentbeheer:

   Het volgen van de incidenten die een wijziging veroorzaken en de incidenten die worden veroorzaakt door een wijziging, geeft u een beter inzicht in de manier waarop wijzigingen van invloed zijn op uw organisatie. Wanneer bijvoorbeeld een router wordt bijgewerkt, zou u incidenttickets kunnen krijgen die melden dat het internet niet werkt. Verbinden van wijzigingen aan de incidenten die ze hebben veroorzaakt, helpt u bij het snel identificeren van de oorzaak van een incident en afstand doen van het moeten toewijzen van hulpmiddelen om dat specifieke incident te corrigeren, aangezien het wordt gecorrigeerd wanneer de wijziging is afgerond.

2. Behandeling van aanvragen:

   Het is belangrijk om wijzigingen te gebruiken voor serviceaanvragen met hoge impact om uw IT-infrastructuur geactualiseerd te houden. Zonder wijzigingen eindigt een service-aanvraag voor een serverupgrade of een aanvraag voor een upgrade van de Azure-opslagruimte met het leveren van de service. Maar wanneer u een wijziging gebruikt voor het implementeren van de service-aanvraag, kunt u meer informatie verzamelen, zoals de reden voor de wijziging en het implementatieplan, de noodzakelijke goedkeuringen krijgen van alle belanghebbenden, en de CMDB bijwerken met de nieuwe informatie.

   Opmerking: Het gebruiken van een wijziging voor aanvraagbehandeling werkt het beste voor service-aanvragen met hoge impact en enige service-aanvragen die een wijziging van de CMDB vereisen. Als het vereist dat de CMDB wordt bijgewerkt, dan heeft het een wijziging nodig!

3. Probleembeheer:

   Probleembeheer vereist het aanmaken van een wijziging voor het corrigeren van de hoofdoorzaak van een probleem. In staat zijn om een RFC direct vanuit een probleemticket aan te maken, maakt het gemakkelijker om verbonden wijzigingen en problemen te volgen. Het geeft de CAB tevens een beter beeld van waarom de wijziging nodig is, en geeft de ernst van het probleem aan dat de wijziging heeft geïnitieerd.

4. Release- en inzetbeheer:

   Release- en inzetupgrades profiteren van de gestructureerde benadering die wordt geboden door het wijzigingsproces. U kunt gemakkelijk de implementatieplannen en de feitelijke implementatie van release en inzet volgen met gebruik van wijzigingen. De transparantie en zichtbaarheid die wijzigingen bieden, helpt tevens om alle belanghebbenden geïnformeerd te houden.

5. CMDB:

   Enige updates van de CMDB moeten altijd worden uitgevoerd met een wijziging. Een wijziging biedt veel nuttige informatie over waarom, hoe en wanneer de update werd uitgevoerd. De impactanalyse die naast een wijziging wordt uitgevoerd, zorgt er ook voor dat alle updates van de CMDB goed worden geanalyseerd en dat de update niet zorgt voor verstoringen voor de rest van uw organisatie. U kunt soorten wijzigingen gebruiken voor het registreren van CMDB-updates van verschillende prioriteit.

Hier vindt u enkele belangrijke metrieken voor het meten van de effectiviteit van uw proces van wijzigingsbeheer.

Laten we eens gedetailleerd kijken hoe u uw proces van wijzigingsbeheer kunt verbeteren.

Zylker, een bedrijf met een groot aantal externe gebruikers, besluit om de cloud te gebruiken.

Momenteel zijn alle productiviteitstoepassingen en -hulpbronnen van het bedrijf intern, dus externe gebruikers krijgen VPN-toegang tot het netwerk. Om te zorgen voor een snellere toegang tot gegevens, besluit Zylker om te beginnen met het gebruik van cloud-toepassingen. Ze kiezen Zoho One voor de productiviteitssuite, en Office 365 voor e-mail. Een deel van de hulpbronnen van het bedrijf, zoals de bestandsservers en databases, bevinden zich nog op locatie, dus externe gebruikers moeten hier ook toegang tot krijgen.

Voor het bereiken van deze vereiste configureert het IT-team een hybride Azure Active Directory (AD)-omgeving. Zij voorzien een federation server voor het repliceren van hun AD op locatie in de Azure AD in de cloud. Nu hebben eindgebruikers, en zelfs externe gebruikers, toegang tot hulpbronnen in de cloud met hun AD-inloggegevens.

Stap 1: De RFC opwerpen

De eerste stap is het opwerpen van een wijzigingsticket en het verzamelen van de noodzakelijke informatie over de wijziging, zoals het soort wijziging, de impact van de wijziging en de urgentie, en het instellen van de wijzigingsrollen. De initiator van de wijziging kan gemakkelijk een ticket opwerpen met gebruik van zijn./haar webportal en het relevante wijzigingssjabloon en soort wijziging kiezen. Het wijzigingssjabloon verzamelt alle noodzakelijke informatie met gebruik van verplichte velden. Hier stelt de initiator van de wijziging het soort wijziging in als normaal, selecteert het aangewezen wijzigingssjabloon, wijst de wijzigingsrollen toe en geeft een omschrijving van de reden dat de wijziging vereist is.

Stap 2: De wijziging plannen

Vervolgens voegt de initiator van de wijziging de wijzigingsinformatie toe, zoals de reden voor de wijziging, gedetailleerde informatie over de impact, implementatie- en herstelplannen, en geplande uitvaltijd. De initiator van de wijziging voegt tevens alle verbonden incidenten en problemen toe om de wijziging en de impact ervan beter te volgen. Hieronder staan de diverse plannen die de initiator van de wijziging heeft bedacht.

Implementatieplan:

• Zorg voor Azure AD- en Office 365-accounts
• Configureer Active Directory Federation Services (ADFS)
• Start synchronisatie tussen AD op locatie en Azure AD
• Configureer eenmalige aanmelding
• Synchroniseer Exchange op locatie met Office 365

Herstelplan:

Aangezien de bestaande configuratie intact is, keert u terug naar de oude configuratie en hervat u de services.

Geplande uitvaltijd: 12 uur

Stap 3: De juiste goedkeuringen verkrijgen

De beheerder van de wijziging stelt CAB’s in voor het controleren van het wijzigingsplan en doen van hun aanbeveling of de wijziging moet worden geïmplementeerd of dat het plan moet worden aangepast. Aangezien dit een grootschalige wijziging is, zijn goedkeuringen vereist van diverse rollen over verschillende functies. Hier vindt u een lijst met CAB’s en leden die betrokken zijn bij het goedkeuringsproces:

1. Leidinggevende CAB:
   • Chief information officer (CIO)
   • Chief technology officer (CTO)
   • Chief financial officer (CFO)
   • Chief executive officer (CEO)
2. Technische CAB:
   • Service Delivery Manager
   • Operationeel directeur
   • Informatiebeveiligingsmanager
   • Functionaris voor gegevensbescherming
3. Zakelijke CAB:
   • Manager Bedrijfsadministratie
   • Manager Personeelszaken
   • Manager Handelsrelaties

Stap 4: De wijziging op de juiste manier implementeren

Zylker maakt gebruik van taken voor het volgen van de implementatie. Taken worden toegewezen aan verschillende technici, en de volgorde waarin ze moeten worden uitgevoerd, wordt gedefinieerd met gebruik van taakafhankelijkheden. De eigenaar van de wijziging kan de voortgang van de implementatie van de wijziging eenvoudig volgen en taken beheren, allemaal op één plaats.

Hier ziet u hoe Zylker de implementatie opsplitste in taken om het gemakkelijk te maken om de implementatie van de wijziging te volgen en te beheren:

• Office 365 en Azure AD voorbereiden
• Een ingest server instellen
• Gegevensmigratie initiëren
• Azure AD-proxy’s configureren
• De gegevensintegriteit controleren

Stap 5: Blijven bij het plan

Vervolgens wordt de implementatie van de wijziging gecontroleerd door de eigenaar/beheerder van de wijziging om te controleren op enige afwijkingen van het plan. Alle afwijkingen worden gemeld en gecorrigeerd voordat de wijziging succesvol wordt geacht.

Stap 6: Het wijzigingsticket sluiten

Tenslotte wordt de wijziging gesloten en een sluitingscode wordt toegewezen gebaseerd op de aard van de sluiting van de wijziging.

Stap 7: Metrieken verzamelen

De beheerder van de wijziging meet bepaalde KPI’s om vast te stellen hoe efficiënt het wijzigingsproces is en voor het identificeren van verbeterpunten.

Hier vindt u een lijst met functies die u in de gaten moet houden bij het kiezen van een hulpprogramma van de servicedesk. Het hebben van deze functies zal u helpen bij het implementeren van een effectief proces van wijzigingsbeheer in uw organisatie.

Wijzigingsbeheer

Aanmaken en registreren van wijziging

• Maak wijzigingen aan uit incidenten en problemen, en draag de noodzakelijke informatie over.
• Verzamel vereiste informatie met aangepaste wijzigingssjablonen.
• Maak verschillende soorten wijzigingen aan, en maak unieke workflows voor elke soort.
• Betrek de juiste belanghebbenden, zoals de eigenaar van de wijziging, goedkeurder, lijnmanager en beoordelaar van de wijziging, met gebruik van wijzingsrollen.

Planning en evaluatie van wijziging

• Maak uitgebreide wijzigingsplannen met impactanalyse en implementatie, herstel- en plannen voor uitvaltijd.
• Houd een checklist bij van essentiële stappen om uit te voeren.

Goedkeuring van wijziging

• Vorm meerdere CAB's.
• Configureer meerdere goedkeuringsniveaus. Markeer of de RFC moet worden goedgekeurd door alle leden van de CAB pof door een willekeurig lid.
• Geef de beheerder van de wijziging het laatste woord betreffende de goedkeuring van de wijziging.
• Ga voorbij aan goedkeuringen van de beheerder van de wijziging en goedkeurder van de wijziging door het automatisch goedkeuren van de wijziging wanneer alle CAB-leden dit aanbevelen.
• Markeer eindgebruikers als goedkeurders van service-aanvragen.

Implementatie van wijziging coördineren

• Splits wijzigingen op in taken, en gebruik werklogboeken om in te schatten hoe lang het team voor implementatie van de wijziging nodig zal hebben om de activiteiten af te ronden.
• Stroomlijn de implementatie door het aanmaken van projecten uit een wijziging of het koppelen van een wijziging aan bestaande projecten.
• Volg alle verbonden incidenten en problemen die de wijziging hebben veroorzaakt of die werden veroorzaakt door de wijziging.
• Plan uitvaltijd en kondig het aan belangrijke belanghebbenden aan.
• Houd belanghebbenden op de hoogte met regelmatige kennisgevingen.

Controle en sluiting van wijziging

• Documenteer controle na de implementatie: (PIR).

Workflows voor wijzigingen

• Maak onderscheidende workflows aan voor verschillende soorten wijzigingen en processen met verschillende mate van complexiteit en functies.
• Configureer diverse acties zoals voorwaarden, schakelingen, kennisgevingen, veldupdates en goedkeuringen tijdens de overgang tussen fasen.
• Teken workflows voor wijzigingen op een doek dat kan worden gesleept en neergezet.

Wijziging:

De toevoeging, aanpassing of verwijdering van alles dat een direct of indirect effect kan hebben op services.

Wijzigingsadviescommissie (CAB):

Een team van diverse belanghebbenden die aanbevelingen doen over de wijziging en het wijzigingsplan goedkeuren.

Wijzigingsconflict:

Wanneer twee of meer wijzigingen per ongeluk worden gepland om tegelijkertijd te worden geïmplementeerd, waardoor de implementatie van elke afzonderlijke wijziging wordt verstoord.

Wijzigingsbeheer:

Het proces van tot voltooiing brengen van wijzigingen met minimale verstoringen en conflicten.

Rollen wijzigen:

De delegatie van verantwoordelijkheid over de diverse aspecten van de wijziging naar verschillende leden van de organisatie.

Sluitingscode:

Gebruikt voor het registreren van de aard van de sluiting van de wijziging, zoals mislukt of geslaagd.

Database van configuratiebeheer (CMDB):

Een repository van alle configuratie-items en hun relaties.

Voortdurende serviceverbetering:

Het proces van identificeren en corrigeren van punten die kunnen worden verbeterd om services beter te maken.

Uitvaltijd:

De tijdsperiode waarin een specifieke service niet beschikbaar is.

Incident:

Een ongeplande onderbreking van een IT-service, of een reductie van de kwaliteit van een IT-service. Storing van een configuratie-item, zelfs als het de service nog niet heeft beïnvloed, is ook een incident (bijv. storing van één schijf van een spiegelset).

Probleem:

Een oorzaak of potentiële oorzaak van een of meerdere incidenten.

Controle na de implementatie:

Het proces van evalueren of het wijzigingsplan werd gevolgd zonder afwijkingen, alsook het inspecteren van de implementatie om te kijken of er iets moet worden gewijzigd.

Wijzigingsaanvraag (RFC):

Het proces van initiëren van een wijziging met een geldige reden.

Risicobeoordeling:

Het proces van het evalueren van de potentiële risico’s die gepaard gaan met een wijziging.

Servicedesk:

Het punt van communicatie tussen serviceproviders en de gebruikers van de organisatie.