"Det må tas i betraktning at det ikke er noe mer vanskelig å gjennomføre og heller mer tvilsomt om suksess og heller ikke mer farlig å håndtere enn å starte en ny tingenes orden."
Machiavelli (1446-1507)
Change Management Program (CMP), mer kjent som Change Control Process eller Change Control Management Process, er en formell prosess som brukes for å sikre at endringer i et produkt eller system er innført i en kontrollert og koordinert måte (som definert av ISO 20000). CMP må ikke forveksles med Organizational Change Management (OCM), som forvalter konsekvensene av nye forretningsprosesser, inkludert de som stammer fra system rollouts og IT-satsing, endringer i organisasjonsstrukturen, eller kulturelle endringer i en virksomhet. Kort sagt, klarer OCM folk siden av endringen.
Formålet med CMP, er å sikre at den negative virkningen av endringer i et selskaps Information Technology system er minimert ved hjelp av en standardisert styringskunsten. Noen endringer er ikke valgfritt. Hvis, for eksempel, er strekkoden standard endring, må du tilpasse, hvis en skattetrekksmidler strukturen endres, må du ha en endring. Likevel, alle endringer av denne typen er fortsatt gjenstand for styring.
Det må aldri være slik at ad-hoc endringer er gjort i systemet eller prosedyrer uten noen forglemmelse. Denne ideen må stamme med toppledelsen og være gått ned, uten unntak, til alle i selskapet. Uten å sikkerhetskopiere på høyeste nivå, er CMP en ubrukelig bortkastet tid og penger. Med riktig støtte, vil dette programmet lagre din bedrift fra noen svært kostbare feil.
Trinn
- 1Utvikle en anmodning om endring (RFC): Dette kan stamme fra problem ledelse hvor en sak, eller en serie av relaterte spørsmål, er identifisert og en begrensende endring er nødvendig for å hindre (eller minimalisere) fremtidige effekter. RFC kan også stamme som et resultat av en forretningsmessig beslutning som vil kreve noen endringer (legge til, slette, endre) til støtte teknologien. En RFC kan også være nødvendig på grunn av ytre påvirkninger (dvs. statlige forskrifter eller endringer gjort av forretningspartnere).
- 2Skaff virksomheten endres aksept: Beslutningen om å gjøre en endring er vanligvis en forretningsmessig beslutning der kostnader kontra fordeler veies. Selv i situasjoner der endringen er strengt infrastruktur orientert (komponent eller systemsvikt) beslutningen om å bruke penger ligger hos bedriften, ikke med IT-avdelingen. Det finnes tilfeller der prosedyrer er utviklet på forhånd for å forhåndsgodkjenne endringer som for eksempel akutt systemvedlikehold, men uavhengig av tidspunktet for fullmakten, avgjørelsen hviler fortsatt med business management.
- 3Initiere utviklingsprosjekt: Utvikling av endringen (inkludert testing) er et IT-guidet funksjon. I tilfelle en nødsituasjon endring (serveren er nede) disse funksjonene er vanligvis forhåndsbestemt. Når et nytt system skal utvikles, er det et samarbeid mellom de profesjonelle brukere og IT-team. Systemene er designet av IT, er utformingen godkjent av forretningspartnere (brukere), utviklet av IT, testet av en kombinasjon av IT og brukerne, og det endelige produktet er godkjent av begge. Nøye oppmerksomhet må gis til hjelpeutstyr effekter den nye endringen kan ha på eksisterende systemer.
- 4Passere endringsledelse gate: The Change Advisory Board (CAB) gjennomgår alle endringer før de kan settes i produksjon. Normalt vil CAB består av en gruppe mennesker med ulike perspektiver, bakgrunner og kompetanseområder. Deres funksjon er å vurdere endring fra en prosess og styring ståsted for å sikre at alle forutsigbare risikoer er identifisert og dempet, og at kompenserende teknikker er på plass for noen elementer av eksponering (ting som kan gå galt). Utviklingsteamet og endringen sponsor vil presentere endringen i CAB. Evaluering av risiko vil være fokus. Implementeringsstrategier, kommunikasjon til berørte interessenter, Backout planer og etter implementering overvåking er elementer der CAB er nødvendig å fokusere. CAB er ikke ansvarlig for å avgjøre om endringen er riktig - at avgjørelsen allerede er gjort. CAB er heller ikke ansvarlig for å avgjøre om endringen er kostnadseffektivt. Igjen, det er strengt tatt et forretningsmessig beslutning.
- 5Gjennomføre endringen: Hvis CAB ikke godkjenne endringen er årsakene listet opp (dette er alltid fordi visse risikoer ikke er dempet eller kommunikasjon har ikke vært planlagt) og utviklingsteamet vil bli gitt tid til å fikse disse problemene og planlegge en møte før CAB. Dersom endringen blir godkjent, er gjennomføringen planlagt. Det er ikke normalt tilfelle at CAB er representert ved gjennomføringen selv om det er mulig at noen medlemmer av CAB har kompetanse som er nødvendig under gjennomføringen, men de vil ikke være til stede som offisielle CAB representanter, men heller som fageksperter ( SME). Hvordan endringen gjennomføres, sjekkliste og trinn, er forhåndsdefinert og ble presentert for og godkjent av CAB. Hele prosessen må være grundig dokumentert og godkjent prosessen må fulgt nøyaktig.
- 6Rapportere resultatene: Enten endringen ble gjennomført med hell uten problemer, ble endringen gjennomført med spørsmål som ble rettet i løpet av gjennomføringen, ble endringen gjennomført med saker som ble ansett som akseptabelt, oppsto problemene som var uakseptabelt og endringen ble rullet tilbake, eller i verste fall endringen ble gjennomført med uakseptable forhold, og kunne ikke bli rullet tilbake. Uansett resultatet, er det dokumentert og returneres til førerhuset. CAB er da ansvarlig for å distribuere denne informasjonen til interessenter og for lagring og vedlikehold disse resultatene i Change Management system (som kan enten være en automatisert database eller et papir arkivsystem, men dokumentene må opprettholdes for revisjon formål).
- 7Link problem at ledelsen endringer: Problemer som oppstår bør være i forhold til CAB dokumentasjon av endringer slik at eventuelle uforutsette bivirkninger av en endring kan isoleres. Det er ofte slik at uønskede virkninger av en endring ikke blir lagt merke til umiddelbart, men identifiseres av fremveksten av problemer i hjelpe-systemer. For eksempel kan tillegg av flere felt i en database ikke har en direkte negativ effekt på brukerne, men kan påvirke nettverksytelsen som ville være synlig for andre brukere som ikke er direkte involvert med den modifiserte systemet.
- 8Periodisk revidere CMP: Minst én gang hvert år en revisjon av CMP bør gjennomføres for å sikre at all forandring dokumentasjon er vedlikeholdt og tilgjengelig. Hver endring godkjenning dokumentet bør undersøkes for å sikre at de riktige signaturene er på plass og at resultatene av gjennomføringen er skikkelig dokumentert.
Tips
- Prosedyrer bør være gjenstand for Change Management. Hvis det er en endring i systemet backup planlegging, må det gå gjennom Change Management. Analysere hver endring av noe slag (system eller prosedyre) for å finne ut om det er mulig risiko.
- Standard periodisk vedlikehold bør forhåndsgodkjent. Hvis det er en normal prosess for å starte en server på søndag morgen klokken 02:00, er det ikke nødvendig å sende inn en RFC hver gang, men at prosessen skal godkjennes på forhånd.
- Ad-hoc vedlikehold må forholde seg til CMP. Inkluderer slike ting som å teste brannslokningsutstyr, rengjøring sub-gulv i datasenteret, HVAC inspeksjon og testing og selv skadedyrbekjempelse vedlikehold. Noen selskaper går så langt som å kreve en RFC hvis en lyspære endres i datasenteret (stigen falt og skadet nettverket).
Advarsler
- Politikk kan ofte komme i veien for CAB. "Denne endringen er nødvendig" kan være sant, men det kan også være en personlig agenda fra en av de ansatte. CAB må ha øverste myndighet til å fatte vedtak om gjennomføring.
- Roter CAB medlemmer ofte. Alltid har lik sammensetning kan føre til favorisering, og det kan føre til utbrenning. Du vil at CAB å være frisk, ta hensyn, og ikke være gjenstand for ytre politiske innflytelse.