De bedrijfswereld is berucht om het gebruik van verwarrende modewoorden en industriejargon. Dit is het geval als het gaat om het onderscheid tussen Standard Change en Normal Change.
Het is geen verrassing dat veel mensen zich afvragen: “Wat is het verschil tussen normal en standard change?” Dit is vooral waar gezien het feit dat standard en normal synoniemen zijn die onder de meeste omstandigheden relatief uitwisselbaar zijn.
Voordat we verder in het konijnenhol van change duiken, laten we ervoor zorgen dat we op één lijn zitten over wat we in de eerste plaats bedoelen als we “change” zeggen.
Download nu: ITIL 4 Best Practice e-Books
Deze geheel nieuwe ITIL-e-boeken voor 2020 belichten belangrijke elementen van ITIL 4 best practices.
Wat is change?
In de context van de IT-bedrijfswereld en meer in het bijzonder de wereld van ITIL-beheer, verwijst change naar wijzigingen in de softwaretoepassingen van de organisatie, of het nu gaat om interne toepassingen of om producten die op de klant zijn gericht. Change in deze context omvat updates van bestaande code en systemen die worden getest en geïmplementeerd in live omgevingen.
Dit proces van change management wordt afgehandeld door de Change Manager en Change Advisory Boards (CAB’s). De CAB behandelt over het algemeen twee hoofdtypen wijzigingen waarover zij informatie verzamelen voordat zij het definitieve groene licht geven voor implementatie:
- Standaard wijziging
- Normale wijziging
Deze specifieke definities en benamingen kunnen van organisatie tot organisatie verschillen, afhankelijk van hun behoeften, maar er zijn enkele algemene regels waaronder zij over het algemeen werken. Laten we beginnen deze processen te onderzoeken door een standaardwijziging te bekijken.
(Spoedwijzigingen, die we later zullen bespreken, zijn wijzigingen die dringender en gevoeliger zijn en worden behandeld door de Emergency Change Advisory Board of ECAB, die meestal een subgroep is van de CAB.)
Wat is een standaardwijziging?
Standaardwijzigingen, soms routinematige wijzigingen genoemd, zijn meestal vooraf geautoriseerde wijzigingen waaraan weinig tot geen risico’s verbonden worden geacht. Ze komen vrij vaak voor en hebben specifieke richtlijnen en procedures die ze volgen. Standaardwijzigingen worden vaak uitgevoerd met herhaalbare stappen die zelden wijzigingen vereisen. De CAB beoordeelt gewoonlijk niet elk geval van een standaardwijziging en stelt in plaats daarvan een protocol op en geeft een overzicht van de richtlijnen voor het doorvoeren van standaardwijzigingen.
Standaardwijzigingen zijn vaak gebieden waar automatisering kan worden toegepast om het proces te versnellen en de efficiëntie te verhogen. Deze wijzigingen zijn verfijnd tot een nette, geordende systematische aanpak die op betrouwbare wijze tot succes leidt. Het automatiseren van aspecten van deze Standard changes kan de tijd die aan het proces wordt verspild drastisch verminderen en manuren vrijmaken voor werk dat een beetje menselijk vernuft vereist.
ITIL change management definieert Standard Change als:
“Een vooraf geautoriseerde change die weinig risico’s met zich meebrengt, relatief vaak voorkomt en een procedure of werkinstructie volgt”.
Beschouw standaard als de diensten die IT aan haar eindgebruikers biedt. Diensten zoals:
- Lifecycle replacement van hardware
- Software patching en updates
- Firewall changes
- Nieuwe DNS entries
Dit zijn allemaal voorbeelden van vooraf geautoriseerde taken die IT direct kan uitvoeren zodra een wijzigingsverzoek of -vereiste zich voordoet. Na de autorisatie van dergelijke wijzigingen is een minimale planning nodig om een wijzigingsverzoek uit te voeren. Deze veranderingen komen meestal voort uit serviceverzoeken van eindgebruikers en zijn van tevoren goed voorzien, niet noodzakelijkerwijs in termen van een specifiek tijdsbestek.
Standaard veranderingen kunnen ook operationele veranderingen omvatten die een specifiek schema volgen, zoals verversingscycli van printers, werkstations en netwerkapparatuur.
De procedure voor het doorvoeren van veranderingen is rechttoe rechtaan en leidt zelden tot problemen of risico’s. Een grondige risicobeoordelingsprocedure wordt uitgevoerd voordat standaardwijzigingen worden geautoriseerd. Alleen bij een bedrijfswijziging of een IT-incident moeten de risico’s van standaardwijzigingen opnieuw worden beoordeeld.
Het wordt beschreven als een standaardwijziging omdat de goedkeuring en pre-autorisatie ter beoordeling staat van de organisatie of de dienstverlener. De procedure voor het doorvoeren van wijzigingen is goed gedocumenteerd. De bijbehorende risico’s worden ruim van tevoren berekend en verantwoord. De nodige risicobeperkende maatregelen worden genomen als onderdeel van de veranderingsimplementatieprocedure. Zodra het change request is ontvangen, is geen aanvullende goedkeuring meer nodig van de beslissers of de Change Advisory Board (CAB).
Het hebben van een IT service request als een Standard Change heeft zijn voordelen vanuit een IT Service Management (ITSM) perspectief. Het change-proces verloopt met minimale wrijving, vooral wanneer informatie- en afdelingssilo’s kunnen leiden tot onnodige vertragingen en beperkingen in de implementatie van de change. Als de pre-autorisatie, gedocumenteerde implementatieprocedure en uitgebreide risicobeoordeling al op hun plaats zijn, kan IT de gevraagde service efficiënt en effectief leveren, wat precies het doel is van het ITIL-raamwerk dat geassocieerd wordt met change management.
Er kunnen momenten zijn waarop de CAB ingrijpt en zich realiseert dat er items moeten worden toegevoegd aan of verwijderd uit de lijst met Standard changes die zeer weinig toezicht vereisen. Over het algemeen verloopt een Standard change zonder problemen tijdens een gepland onderhoudsvenster en heeft het weinig of geen impact op de live services. Dit staat in direct contrast met Emergency changes, die direct toezicht en zorgvuldige overweging vereisen.
Wat is een emergency change?
Emergency changes zijn in feite precies het tegenovergestelde van Standard changes. ITIL definieert een spoedwijziging als:
“Een wijziging die zo snel mogelijk moet worden ingevoerd”.
Voorbeelden van Emergency Change zijn:
- Het implementeren van een beveiligingspatch voor een zero-day exploit
- Het netwerk isoleren van een grootschalige Distributed Denial of Service (DDoS)-aanval
Deze veranderingen vertegenwoordigen typisch een crisis of een kans die moet worden aangepakt zonder onnodige risico’s. Daarom wordt een aanvaardbaar risiconiveau verwacht en worden specifieke procedures gevolgd als risicobeperkingsstrategie. Specifieke goedkeuringen en autorisaties zijn ook vereist voordat een Emergency Change wordt geïmplementeerd.
Dit betekent geen langdurige vergaderingen tussen CAB-leden, maar een toezicht op hoog niveau over het change management proces. In elke fase van het veranderingsproces moeten alle belanghebbenden snel actie ondernemen. Het resultaat is dat de Emergency Changes niet grondig worden getest en dat de juiste beslissingen worden genomen als een evenwichtige afweging tussen risico en beloning.
De wendbaarheid van de organisatie bepaalt hoe goed zij Emergency Changes kan beheren. Het volgt een gelijksoortige change management procesflow als Normal Changes, maar met een versnelde tijdschaal volgens de ITIL-richtlijnen. De succesvolle afhandeling van een Emergency Change bepaalt de stabiliteit van de IT-dienstverlening aan eindgebruikers. Daarom moet de impact van een Emergency Change worden gedocumenteerd en geëvalueerd voor toekomstige verbeteringen in het change management proces.
U moet ook een herstel- of back-out proces opnemen in de Emergency Change management protocollen. Dit is zodat u de oorspronkelijke staat kunt herstellen wanneer de implementatie van de verandering extra risico’s en problemen met zich meebrengt.
Ze komen niet op de verwachte tijdstippen en zijn allesbehalve alledaags. Noodwijzigingen worden doorgevoerd als reactie op onvoorziene obstakels zoals beveiligingslekken en exploits. Noodwijzigingen worden onmiddellijk onder de aandacht gebracht van een Change Manager en vervolgens doorgestuurd naar de ECAB voor verdere analyse. Het is de taak van de ECAB om het risico van de voorgestelde noodwijzigingen te beoordelen en het gevaar af te wegen dat het onderliggende probleem vormt voor de organisatie en haar diensten.
De ECAB probeert een snelle maar effectieve oplossing te vinden voor het nieuw ontdekte probleem en werkt met een strakke deadline die geen ruimte laat voor de typische bureaucratie van de meeste veranderingsoperaties. Informatie moet snel worden verzameld en geanalyseerd om te beslissen wat de beste manier is om het probleem op te lossen. Wijzigingen in noodgevallen worden snel getest en indien nodig onmiddellijk doorgevoerd. Het doel van noodwijzigingen is om zo weinig mogelijk impact te hebben op live services en het bloeden zo snel mogelijk te stoppen.
Wat overblijft ergens in het midden tussen Emergency change en Standard change is Normal change.
Wat is een normale change?
De meeste organisaties definiëren Normal changes als elke change die NIET een Emergency change of Standard change is. Normale wijzigingen zijn niet vooraf geautoriseerd zoals standaardwijzigingen, maar ze hebben ook niet de striktere tijdlijn en het meer wildwestkarakter van spoedwijzigingen die vrij moeten zijn van bureaucratie en beperkende richtlijnen. Normale wijzigingen doorlopen het CAB-proces voor elke wijziging die wordt aangebracht.
Dit maakt toezicht op de wijzigingen mogelijk en biedt de CAB de gelegenheid om te beoordelen of deze Normale wijziging met een zodanige frequentie voorkomt dat er herhaalbare richtlijnen aan kunnen worden gegeven die de wijziging in een Standaardwijziging zouden kunnen omzetten. Elke Normal change wordt verwerkt als een Request for Change (RFC), die aan de CAB wordt voorgelegd en uiteindelijk door de Change Manager wordt goedgekeurd of afgewezen.
Normal changes komen vrij vaak voor, maar vereisen doorgaans een enigszins unieke of nieuwe aanpak, in tegenstelling tot Standard changes, die doorgaans kunnen worden uitgevoerd met behulp van stapsgewijze handleidingen of enkele basisrichtlijnen. Normale wijzigingen ondergaan een zelfevaluatie waarbij het team de wijziging analyseert binnen het toepassingsgebied van de opdracht en de levensvatbaarheid ervan beoordeelt alvorens ze aan de CAB voor te leggen. De CAB neemt vervolgens de voorgestelde wijziging door en zorgt ervoor dat deze voldoet aan compliance en alle beveiligingsprotocollen voordat deze uiteindelijk aan de Change Manager wordt overhandigd voor definitieve goedkeuring.
ITIL definieert Normal Change als:
“Een wijziging die geen emergency change of een standaard wijziging is. Normale wijzigingen volgen de gedefinieerde stappen van het change management proces”.
Dit zijn de wijzigingen die moeten worden geëvalueerd, geautoriseerd en vervolgens gepland volgens een gestandaardiseerd proces. Deze veranderingen worden van tevoren voorzien en gepland en passende gestandaardiseerde controles voor wijzigingsbeheer kunnen dienovereenkomstig worden ontworpen. De Normal Change wordt echter pas uitgevoerd nadat formele autorisatie en goedkeuring is ontvangen. Voor wijzigingen met een laag risico kan de goedkeuring van lokale IT-teams vereist zijn, terwijl voor wijzigingen met een hoog risico de goedkeuring van de CAB of van hogere bedrijfs- en IT-managers vereist kan zijn. Alle activiteiten binnen het change management proces controls worden beoefend voor de Normal Changes.
Voorbeelden kunnen zijn migratie van kritische informatiebronnen, applicaties en workloads van on-premise servers naar cloud datacenters.
Het definiëren van wijzigingen als Normal vermindert het risico voor de organisatie en IT-dienstverleners, omdat planning voor elke wijziging ervoor zorgt dat risico’s zorgvuldig worden beperkt en wijzigingsverzoeken de gewenste uitkomsten opleveren. De implementatie van Normal Changes is echter ook een langdurig en tijdrovend proces. Naast het goedkeurings- en autorisatieproces heeft de serviceprovider behoefte aan een sterke zichtbaarheid van en controle over het veranderingsproces, de onderworpen systemen en de bijbehorende afhankelijkheden.
Het beheer en de implementatie van Normal Changes vereist daarom geavanceerde ITSM-technologieën om het veranderingsproces en de systemen zorgvuldig te analyseren, te testen, te beheren en uit te voeren. Zodra de Normal Change is geïmplementeerd, evalueert de IT het succes van de implementatie en de toekomstige eisen voor soortgelijke wijzigingen. Idealiter rijpt IT zijn change management proces, tooling en mogelijkheden om een Normal Change om te zetten in een Standard Change. Dit vermindert de last voor IT en de serviceproviders om wijzigingen te beheren, terwijl ze ook controle krijgen over het proces van wijzigingsbeheer zoals dat is bereikt voor Standard Changes.
Samenvatting
Dit proces van wijzigingsbeheer helpt om het succes van implementaties te vergroten, terwijl het risico wordt verminderd en de downtime wordt geminimaliseerd. De verschillende soorten wijzigingen en hun categorisering helpt bij het soepel laten verlopen van het gehele wijzigingsproces. Standaard veranderingen worden doorgevoerd met weinig tot geen toezicht, terwijl Emergency veranderingen zorgvuldig beheer en gedetailleerde analyse vereisen.
Het onderscheid tussen Standaard, Normaal en Noodwijzigingen moet worden gezien vanuit een conceptueel perspectief, dat verder gaat dan verschillen in de naamgeving. De termen Standaard en Normaal kunnen synoniem lijken, maar de onderliggende verschillen vertegenwoordigen de doeltreffendheid van de procedures en controles voor wijzigingsbeheer. Het is daarom belangrijk om een sterke change enablement praktijk te hebben in het discrimineren tussen de drie veranderingstypen door middel van een zorgvuldige beoordeling van de wijzigingsverzoeken en incidenten die leiden tot een veranderingseis.
Deze drie soorten verandering helpen organisaties om problemen aan te pakken wanneer ze zich voordoen en tegelijkertijd het constante tempo te handhaven dat van moderne DevOps-organisaties wordt verwacht.
Gerelateerde lectuur
- BMC Service Management Blog
- Types & Levels of Change Management
- Change Management in de Cloud
- Organizational Change Management (OCM): A Template for Reorganizing IT
- Facilitating Change through Effective Communication