Home \ ekonomi
 

Utveckla ett IT Change Management Program.

 

"Det måste komma ihåg att det inte finns något svårare eller tveksamt att lyckas än farligare än införandet av något nytt." Machiavelli (1446-1507) <91112>  

Ett Change Management Program (CMP), även känt 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 styrs och samordnat sätt (enligt definitionen i ISO 20000). CMP ska inte förväxlas med Organisation Change Management (OCM), som hanterar effekterna av nya affärsprocesser, inklusive systemutdelningar och IT-initiativ, förändringar i organisationsstrukturen eller kulturförändringar inom ett företag. Kort sagt, OCM avser människor när det gäller förändringar.

 

Syftet med CMP är att hjälpa till att minimera de negativa effekterna av förändringar i ett företags IT-system med hjälp av en standardiserad kontrollprocess. Vissa ändringar är inte valfria. Om, till exempel, Streckkodsstandarden ändras, du måste anpassa dig till den; Om en skattestruktur ändras måste du göra ändringar. Ändå är alla ändringar av detta slag föremål för kontroll.

 

Det får aldrig tillåtas göra ad hoc-ändringar i systemet eller processerna utan tillsyn. Denna idé måste komma från ledningen och utan undantag skickas till alla i företaget. Med ingen toppnivån är CMP slöseri med tid och pengar. Med korrekt stöd sparar detta program ditt företag kostsamma misstag.

                

Förfarande .

    
     
  1.            1      Utveckla en begäran om ändring (RFC): Det här kan komma från problemhantering, som identifierar ett problem eller en uppsättning problem och kräver mildrande förändringar för att förhindra (eller förhindra) framtida påverkan minimera). RFC kan också vara ett resultat av ett affärsbeslut som kräver ändringar av stödtekniken (lägg till, ta bort, ändra). En RFC kan också vara nödvändig på grund av yttre påverkan (till exempel lagaregler eller förändringar som görs av affärspartner).       
  2.  
  3.             2      Få godkännande för en företagsändring: Beslutet att byta är vanligtvis ett affärsbeslut som balanserar kostnader och fördelar. Även i situationer där förändringen är strikt relaterad till infrastruktur (komponent eller systemfel) är beslutet att investera i verksamheten, inte IT-avdelningen. Det finns tillfällen där processer utvecklas i förväg för att förhandla om förändring, t.ex. Nödsystemet underhåll, men oavsett tidpunkten för godkännandet kvarstår beslutet med ledningen.        
  4.  
  5.             3      Inleda utvecklingsprojektet: Utvecklingen av förändringen (inklusive testet) är en IT-ledd funktion. I händelse av en nödförändring (servern är defekt) är dessa funktioner vanligtvis förutbestämda. När ett nytt system behöver utvecklas finns det samarbete mellan användarna och IT-teamet. Systemen är designade av IT, designen släpps av affärspartnerna (användare), utvecklad av IT, testad av en kombination av IT och användare, och den slutliga produkten släpps av båda. Noggrann uppmärksamhet måste ägnas åt eventuella ytterligare effekter som förändringen kan ha på befintliga system.        
  6.  
  7.             4      Passerar Change Management Gate: Change Advisory Board (CAB) granskar alla ändringar innan de går i produktion. Vanligtvis är CAB en grupp människor med olika perspektiv, bakgrund och expertis. Dess funktion är att se över förändringen från processens synvinkel och kontrollen för att säkerställa att alla förutsebara risker har identifierats och mildrats och att balanseringstekniker har använts för alla sårbara element (saker som kan gå fel). Utvecklingslaget och underhållaren av förändringen presenterar förändringen till CAB. Fokus ligger på att uppskatta riskerna. Implementeringsstrategier, kommunikation med berörda aktörer, fallback-planer och övervakning efter genomförande är element som CAB behöver fokusera på. CAB är inte ansvarig för att avgöra om ändringen är lämplig - detta beslut har redan gjorts. CAB ansvarar inte heller för att avgöra huruvida förändringen är kostnadseffektiv. Återigen är detta ett strikt affärsbeslut.        
  8.  
  9.             5      Implementera ändringen: Om CAB inte godkänner ändringen anges orsakerna (det beror på att vissa risker inte har lindrats eller kommunikationen inte har planerats) och utvecklingsgruppen får tid att lösa dessa problem fixa och ordna ett nytt möte med CAB. När förändringen släpps är genomförandet planerat. Det är vanligtvis inte så att CAB är involverad i genomförandet, även om det är möjligt att vissa medlemmar av CAB har den kompetens som behövs för att genomföra den, men de blir inte officiella representanter för CAB men ämnesexperter (SMF) som skall representeras. När ändringen görs är checklistan och stegen förutbestämd och presenterad och godkänd av CAB. Hela processen måste dokumenteras noggrant och den godkända processen måste följas noggrant.        
  10.  
  11.             6      Rapportera resultaten: Antingen ändringen genomfördes utan problem, förändringen genomfördes med problem som fastställdes under implementeringen, ändringen genomfördes med problem som ansågs acceptabla, det är problem inträffade, vilket var oacceptabelt och en återföring av förändringen gjordes eller i värsta fall förändringen gjordes med oacceptabla problem och ingen återuppringning kunde utföras. Oavsett resultatet kommer det att dokumenteras och rapporteras tillbaka till CAB. CAB ansvarar då för att distribuera denna information till aktieägarna och för att lagra och erhålla dessa resultat i Change Management System (detta kan antingen vara en automatiserad databas eller ett pappersbaserat system, men dokumenten måste erhållas för revisioner).        
  12.  
  13.             7      Länkhantering till ändringar: Uppkomna problem bör jämföras med att dokumentera ändringen till CAB så att eventuella oväntade skadliga effekter av en ändring kan isoleras. Det är ofta fallet att oönskade effekter av en förändring inte omedelbart märks, utan identifieras genom att problem uppstår i ytterligare system. Det kan t.ex. Att lägga till att lägga till flera fält i en databas kommer inte att ha direkt negativ påverkan för användarna, men kommer att påverka nätverksprestandan, vilket skulle uppmärksamma andra användare som inte är direkt involverade i det ändrade systemet.        
  14.  
  15.             8      CMP Regular Audit: En revision av CMP bör utföras minst en gång per år för att säkerställa att all dokumentation av ändringarna upprätthålls och är tillgänglig. Varje utgåva av ändringen bör granskas för att säkerställa att rätt signaturer finns på plats och att resultaten av genomförandet dokumenteras korrekt.                  
  16.  
             

Tips .

    
     
  • Vanligt periodiskt underhåll bör godkännas i förväg. Om det är en vanlig process att starta om en server klockan 2 på en söndagsmorgon är det inte nödvändigt att skicka in en RFC varje gång, men denna process måste släppas i förväg.
  •  
  • Ad hoc underhåll kvarstår med CMP. Inkludera sådana saker som att testa brandsläckare, rengöra datacenterets golv, inspektera och testa HVAC, och till och med skadedjursbekämpning. Vissa företag går så långt att de behöver en RFC när en glödlampa behöver bytas ut i datacentret (stegen har fallit över och skadat nätverket).
  •  
  • Processer bör vara föremål för förändringshantering. Om det finns en förändring i systemets backupplan, måste den gå igenom förändringshantering. Analysera varje ändring av varje typ (system eller process) för att avgöra om det finns någon potentiell risk.
  •  
             

Varningar .

    
     
  • Rotera medlemmarna av CAB ofta. Att alltid ha samma medlemmar kan leda till favoritism och utbrändhet. Du vill att din CAB ska vara frisk, uppmärksam och inte utsatt för externa politiska influenser.
  •  
  • Politiken kan ofta komma i vägen för CAB. "Denna förändring är nödvändig" kan vara sant, men det kan också vara en personlig agenda för en av cheferna. CAB måste ha den ultimata myndigheten att fatta beslut om att göra en förändring.
  •  
             

citat .

    

Internationella standardiseringsorganisationen COBIT ITIL Wikipedia Referens <91112>         

Ekonomi populär:
Bor på en stram budget.

Överför pengar från PayPal till bankkonto.

Köp odlad mark.

Låt dina smycken uppskatta.

Köp och sälj valutor.

Tjäna pengar på sidan.

Starta ett online företag.

Beräkna kreditkortsränta.

Köp bostäder i Australien.

Köp bitcoins.

Bitcoins mottagna.

Registrera ett namn som ett varumärke.

Starta ditt eget städföretag.

Beräkna netto nuvärdet.

Tjäna pengar på sidan.

Öppna en butik för klädaffärer.

Avbryt ett kontrakt.

Beräkna marginalverktyg.

Skriv ett rådgivningstilbud.

Utveckla en affärsidé.

Kontrollera Powerball.

ako woman