Cum să dezvoltați un program de management al schimbării IT

"Trebuie să se considere că nimic nu este mai greu de realizat, nici un succes nesigur sau chiar mai riscant de gestionat, începutul unei noi ordini de lucruri."

Programul de management al schimbării (CMP), mai cunoscut sub numele de procesul de control al schimbării sau procesul de control al schimbării, este un proces formal utilizat pentru a se asigura că modificările unui produs sau sistem sunt introduse într-o manieră coordonată și controlată conform definiției din ISO 20000). CMP nu trebuie confundat cu schimbarea managementului organizațional (OCM), care gestionează impactul noilor procese de afaceri, inclusiv cele rezultate din implementările de sistem și proiecte IT (Tehnologia informației), modificări în structura organizatorică, sau cele activități culturale în cadrul unei companii. Pe scurt, OCP gestionează aspectele schimbării legate de oameni.

CMP urmărește să se asigure că impactul negativ al schimbărilor sistemelor de informații ale unei organizații este minimizat prin utilizarea unui proces de guvernanță standardizat. Unele modificări nu sunt discreționare. Dacă, de exemplu, codul de bare standard se modifică, trebuie să vă adaptați - dacă se modifică structura unui impozit la sursă, este necesară o modificare. Cu toate acestea, chiar toate modificările nediscreționare trebuie implementate ca parte a unui proces de guvernanță standardizat.

Nu ar trebui să se întâmple niciodată că schimbările ad-hoc ale sistemului sau ale procedurilor sunt puse în aplicare fără o supraveghere minimă. Această filozofie trebuie să provină de la conducerea de vârf și să fie transferată, vertical și fără excepție, oricui operează în companie. Fără sprijinul conducerii superioare, CMP este o pierdere inutilă de timp și de bani. Cu suport adecvat, acest program vă va salva afacerea de la unele greșeli foarte costisitoare.

2

Obțineți aprobarea solicitării de modificare: Decizia privind schimbarea este, în general, o decizie comercială în care costurile și beneficiile sunt cântărite. Chiar și în situațiile în care schimbarea este strâns legată de infrastructura sistemului (componentă sau eroare de sistem), decizia de a cheltui bani apartine companiei, nu departamentul IT. Există situații în care procedurile sunt pre-aranjate, în scopul de a pre-autoriza modificări, cum ar fi întreținerea sistemelor, cu toate acestea, în caz de urgență, indiferent de calendarul autorizației, decizia este întotdeauna de expertiză de top.

3

Începeți proiectul de dezvoltare: dezvoltarea schimbării (inclusiv a testelor) este o funcție aflată sub responsabilitatea departamentului IT. În cazul unei modificări datorate unei situații de urgență (serverul este în jos), aceste funcții sunt în general predeterminate. Atunci când dezvoltăm un nou sistem informatic, există un efort de colaborare între utilizatorii companiei și echipa IT. Sistemele sunt proiectate de acesta din urmă, proiectul este aprobat de parteneri de afaceri (utilizatori), este dezvoltat de departamentul IT, este testat împreună de către utilizatori și departamentul IT, iar produsul final este aprobat de ambele. Trebuie să acordăm o atenție deosebită efectelor secundare pe care schimbarea le poate avea asupra sistemelor existente.

4

Treceți pragul de gestionare a modificărilor: Consiliul consultativ pentru modificări (CAB) sau comisia de consiliere pentru modificări examinează toate modificările înainte de a fi introduse în producție. În mod normal, CAB va fi compus dintr-un grup de persoane cu puncte de vedere, experiențe și domenii de expertiză diferite. Funcția lor este de a revizui schimbarea în funcție de proces și de perspectiva guvernării, pentru a se asigura că toate riscurile previzibile au fost identificate și reduse și că au fost adoptate soluții compensatorii pentru toate situațiile de proces expuse riscului. Echipa de dezvoltare și sponsorul de schimbare vor prezenta proiectul CAB. Punctul crucial va fi evaluarea riscurilor. Strategiile de punere în aplicare, comunicarea părților interesate, planurile de întrerupere și monitorizarea ulterioară punerii în aplicare sunt elementele pe care CAB își concentrează atenția. CAB nu are responsabilitatea de a determina dacă schimbarea este adecvată - această decizie a fost deja luată. De asemenea, CAB nu are responsabilitatea de a stabili dacă schimbarea este convenabilă. Încă o dată, aceasta este o decizie a conducerii superioare a companiei.

5

Implementați modificarea: în cazul în care cabinetul nu aprobă modificarea, enumeră motivele (acest lucru este aproape întotdeauna, deoarece anumite riscuri au fost reduse sau pentru că nu au fost planificate de comunicații) și atribuite echipei de dezvoltare un timp rezonabil pentru a rezolva problemele și să reeșaloneze o întâlnire cu CAB. Dacă modificarea este aprobată, implementarea este programată. În mod normal, CAB nu participă la faza de implementare, deși este posibil ca anumiți membri CAB să aibă abilitățile necesare în acest stadiu - în acest caz nu vor participa ca reprezentanți oficiali ai CAB, ci mai degrabă ca experți (IMM-uri). După implementarea modificării, sunt definite lista de verificare și pașii aprobați de CAB. Întregul proces de implementare trebuie să fie atent documentat, iar calea aprobată trebuie să fie urmată de scrisoare.

6

Relate Rezultate: schimbare poate fi pusă în aplicare cu succes fără probleme, sau cu probleme care au fost corectate în timpul implementazione- sau cu probleme care au fost considerate inacceptabile accettabili- sau întrebări pot fi ieșit la suprafață, iar schimbarea a fost interrotto- sau, în cel mai rău cazuri, schimbarea a fost pusă în aplicare cu probleme inacceptabile și nu poate fi întreruptă. Oricare ar fi rezultatul, acest lucru trebuie să fie documentat și prezentat CAB. BCC este, prin urmare, responsabil pentru comunicarea acestor informații către părțile interesate, atât arhivarea ambele rezultate de conservare în sistemul de management al schimbării (care poate fi o bază de date sau sistem de regăsire cartaceo- automatizat Cu toate acestea, documentele trebuie să fie păstrate pentru control).

7

Managementul problemelor legate de schimbarea legăturilor: problemele apărute trebuie comparate cu documentația CAB a modificărilor, astfel încât orice efecte negative neprevăzute ale unei schimbări pot fi izolate. Se întâmplă deseori ca efectele nedorite ale unei schimbări să nu fie observate imediat, dar sunt identificate prin apariția unor probleme în sistemele auxiliare. De exemplu, adăugarea de câmpuri multiple într-o bază de date ar putea să nu aibă un efect negativ direct asupra utilizatorilor, dar ar putea afecta performanța rețelei, făcând-o evidentă și altor utilizatori care nu sunt implicați direct în sistemul modificat.

8

Faceți auditul periodic al CMP: cel puțin o dată pe an, CMP ar trebui să fie auditat pentru a se asigura că toate documentele schimbării sunt păstrate și disponibile. Documentul de aprobare pentru fiecare modificare trebuie revizuit pentru a verifica dacă are semnăturile necesare și că rezultatele implementării sunt documentate corespunzător.