Change Management Program (CMP), beter bekend als Change Control Process of Change Control Management Process, is een formeel proces dat wordt gebruikt om ervoor te zorgen dat wijzigingen in een product of systeem op een gecontroleerde en gecoördineerde manier worden ingevoerd (zoals gedefinieerd door ISO 20000). CMP moet niet worden verward met Organizational Change Management (OCM), dat de gevolgen van nieuwe bedrijfsprocessen beheert, inclusief die voortvloeien uit systeemrol-outs en IT-initiatieven, veranderingen in de organisatiestructuur of culturele veranderingen binnen een onderneming. Kortom, OCM beheert de mensenkant van verandering.

Het doel van het CMP is ervoor te zorgen dat de negatieve impact van wijzigingen in het IT-systeem van een bedrijf wordt geminimaliseerd door gebruik te maken van een gestandaardiseerd proces van governance. Sommige wijzigingen zijn niet optioneel. Als, bijvoorbeeld, de barcodestandaard verandert, moet u aanpassen; als een belastinginhoudingsstructuur verandert, moet u een wijziging hebben. Niettemin zijn alle veranderingen van deze aard nog steeds onderwerp van governance.

Het mag nooit zo zijn dat er zonder enig toezicht ad-hoc wijzigingen in het systeem of in procedures worden aangebracht. Dit idee moet afkomstig zijn van het hogere management en zonder uitzondering worden doorgegeven aan iedereen in het bedrijf. Zonder ondersteuning op het hoogste niveau is de CMP een nutteloze verspilling van tijd en geld. Met de juiste begeleiding, zal dit programma uw bedrijf redden van een aantal zeer kostbare fouten.

Stappen

  1. 1 Ontwikkel een Request for Change (RFC): Dit kan afkomstig zijn van probleembeheer waarbij een probleem of een reeks gerelateerde problemen wordt vastgesteld en een beperkende verandering nodig is om toekomstige effecten te voorkomen (of te minimaliseren). De RFC kan ook ontstaan ​​als gevolg van een zakelijke beslissing die enige aanpassing (toevoegen, verwijderen, wijzigen) aan de ondersteunende technologie vereist. Een RFC kan ook noodzakelijk zijn vanwege invloeden van buitenaf (dat wil zeggen overheidsvoorschriften of door zakelijke partners aangebrachte wijzigingen).
  2. 2 Accepteer acceptatie van acceptatie: Het besluit om een ​​wijziging aan te brengen is meestal een zakelijke beslissing waarbij kosten versus voordelen worden gewogen. Zelfs in situaties waarin de wijziging strikt infrastructuurgeoriënteerd is (uitval van onderdelen of systemen), ligt de beslissing om geld te besteden bij het bedrijf, niet bij de IT-afdeling. Er zijn situaties waarin van tevoren procedures worden ontwikkeld om wijzigingen zoals onderhoud van noodsystemen vooraf te autoriseren, maar ongeacht de timing van de autorisatie ligt de beslissing nog steeds bij de bedrijfsleiding.
  3. 3 Start het ontwikkelingsproject: Ontwikkeling van de verandering (inclusief testen) is een IT-geleide functie. In het geval van een noodverandering (server is uit) zijn die functies meestal vooraf bepaald. Wanneer een nieuw systeem moet worden ontwikkeld, is er een samenwerking tussen de zakelijke gebruikers en het IT-team. De systemen zijn ontworpen door IT, het ontwerp is goedgekeurd door de zakelijke partners (gebruikers), ontwikkeld door IT, getest door een combinatie van IT en de gebruikers, en het eindproduct is door beide goedgekeurd. Er moet zorgvuldig aandacht worden besteed aan bijkomende effecten die de nieuwe wijziging op bestaande systemen kan hebben.
  4. 4 Geef de Change Management Gate door: De Change Advisory Board (CAB) beoordeelt alle wijzigingen voordat ze in productie kunnen worden genomen. Normaal zal de CAB bestaan ​​uit een groep mensen met verschillende perspectieven, achtergronden en expertisegebieden. Hun functie is om de verandering vanuit een proces- en governance-standpunt te bekijken om te verzekeren dat alle te voorziene risico's zijn geïdentificeerd en beperkt en dat compenserende technieken aanwezig zijn voor alle elementen van blootstelling (dingen die mis kunnen gaan). Het ontwikkelteam en de veranderingssponsor zullen de wijziging presenteren aan de CAB. Evaluatie van het risico zal de focus zijn. Implementatiestrategieën, communicatie naar getroffen belanghebbenden, back-upschema's en monitoring na implementatie zijn elementen waarop de CBI moet focussen. De CAB is niet verantwoordelijk om te bepalen of de verandering geschikt is - die beslissing is al genomen. De CAB is ook niet verantwoordelijk voor het bepalen of de wijziging kosteneffectief is. Nogmaals, dat is strikt een zakelijke beslissing.
  5. 5 Implementeer de verandering: Als de CAB de wijziging niet goedkeurt, worden de redenen vermeld (dit is altijd omdat bepaalde risico's niet zijn gematigd of de communicatie niet is gepland) en het ontwikkelteam krijgt de tijd om deze problemen op te lossen en een vergadering opnieuw te plannen voor de CAB . Als de wijziging is goedgekeurd, is de implementatie gepland. Het is normaal niet dat de CBI wordt vertegenwoordigd bij de uitvoering, hoewel het mogelijk is dat sommige leden van de CBI over expertise beschikken die noodzakelijk is tijdens de implementatie, maar ze zullen niet aanwezig zijn als officiële CAB-vertegenwoordigers, maar eerder als materiedeskundigen ( SME). Hoe de wijziging wordt geïmplementeerd, de checklist en de stappen, zijn vooraf gedefinieerd en zijn gepresenteerd aan en goedgekeurd door de CBI. Het hele proces moet grondig worden gedocumenteerd en het goedgekeurde proces moet precies worden gevolgd.
  6. 6 Rapporteer de resultaten: Ofwel de wijziging is zonder problemen geïmplementeerd, de wijziging is geïmplementeerd met problemen die zijn gecorrigeerd tijdens de implementatie, de wijziging is geïmplementeerd met kwesties die acceptabel werden geacht, er ontstonden problemen die onaanvaardbaar waren en de wijziging werd teruggedraaid, of in het slechtste geval de verandering werd geïmplementeerd met onaanvaardbare problemen en kon niet worden teruggedraaid. Wat het resultaat ook is, dat is gedocumenteerd en teruggestuurd naar de CAB. De CAB is vervolgens verantwoordelijk voor het verspreiden van die informatie naar de belanghebbenden en voor het opslaan en bijhouden van die resultaten in het systeem voor wijzigingsbeheer (dat kan een geautomatiseerde database of een papieren archiveringssysteem zijn, maar de documenten moeten voor controledoeleinden worden bewaard).
  7. 7 Koppel probleembeheer aan wijzigingen: Problemen die zich voordoen, moeten worden vergeleken met de documentatie van CAB van wijzigingen zodat onverwachte schadelijke effecten van een verandering kunnen worden geïsoleerd. Het is vaak zo dat ongewenste effecten van een verandering niet onmiddellijk worden opgemerkt, maar worden geïdentificeerd door de opkomst van problemen in aangesloten systemen. Het toevoegen van meerdere velden aan een database heeft bijvoorbeeld mogelijk geen direct negatief effect op de gebruikers, maar kan van invloed zijn op de netwerkprestaties die duidelijk zijn voor andere gebruikers die niet direct betrokken zijn bij het gewijzigde systeem.
  8. 8 Regelmatig de CMP controleren: Ten minste één keer per jaar moet een audit van het CMP worden uitgevoerd om te verzekeren dat alle wijzigingsdocumentatie wordt bijgehouden en beschikbaar is. Elk goedkeuringsdocument voor wijzigingen moet worden onderzocht om te verzekeren dat de juiste handtekeningen aanwezig zijn en dat de resultaten van de implementatie naar behoren zijn gedocumenteerd.