Elaborați un program de management al schimbării IT

"Trebuie să se țină cont de faptul că nu există nimic mai dificil sau îndoielnic pentru succes, chiar mai periculos decât introducerea unui lucru nou".

Un program de management al schimbării (CMP), cunoscută în mod obișnuit ca un proces de schimbare de control sau Process Change Management Control este un proces formal, care este utilizat pentru a se asigura că modificările în ceea ce privește un produs sau sistem să fie introdus într-un mod controlat și coordonat ( conform ISO 20000). CMP ar trebui să nu cu managementul schimbării organizaționale (OCM), care urmează să fie confundate, care se ocupă de impactul noilor procese de afaceri, inclusiv cele ale lansările de sistem și inițiative IT, modificări în structura organizatorică sau schimbările culturale din cadrul unei companii. Pe scurt, OCM se referă la oameni atunci când este vorba de schimbări.

Scopul CMP este de a minimiza impactul negativ al schimbărilor aduse sistemului informatic al unei companii prin utilizarea unui proces de control standardizat. Unele modificări nu sunt opționale. Dacă, de exemplu, schimbările standard de cod de bare trebuie să vă adaptați - în cazul în care se modifică o structură fiscală, trebuie să efectuați modificări. Cu toate acestea, toate schimbările de acest tip sunt supuse controlului.

Nu trebuie să li se permită niciodată să modifice ad-hoc sistemul sau procesele fără supraveghere. Această idee trebuie să provină de la conducerea superioară și, fără excepție, să fie transmisă tuturor celor din companie. În lipsa suportului de nivel superior, CMP este o pierdere de timp și bani. Cu suport adecvat, acest program vă salvează greșelile costisitoare în afaceri.

2

Obțineți aprobarea pentru o modificare a afacerii: decizia de a face o schimbare este de obicei o decizie de afaceri care echilibrează costurile și beneficiile. Chiar și în situațiile în care schimbarea este strict legată de infrastructură (eșecul componentelor sau sistemului), decizia de a investi este în afaceri, nu în departamentul IT. Există ocazii în care procesele sunt dezvoltate în prealabil pentru a pre-autoriza schimbarea, cum ar fi, de ex. întreținerea sistemului de urgență, dar indiferent de perioada de autorizare, decizia rămâne în continuare la conducere.

3

Inițiați proiectul de dezvoltare: Evoluția schimbării (inclusiv testul) este o funcție condusă de IT. În cazul unei schimbări de urgență (serverul este defect), aceste funcții sunt de obicei predeterminate. Atunci când trebuie dezvoltat un nou sistem, există o colaborare între utilizatori și echipa IT. Sistemele sunt proiectate de IT, proiectul este lansat de partenerii de afaceri (utilizatori), dezvoltat de IT, testat de o combinație de IT și utilizatori, iar produsul final este lansat de ambele. O atenție deosebită trebuie acordată oricăror alte efecte pe care schimbarea le poate avea asupra sistemelor existente.

4

Existența Poștei de Management al Schimbărilor: Consiliul consultativ pentru schimbări (CAB) analizează toate modificările înainte de a intra în producție. De obicei, CAB este un grup de persoane cu perspective diferite, fundaluri și expertiză. Rolul lor este de a examina schimbarea din punct de vedere al procesului și de control pentru a se asigura că toate riscurile previzibile au fost identificate și atenuate și au fost utilizate ca tehnici de echilibrare pentru toate elementele periculoase (lucruri care ar putea merge prost). Echipa de dezvoltare și întreținerea schimbării prezintă schimbarea la CAB. Accentul se pune pe estimarea riscurilor. Strategiile de punere în aplicare, comunicarea cu acționarii afectați, planurile de rezervă și monitorizarea ulterioară punerii în aplicare sunt elemente pe care trebuie să se concentreze CAB. CAB este nu responsabil pentru a determina dacă schimbarea este adecvată - această decizie a fost deja luată. CAB nu este, de asemenea, responsabil pentru a determina dacă schimbarea este rentabilă. Din nou, aceasta este o decizie strictă de afaceri.

5

Implementați modificarea: În cazul în care OEC nu eliberează schimbarea, motivele sunt enumerate (acest lucru este întotdeauna că anumite riscuri nu au fost atenuate sau de comunicare nu a fost planificat), iar echipa de dezvoltare devine timp pentru a rezolva aceste probleme și să cadă de acord asupra unei noi reuniuni cu CAB . Când schimbarea este lansată, implementarea este programată. Nu este de obicei cazul în care OEC este reprezentat în punerea în aplicare, chiar dacă este posibil ca unii membri ai cabinetului au expertiza necesară pentru a pune în aplicare, dar ele nu sunt în calitate de reprezentanți oficiali ai CAB, ci ca o Tema Expert (IMM) să fie reprezentat. Odată cu modificarea, lista de verificare și pașii sunt predeterminate și au fost prezentate și aprobate de CAB. Întregul proces trebuie documentat cu grijă și procesul aprobat trebuie urmărit cu atenție.

6

Raportați rezultatele: Fie schimbarea a fost implementată cu succes fără probleme, schimbarea a fost pusă în aplicare cu privire la problemele care au fost corectate în timpul punerii în aplicare, modificarea a fost pusă în aplicare cu privire la problemele care au fost considerate a fi acceptabile, a avut loc probleme care nu au fost acceptabile, și a fost efectuat rollback modificarea sau, în cel mai rău caz, schimbarea a fost efectuată cu probleme inacceptabile și nu a putut fi derulată înapoi. Oricare ar fi rezultatul, acesta va fi documentat și raportat înapoi la CAB. BCC este responsabil pentru distribuirea acestor informații către acționari și pentru stocarea și menținerea acestor rezultate în sistemul de management al schimbării (acest lucru poate fi fie o bază de date automat sau un sistem de evidență de hârtie, dar documentele trebuie să fie obținute pentru audituri).

7

Conectați gestionarea problemelor la schimbări: Orice probleme care apar vor fi comparate cu documentarea schimbării în CAB, astfel încât orice efecte adverse neașteptate ale unei schimbări să poată fi izolate. Este adesea cazul în care efectele nedorite ale unei schimbări nu sunt observate imediat, dar sunt identificate prin apariția unor probleme în sisteme suplimentare. Ar putea, de ex. adăugând că adăugarea câmpurilor multiple într-o bază de date nu va avea un impact negativ direct asupra utilizatorilor, ci va afecta performanța rețelei, ceea ce ar atrage atenția asupra altor utilizatori care nu sunt implicați direct în sistemul modificat.

8

Auditul periodic al CMP: Cel puțin o dată pe an, ar trebui efectuat un audit al CMP pentru a se asigura că întreaga documentație a modificărilor este menținută și disponibilă. Fiecare document de lansare al schimbării trebuie examinat pentru a se asigura că există semnături corecte și că rezultatele implementării sunt documentate corespunzător.