"Det måste beaktas att det finns inget svårare att genomföra eller mer tveksamt om framgång eller farligare att hantera än att inleda en ny tingens ordning."
Machiavelli (1446-1507)
Change Management Program (CMP), mer känd som Change Control Process eller Change Control Management Process, är en formell process som används för att säkerställa att ändringar i en produkt eller ett system införs på ett kontrollerat och samordnat sätt (enligt ISO 20000). CMP ska inte förväxlas med Organizational Change Management (OCM), som hanterar effekterna av nya affärsprocesser, inklusive sådana som härrör från systemets utbyggnader och IT-initiativ, förändringar i organisationsstrukturen, eller kulturella förändringar inom ett företag. Kort sagt, förvaltar OCM folket sidan av förändring.
Syftet med CMP, är att se till att de negativa effekterna av förändringar i ett företags IT-system minimeras genom att använda en standardiserad process för styrning. Vissa förändringar är inte valfritt. Om, till exempel, är streckkoden standarden förändras måste man anpassa, om en källskattsförpliktelser struktur förändras, måste du ha en förändring. Trots alla förändringar av detta slag är fortfarande föremål för styrning.
Det får aldrig vara så att ad-hoc ändringar görs i systemet eller förfaranden utan någon tillsyn. Denna idé måste komma med företagsledningen och föras vidare, med några undantag, att alla i företaget. Utan att backa på den högsta nivån, är CMP en värdelös slöseri med tid och pengar. Med rätt stöd, kommer detta program att rädda ditt företag från vissa mycket kostsamma fel.
Steg
- 1Utveckla en begäran om förändring (RFC): Detta kan härröra från problem förvaltning där en fråga, eller en rad frågor, identifieras och en förmildrande förändring är nödvändig för att förhindra (eller minska) framtida effekter. Den RFC kan också härröra till följd av ett affärsmässigt beslut som kommer att kräva vissa ändringar (lägga till, ta bort, ändra) till stödjande teknik. En RFC kan också vara nödvändigt på grund av yttre påverkan (dvs. statliga föreskrifter eller ändringar som görs av affärspartners).
- 2Skaffa acceptans affärer förändring: Beslutet att göra en förändring är typiskt ett affärsmässigt beslut där kostnaderna kontra fördelarna vägs. Även i situationer där förändringen är strikt infrastruktur orienterad (komponent eller systemfel) beslutet att spendera pengar bosatt med verksamheten, inte med IT-avdelningen. Det finns tillfällen när förfarandena utarbetas i förväg för att förauktorisera förändringar såsom akut systemunderhåll, men oavsett tidpunkten för godkännandet, beslutet vilar fortfarande med företagsledning.
- 3Initiera utvecklingsprojekt: Utveckling av förändringen (inklusive provning) är ett IT-styrd funktion. I händelse av en nödsituation förändring (servern är nere) dessa funktioner är oftast förutbestämt. När ett nytt system ska utvecklas, det finns ett samarbete mellan de affärsanvändare och IT-teamet. Systemen är designade av IT, är designen godkänts av affärspartners (användare), som utvecklats av IT, testad av en kombination av IT och användarna, och den slutliga produkten är godkänd av båda. Noggrann uppmärksamhet måste ägnas bieffekter den nya förändringen kan ha på befintliga system.
- 4Pass grinden ändringshantering: The Change Advisory Board (CAB) granskar alla ändringar innan de kan sättas i produktion. Normalt kommer CAB bestå av en grupp människor med olika perspektiv, bakgrunder och kompetenser. Deras funktion är att granska förändringen från en process och styrning synvinkel för att säkerställa att alla förutsebara risker har identifierats och lindras, och att kompenserande tekniker finns på plats för alla delar av exponeringen (saker som kan gå fel). Utvecklingsteamet och förändringen sponsorn kommer att presentera förändringen till hytten. Utvärdering av risk kommer att vara i fokus. Strategier för genomförande, kommunikation med berörda intressenter, planer avinstallationsdata och efter genomförandet övervakning är faktorer på vilka CAB krävs för att fokusera. Hytten är inte ansvarig för att avgöra om ändringen är lämpligt - att beslutet redan har gjorts. Hytten är dessutom inte ansvarig för att avgöra om ändringen är kostnadseffektiv. Återigen, är det absolut ett affärsmässigt beslut.
- 5Genomföra förändring: Om CAB inte godkänner ändringen, är de skäl som anges (detta är alltid att vissa risker inte har mildrats eller kommunikation har inte planerat) och utvecklingsteam kommer att ges tid att åtgärda dessa problem och boka om en mötet före CAB. Om ändringen godkänns, är genomförandet planeras. Det är inte vanligtvis så att hytten är representerad vid genomförandet även om det är möjligt att några medlemmar av CAB har kompetens som är nödvändig i samband med genomförandet, men de kommer inte att vara närvarande som officiell CAB företrädare, utan snarare som ämnesexperter ( SMF). Hur förändringen genomförs, checklistan och steg, är fördefinierade och presenterades för och godkändes av CAB. Hela processen måste dokumenteras noggrant och godkända processen måste noggrant följas.
- 6Rapportera resultaten: Antingen förändring genomfördes framgångsrikt med några frågor, var förändringen genomfördes med frågor som rättades till under genomförandet, var förändringen genomfördes med frågor som ansetts vara godtagbart, uppstod frågor som var oacceptabla och förändringen rullades tillbaka, eller i värsta fall ändringen genomfördes med oacceptabla problem och kunde inte rullas tillbaka. Oavsett resultat, är att dokumenteras och återförs till CAB. Hytten är sedan ansvarig för att distribuera denna information till de berörda parterna och för att lagra och underhålla dessa resultat i Change Management-systemet (som antingen kan vara en automatisk databas eller ett papper register, men de dokument som måste upprätthållas för revision).
- 7Länk problemet ledningen till förändringar: Problem som uppstår bör jämföras med CAB dokumentation av förändringar så oförutsedda negativa effekter av en förändring kan isoleras. Det är ofta så att oönskade effekter av en förändring inte märkte genast, men identifieras genom uppkomsten av problem i anslutna system. Till exempel, kan tillägg av flera fält till en databas har inte en direkt negativ effekt på användarna, men kan påverka nätverkets prestanda som skulle vara uppenbart för andra användare som inte är direkt involverade med den modifierade systemet.
- 8Periodvis granska CMP: Minst en gång varje år en granskning av CMP bör genomföras för att säkerställa att all förändring dokumentation upprätthålls och tillgängliga. Varje förändring Typgodkännandeintyget bör undersökas för att säkerställa att rätt signaturer är på plats och att resultaten av genomförandet är korrekt dokumenterade.
Tips
- Rutiner bör vara föremål för Change Management. Om det finns en förändring i systemet backup schemaläggning, måste det gå igenom Change Management. Analysera varje förändring av något slag (system eller förfarande) för att avgöra om det finns någon möjlig risk.
- Standard periodiskt underhåll bör preapproved. Om det är en normal process för att starta en server på söndag morgon klockan 2:00 AM, är det inte nödvändigt att lämna in en RFC varje gång, men den processen måste godkännas i förväg.
- Ad-hoc-underhåll måste följa CMP. Omfatta sådana saker som att testa brandsläckningssystem, rengöring sub-golv i datacentret, VVS inspektion och provning samt även skadedjursbekämpning underhåll. Vissa företag går så långt som att kräva en RFC om en glödlampa ändras i datacentret (stegen föll och skadade nätverket).
Varningar
- Politik kan ofta komma i vägen för CAB. "Denna förändring krävs" kan vara sant, men det kan också vara en personlig agenda från en av chefer. Hytten skall ha högsta auktoritet att fatta beslut om genomförandet.
- Rotera CAB medlemmar ofta. Alltid har samma medlemmar kan leda till favorisering, och det kan leda till utbrändhet. Du vill att din CAB vara frisk, vara uppmärksamma, och inte vara föremål för yttre politisk påverkan.