Hoe een IT Change Management-programma te ontwikkelen

Accepteer de verandering in het bedrijf: De beslissing om een ​​wijziging aan te brengen is meestal een zakelijke beslissing waarbij kosten versus voordelen worden vergeleken. Zelfs in situaties waarin de wijziging strikt infrastructureel is (uitval van onderdelen of systemen), ligt de beslissing om geld te investeren in het bedrijf, niet in de IT-afdeling. Er zijn situaties waarin de procedures worden ontwikkeld voorafgaand aan de vooraf toegestane wijzigingen, zoals het onderhoud van het noodsysteem, maar ongeacht de datum van de autorisatie, valt de beslissing nog steeds onder de bedrijfsadministrateurs.

Start de projectontwikkeling: Het ontwikkelen van de verandering (inclusief de tests) is een functie geleid door IT. In het geval van een noodverandering (server werkt niet) zijn deze 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 gebruikers, en het eindproduct is door beide goedgekeurd. Er moet aandacht worden besteed aan de bijwerkingen die het nieuwe systeem kan hebben op bestaande systemen.

Geef de deur van bestuurlijke verandering door: De Change Advisory Board (CAB) beoordeelt alle wijzigingen voordat ze in productie kunnen worden genomen. Normaal bestaat de CAB uit een groep mensen met verschillende perspectieven, achtergronden en expertisegebieden. Het is zijn functie om de verandering vanuit een proces- en vormperspectief te beoordelen om ervoor te zorgen dat alle te voorziene risico`s zijn geïdentificeerd en beperkt en dat compenserende technieken aanwezig zijn voor elk element dat wordt blootgesteld (dingen die fout kunnen gaan). Het ontwikkelteam en de veranderingssponsor zullen de wijziging presenteren aan de CAB. De risicobeoordeling zal het belangrijkste punt zijn. Implementatie strategieën, communicatie naar getroffen belanghebbenden, achterwaartse plannen en monitoring na implementatie zijn elementen waarin de CBI zich moet concentreren. De CAB is niet verantwoordelijk voor het bepalen of de wijziging geschikt is, maar die beslissing is al genomen. De CAB is ook niet verantwoordelijk voor het bepalen of de wijziging winstgevend is. Nogmaals, dat besluit is strikt administratief.

Implementeer de verandering: Als de CAB de wijziging niet goedkeurt, worden redenen vermeld (dit komt omdat altijd bepaalde risico`s niet worden beperkt of de communicatie niet is gepland) en het ontwikkelteam krijgt de tijd om die problemen op te lossen en er zal een nieuwe vergadering worden gepland vóór de CAB. Als de wijziging wordt goedgekeurd, wordt de implementatie gepland. Het is meestal niet zo dat de CAB wordt vertegenwoordigd in de implementatie, hoewel het mogelijk is dat sommige leden van de CAB kennis hebben die nodig is tijdens de implementatie, maar ze zullen niet worden gepresenteerd als vertegenwoordigers van de CAB, maar als experts in de materie (voor het acroniem in het Engels SME). Terwijl de wijziging wordt geïmplementeerd, zijn de lijst en stappen vooraf gedefinieerd en gepresenteerd en goedgekeurd door de CAB. Het hele proces moet goed worden gedocumenteerd en het goedgekeurde proces moet nauwkeurig worden gevolgd.

Rapporteer de resultaten: Als de verandering correct was geïmplementeerd zonder tegenslagen, of de wijziging werd geïmplementeerd met problemen die werden gecorrigeerd tijdens de implementatie, of de wijziging werd geïmplementeerd met problemen die als acceptabel werden beschouwd, of de problemen die ontstonden, waren onaanvaardbaar en teruggestuurd, of in het slechtste geval van de gevallen werd de verandering geïmplementeerd met onaanvaardbare problemen en kan deze niet worden geretourneerd. Alle resultaten zullen worden gedocumenteerd en teruggestuurd naar de CAB. De CAB is nu verantwoordelijk voor het verspreiden van die informatie naar de belanghebbende partijen en voor het opslaan en onderhouden van die resultaten in het Wijzigingsbeheersysteem (dit kan in een geautomatiseerde database of in een geautomatiseerde database zijn). papiervulsysteem, maar documenten moeten worden bewaard voor auditdoeleinden).

Linkproblemen in Change Management: Problemen die zich voordoen in vergelijking met de documentatie van wijzigingen in de CAB, zodat elk ongunstig effect op de verandering die niet wordt verwacht, kan worden geïsoleerd. Het is een veel voorkomend geval dat ongewenste effecten van de verandering niet onmiddellijk worden opgemerkt, maar dat ze worden geïdentificeerd wanneer het probleem zich voordoet in hulpsystemen. Het toevoegen van veel velden aan een database heeft bijvoorbeeld mogelijk geen direct negatief effect op gebruikers, maar kan van invloed zijn op de prestaties van het netwerk die worden opgemerkt voor andere gebruikers die niet rechtstreeks zijn gerelateerd aan het gewijzigde systeem.