Wko

Hvordan man kan udvikle et IT skifter management program

"Det må antages, at der ikke er noget mere vanskeligt at gennemføre eller mere tvivlsomt for succes eller farligere at håndtere end at indlede en ny orden i tingene."
Machiavelli (1446-1507)

Change Management Program (CMP), mere almindeligt kendt som Change Control Process eller Skift Control Management Process, er en formel proces, der anvendes til at sikre, at ændringer til et produkt eller system er indført i en kontrolleret og koordineret måde (som defineret af ISO 20000). CMP skal ikke forveksles med Organizational Change Management (OCM), som forvalter virkningerne af nye forretningsprocesser, herunder som følge af systemets rollouts og it-initiativer, ændringer i organisationsstruktur, eller kulturelle ændringer inden for en virksomhed. Kort sagt, styrer OCM folket side af forandringer.

Formålet med CMP, er at sikre, at de negative konsekvenser af ændringer i en virksomheds IT-system minimeres ved hjælp af en standardiseret proces governance. Nogle ændringer er ikke valgfrit. Hvis for eksempel, bliver stregkoden standard skifte, skal du tilpasse sig; hvis en tilbageholdelse af skat struktur ændres, skal du have en ændring. Ikke desto mindre er alle ændringer af denne art er stadig genstand for styring.

Det må aldrig være sådan, at ad hoc-der foretages ændringer i systemet eller procedurer uden nogen forglemmelse. Denne idé skal stamme med den øverste ledelse og blive væltet ned, uden undtagelser, at alle i virksomheden. Uden opbakning på højeste niveau, er CMP en ubrugelig spild af tid og penge. Med en passende, vil dette program gemme din virksomhed fra nogle meget dyre fejl.

Steps

Hvordan man kan udvikle et IT skifter management program. Udvikle en anmodning om ændring (RFC).
Hvordan man kan udvikle et IT skifter management program. Udvikle en anmodning om ændring (RFC).
  1. 1
    Udvikle en anmodning om ændring (RFC): Dette kan stamme fra problemer forvaltning, hvor et emne, eller en serie af relaterede emner, er identificeret, og en formildende ændring er nødvendig for at forhindre (eller minimere) fremtidige virkninger. RFC kan også stamme som et resultat af en forretningsmæssig beslutning, som vil kræve nogle ændringer (tilføje, slette, skift) til understøttende teknologi. En RFC kan også være nødvendigt på grund af påvirkninger udefra (dvs. statslige reguleringer eller ændringer foretaget af forretningspartnere).
  2. 2
    Opnå business ændring accept: Beslutningen om at foretage en ændring er typisk en forretningsmæssig beslutning, hvor omkostningerne vs fordele vejes. Selv i situationer, hvor ændringen er strengt infrastruktur orienteret (komponent eller systemfejl) beslutningen om at bruge penge ligger hos erhvervslivet, ikke med den IT-afdeling. Der er tilfælde, hvor procedurer er udviklet på forhånd at Forhåndsgodkend ændringer såsom nødsystem vedligeholdelse, men uanset hvornår af tilladelsen, at beslutningen stadig ligger hos business management.
  3. 3
    Indled udviklingsprojektet: Udvikling af ændringen (herunder testning) er en IT-styret funktion. I tilfælde af en nødsituation ændring (server er nede) disse funktioner er typisk forudbestemt. Når et nyt system skal udvikles, er der et samarbejde mellem de forretningsmæssige brugere og it-team. Systemerne er designet af det, er designet godkendt af forretningspartnere (brugere), som er udviklet af IT, testet af en kombination af it og brugere, og det endelige produkt er godkendt af begge. Omhyggelig opmærksomhed skal gives til tilknyttede virkninger af den nye ændring kan have på eksisterende systemer.
  4. 4
    Pass forandringsledelse gate: The Change Advisory Board (CAB) gennemgår alle ændringer, før de kan sættes i produktion. Normalt vil CAB bestå af en gruppe af mennesker med forskellige perspektiver, baggrunde og områder af ekspertise. Deres funktion er at gennemgå ændringen fra en proces og governance synspunkt at sikre, at alle forudsigelige risici er blevet identificeret og afbødet, og at kompenserende teknikker er på plads for alle elementer af eksponering (ting, der kunne gå galt). Udviklingen team og ændringen sponsor vil præsentere ændringen af ​​CAB. Evaluering af risici vil være i fokus. Implementeringsstrategier, kommunikation til de berørte interessenter, backout planer og post-implementering overvågning er elementer, som CAB er forpligtet til at fokusere. CAB er ikke ansvarlig for at afgøre, om ændringen er hensigtsmæssig - afgørelsen allerede er blevet gjort. CAB er heller ikke ansvarlig for at afgøre, om ændringen er omkostningseffektiv. Igen, det er strengt en forretningsmæssig beslutning.
  5. 5
    Gennemføre ændringen: Hvis CAB ikke godkender ændringen, er de grunde, der er anført (dette er altid, fordi visse risici ikke er blevet mildnet eller kommunikation har ikke været planlagt) og udvikling team vil have tid til at løse disse spørgsmål, og omlægge en møde før CAB. Hvis ændringen godkendes, gennemførelse planlægges. Det er normalt ikke tilfældet, at CAB er repræsenteret på implementering, selv om det er muligt, at nogle medlemmer af CAB har ekspertise, der er nødvendig i forbindelse med gennemførelsen, men de vil ikke være til stede som officielle CAB repræsentanter, men snarere som emne eksperter ( SMV). Hvordan ændringen gennemføres, checklisten og trin, er prædefinerede og blev præsenteret for og godkendt af CAB. Hele processen skal være grundigt dokumenteret og den godkendte proces skal præcist følges.
  6. 6
    Rapportere resultaterne: Enten ændringen blev gennemført med succes ingen problemer, blev ændringen gennemføres med spørgsmål, der blev korrigeret under gennemførelsen, blev ændringen gennemføres med spørgsmål, der blev anset for acceptable, problemer opstod, der var uacceptable, og ændringen blev rullet tilbage, eller i værste fald ændringen blev gennemført med uacceptable problemer og kunne ikke blive rullet tilbage. Uanset resultatet, er der dokumenterede og returneres til CAB. CAB er derefter ansvarlig for at distribuere denne information til interessenterne og for at opbevare og vedligeholde disse resultater i Change Management system (det kan enten være en automatiseret database eller et papir registreringssystem, men dokumenterne skal opretholdes for revision).
  7. 7
    Link Problem Management til ændringer: problemer, der opstår, bør sammenlignes med CAB dokumentation af ændringer, så eventuelle uforudsete skadelige virkninger af en ændring kan isoleres. Det er ofte tilfældet, at bivirkningerne af en ændring ikke er bemærket det samme, men er identificeret ved fremkomsten af ​​problemer i afviklingssystemer. For eksempel kan tilsætning af flere felter til en database ikke have en direkte negativ effekt på brugerne, men kan påvirke netværkets ydeevne, der ville være indlysende for andre brugere, som ikke er direkte involveret i det modificerede system.
  8. 8
    Periodisk revidere CMP: Mindst en gang om året en revision af CMP bør udføres for at sikre, at al forandring dokumentationen vedligeholdes og tilgængelige. Alle ændringer godkendelse dokument bør undersøges for at sikre, at de rette underskrifter er på plads, og at resultaterne af gennemførelsen, er behørigt dokumenteret.

Tips

  • Procedurerne bør være genstand for Change Management. Hvis der er en ændring i system backup planlægning, skal der gå gennem Change Management. Analyser hver ændring af enhver art (system eller procedure) for at afgøre, om der er nogen risiko.
  • Standard periodisk vedligeholdelse skal forhåndsgodkendt. Hvis det er en normal proces for at genstarte en server på søndag morgen kl 2:00, er det ikke nødvendigt at indsende en RFC hver gang, men denne proces skal godkendes på forhånd.
  • Ad hoc-vedligeholdelse skal overholde CMP. Omfatte sådanne ting som at teste de brandslukningssystemer, rengøring sub-gulv i datacenteret, HVAC inspektion og afprøvning, og endda skadedyrsbekæmpelse vedligeholdelse. Nogle virksomheder går så vidt som til at kræve en RFC, hvis en pære er ændret i datacenteret (stigen faldt og beskadigede netværket).

Advarsler

  • Politik kan ofte komme i vejen for CAB. "Denne ændring er påkrævet" kan være sandt, men det kunne også være en personlig dagsorden fra en af ​​de ledende medarbejdere. CAB skal have endelige myndighed til at træffe beslutninger om gennemførelse.
  • Roter CAB medlemmer hyppigt. Altid har de samme medlemmer kan føre til favorisering, og det kan føre til udbrændthed. Du vil have din CAB at være frisk, være opmærksom, og ikke være genstand for eksterne politiske påvirkninger.

Citater

International Standards Organization
COBIT
Wikipedia henvisning