Wkonl

Hoe maak je een ontwikkeling van IT-management programma te wijzigen

"Het moet worden overwogen dat er niets meer moeilijk uit te voeren en niet meer twijfelen aan het succes, noch meer gevaarlijk te hanteren dan een nieuwe orde der dingen te initiëren."
Machiavelli (1446-1507)

Change Management Program (CMP), beter bekend als Change Control Process of Change Control Management Process, is een formeel proces wordt gebruikt om ervoor te zorgen dat veranderingen in een product of systeem worden geïntroduceerd in een gecontroleerde en gecoördineerde wijze (zoals gedefinieerd door ISO 20000). CMP moet niet worden verward met Organizational Change Management (OCM), die de effecten van nieuwe business processen, inclusief die welke voortvloeien uit het systeem uitrollen en IT-initiatieven, veranderingen in de organisatiestructuur, of culturele veranderingen binnen een onderneming beheert. Kortom, OCM beheert de menselijke kant van verandering.

Het doel van het CMP, is ervoor te zorgen dat de negatieve impact van wijzigingen in informatie van een bedrijf Technology systeem wordt beperkt door middel van een gestandaardiseerd proces van het bestuur. Sommige veranderingen zijn niet optioneel. Als, bijvoorbeeld, wordt de streepjescode norm verandert, moet u aanpassen, als een fiscale inhouding structuur verandert, moet u een wijziging hebt. Niettemin zijn alle wijzigingen van deze soort zijn nog steeds onderworpen aan het bestuur.

Het mag nooit het geval dat de ad-hoc wijzigingen worden aangebracht aan het systeem of op procedures zonder enige onoplettendheid zijn. Dit idee moet afkomstig zijn met het senior management en worden doorgegeven, zonder uitzonderingen, aan iedereen in het bedrijf. Zonder achtergrondkoor op het hoogste niveau, het CMP is een nutteloze verspilling van tijd en geld. Met de juiste steun, zal dit programma uw bedrijf te redden van een aantal zeer kostbare fouten.

Stappen

Hoe maak je een ontwikkeling van IT-management programma te wijzigen. Ontwikkelen van een verzoek tot wijziging (RFC).
Hoe maak je een ontwikkeling van IT-management programma te wijzigen. Ontwikkelen van een verzoek tot wijziging (RFC).
  1. 1
    Ontwikkelen van een verzoek tot wijziging (RFC): Deze kunnen afkomstig zijn van problem management waar een probleem, of een reeks van gerelateerde onderwerpen, is geïdentificeerd en een verzachtende verandering is nodig om toekomstige effecten te voorkomen (of te minimaliseren). De RFC kan ook afkomstig zijn als gevolg van een zakelijke beslissing die enige aanpassing (toevoegen, verwijderen, wijzigen) om de ondersteunende technologie zal vereisen. Een RFC kan ook nodig zijn als gevolg van invloeden van buitenaf (dwz overheidsvoorschriften of wijzigingen die door zakenpartners).
  2. 2
    Verkrijgen van zakelijke acceptatie verandering: De beslissing om een verandering te maken is meestal een zakelijke beslissing waar de kosten versus baten worden afgewogen. Zelfs in situaties waarin de verandering is ten strengste infrastructuur georiënteerd (component of het systeem) de beslissing om geld te spenderen verblijft met het bedrijfsleven, niet met de IT-afdeling. Er zijn gelegenheden waarbij procedures worden ontwikkeld vooraf aan veranderingen zoals noodsysteem onderhoud preauthorize, maar ongeacht het tijdstip van de vergunning, de beslissing nog steeds berust bij de bedrijfsvoering.
  3. 3
    Initiëren van de ontwikkeling project: Ontwikkeling van de verandering (inclusief testen) is een IT-geleide functie. In geval van nood verandering (server down) die functies zijn meestal voorafbepaalde. Wanneer er een nieuw systeem moet worden ontwikkeld, er is een samenwerkingsverband tussen de zakelijke gebruikers en de IT-team. De systemen zijn ontworpen door IT, wordt het ontwerp goedgekeurd door de business partners (gebruikers), ontwikkeld door IT, getest door een combinatie van IT en de gebruikers, en het uiteindelijke product is goedgekeurd door beide. Zorgvuldige aandacht moet worden besteed aan bijkomende effecten van de nieuwe verandering kan hebben op bestaande systemen.
  4. 4
    Voorbij het ​​beheer poort verandering: De Change Advisory Board (CAB) beoordeelt alle wijzigingen voordat ze in productie kunnen worden gebracht. Normaal gesproken zal het CAB bestaat uit een groep mensen met verschillende perspectieven, achtergronden en expertisegebieden. Hun functie is om de verandering van een proces en governance oogpunt om te verzekeren dat alle voorzienbare risico's zijn geïdentificeerd en gemitigeerd beoordelen, en dat compenserende technieken zijn voorhanden zijn voor de elementen van de blootstelling (dingen die fout kunnen gaan). Het development team en de verandering sponsor zal de wijziging voorleggen aan de CAB. Evaluatie van de risico's zal de nadruk liggen. Implementatiestrategieën, communicatie naar de betrokken stakeholders, backout plannen en post-implementatiecontrole zijn elementen waarop het CAB nodig is om scherp te stellen. Het CAB is niet verantwoordelijk voor het bepalen of de verandering zich opdringt - die beslissing is al gemaakt. Het CAB is ook niet verantwoordelijk voor het bepalen of de verandering kosteneffectief is. Nogmaals, die strikt is een zakelijke beslissing.
  5. 5
    Uitvoering van de verandering: Als de CAB de verandering niet goedkeurt, worden de redenen vermeld (dit is altijd omdat bepaalde risico's niet zijn verzacht of mededelingen zijn niet gepland) en de ontwikkeling team krijgt tijd om die problemen op te lossen en het herschikken van een voldoen voordat het CAB. Indien de wijziging wordt goedgekeurd, wordt de uitvoering gepland. Het is normaal gesproken niet het geval is, dat de CAB is vertegenwoordigd op implementatie hoewel het mogelijk is dat sommige leden van de CAB hebben expertise die nodig is tijdens de uitvoering is, maar ze zullen niet aanwezig als officiële vertegenwoordigers CAB te zijn, maar eerder als vakexperts ( KMO). Hoe de verandering is doorgevoerd, de checklist en trappen, zijn vooraf gedefinieerd en gepresenteerd aan en door de CAB goedgekeurd. Het hele proces moet grondig worden gedocumenteerd en het goedgekeurde proces moet nauwkeurig worden gevolgd.
  6. 6
    Rapporteren de resultaten: Ofwel de verandering werd succesvol geïmplementeerd zonder problemen, werd de verandering doorgevoerd met kwesties die tijdens de uitvoering werden gecorrigeerd, werd de verandering doorgevoerd met zaken die aanvaardbaar werden geacht, problemen ontstonden die onaanvaardbaar waren en de verandering werd teruggedraaid, of in het ergste geval de verandering werd doorgevoerd met onaanvaardbare problemen en kon niet worden teruggedraaid. Ongeacht het resultaat dat wordt beschreven en aan de CAB. Het CAB is vervolgens verantwoordelijk voor het verspreiden van deze gegevens aan de belanghebbenden en voor het opslaan en onderhouden van deze resultaten in het Change Management-systeem (die kan worden ofwel een geautomatiseerd gegevensbestand of een papieren klassement, maar de documenten moeten worden gehandhaafd voor audit doeleinden).
  7. 7
    Link probleem management om veranderingen: Problemen die zich voordoen moeten worden vergeleken met de CAB documentatie over wijzigingen zodat onvoorziene schadelijke effecten van een verandering kan worden geïsoleerd. Het is vaak het geval dat ongewenste effecten van een verandering niet meteen worden opgemerkt, maar worden geïdentificeerd door het ontstaan ​​van problemen in de aangesloten systemen. Bijvoorbeeld, zou de toevoeging van een aantal velden in een database een direct negatief effect op de gebruikers niet hebben, maar kon netwerkprestaties die duidelijk voor andere gebruikers die niet direct betrokken zijn bij het gewijzigde systeem zou beïnvloeden.
  8. 8
    Periodiek controleren van de CMP: Minstens een keer per jaar een audit van de CMP moeten worden uitgevoerd om te verzekeren dat alle verandering documentatie wordt onderhouden en beschikbaar. Elke goedkeuring document verandering moet worden onderzocht om te verzekeren dat de juiste handtekeningen zijn en dat de resultaten van de uitvoering zijn goed gedocumenteerd.

Tips

  • Procedures moeten worden onderworpen aan Change Management. Als er een verandering in het systeem back-up plannen, dat moet doorlopen Change Management. Analyseer elke verandering van welke aard dan ook (of-procedure) om te bepalen of er een mogelijk risico.
  • Standaard periodiek onderhoud moet worden vooraf goedgekeurde. Als het een normaal proces om een ​​server te herstarten op zondagochtend om 2:00, is het niet nodig om een ​​RFC elke keer indienen, maar dat proces moet vooraf worden goedgekeurd.
  • Ad-hoc onderhoud moet zich houden aan de CMP. Omvatten zaken zoals het testen van de brandblussystemen, reinigen sub-vloer in het datacenter, HVAC-inspectie en het testen en zelfs ongediertebestrijding onderhoud. Sommige bedrijven gaan zelfs zo ver om een ​​RFC nodig als een gloeilamp wordt veranderd in het datacenter (de ladder viel en beschadigde het netwerk).

Waarschuwingen

  • Politiek kan vaak in de weg van de CAB. "Deze verandering is nodig" kan waar zijn, maar het kan ook een persoonlijke agenda van een van de leidinggevenden. De CAB moet ultieme bevoegdheid om beslissingen te nemen over de uitvoering.
  • Roteren regelmatig CAB-leden. Altijd met dezelfde leden kunnen leiden tot vriendjespolitiek, en het kan leiden tot burn-out. U wilt dat uw CAB te zijn frisse, aandacht, en niet onderworpen aan externe politieke invloeden.

Citaties

Internationale standaarden organisatie
COBIT
Wikipedia referentie