Managementul schimbării (ITSM)

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare

Managementul schimbării (lit. „managementul schimbării”) este o disciplină de gestionare a serviciilor IT care se ocupă de schimbările din infrastructura IT .
Aceste modificări pot fi: consecința unei reacții implementate ca răspuns la o problemă, impusă extern (de exemplu, din cauza modificărilor legislative), efectuată proactiv pentru a încerca să atingă nivelurile impuse de eficiență și eficacitate, pentru a implementa inițiative care să susțină afacerea sau din nou din programe, proiecte sau inițiative pentru îmbunătățirea serviciilor.
Managementul schimbării poate asigura un echilibru adecvat între necesitatea schimbării și impactul potențial dăunător al schimbării în sine.

Obiective

Obiectivul managementului schimbării este de a se asigura că metodele și procedurile standard sunt utilizate pentru o gestionare eficientă și promptă a tuturor aplicațiilor și a modificărilor infrastructurii IT, pentru a minimiza impactul și incidentele asupra serviciilor furnizate. Este deosebit de important ca procesul de management al schimbării să aibă o vizibilitate bună și să deschidă canale de comunicare în cadrul organizației, pentru a facilita o tranziție lină atunci când are loc o schimbare.

Cele mai bune practici ITIL sugerează planificarea și implementarea procesului „Managementul schimbării” în același timp cu procesul „ Managementul configurației ”. Aceeași considerație este prezentă și în documentația ISO 20000 în care cele două procese fac parte din așa-numitele „Procese de control”.

De asemenea, trebuie luat în considerare faptul că limitele managementului schimbării pot depăși ITSM, de fapt procesul este utilizat ori de câte ori trebuie introduse modificări, prin urmare este un proces utilizat și pentru implementarea programelor sau proiectelor . Managementul schimbării este responsabil pentru gestionarea schimbărilor care implică toate sistemele IT, cum ar fi:

  • Hardware
  • Echipamente și software de comunicații
  • Sisteme software
  • Toată documentația și procedurile legate de gestionarea, suportul și întreținerea mediului de producție.

Prin urmare, procesul de gestionare a modificărilor va trebui să ofere aprobare pentru fiecare cerere de modificare. Organul care are autoritatea de a lua decizia este Consiliul consultativ pentru schimbări (CAB), care este format în principal din membri care reprezintă diferitele funcții ale companiei. De asemenea, este important să rețineți că procesul de „gestionare a configurației” este responsabil pentru furnizarea de informații cu privire la posibilele implicații care decurg din cererea de modificare.

Elemente cheie și actori

Pentru o imagine de ansamblu a activităților procesului de gestionare a schimbării, elementele cheie și actorii implicați în proces sunt prezentate mai jos.

Cerere de modificare (RFC)

RFC este singurul mecanism furnizat de ITIL pentru a solicita o modificare a infrastructurii. RFC trebuie să conțină toate informațiile necesare pentru ca o modificare să fie evaluată, aprobată și implementată. Printre motivele pentru care se poate solicita un RFC se numără:

  • Rezolvarea unui incident sau a unei probleme;
  • Nemulțumirea unui client cu un serviciu (prin SLM);
  • Introducerea, actualizarea sau eliminarea unui CI (Element de configurare);
  • Modificări în urma cererilor de afaceri;
  • Mișcări ale sediului;
  • Modificări legislative;
  • Modificări ale produselor sau serviciilor de către furnizori.

Manager schimbări

Sarcinile principale ale managerului de schimbare, dintre care unele pot fi delegate, sunt următoarele:

  • Primiți, urmăriți și, împreună cu inițiatorii schimbării, acordați prioritate tuturor RFC-urilor. Respingeți imediat cererile impracticabile;
  • Pregătiți toate RFC-urile pentru a fi trimise CAB, definiți-le agenda și oferiți tuturor membrilor lista RFC-urilor în avans, astfel încât să poată face evaluări preliminare.
  • Decideți ce persoane ar trebui să fie invitate la întâlnire
  • Apelați un CAB de urgență în caz de urgență
  • Președinte la toate ședințele CAB
  • Cooperează cu toate structurile implicate pentru a coordona implementarea și testarea conform programului definit
  • Verificați toate modificările făcute pentru a vă asigura că obiectivele stabilite au fost atinse
  • Analizați toate modificările pentru a identifica tendințele în curs sau problemele emergente
  • Închideți RFC-urile
  • Produceți rapoarte regulate și precise pentru a le prezenta conducerii

Comitetul consultativ pentru schimbări (CAB)

Principalele atribuții ale membrilor CAB sunt enumerate mai jos:

  • Analizați toate RFC-urile propuse în CAB, determinând impactul acestora și resursele necesare implementării.
  • Participă la toate ședințele CAB, exprimându-și opinia cu privire la modificările de pe ordinea de zi pentru a autoriza executarea acestora.
  • În cazul CAB-urilor solicitate pentru CE (Schimbare de urgență), fiți disponibile pentru consultare.

Change Initiator sau cel care declanșează fizic procesul prin inserarea RFC.

Executor schimbare , cei implicați în activitatea de implementare RFC.

Două documente importante ale procesului de gestionare a schimbărilor sunt ilustrate mai jos:

Programul de schimbări înainte (FSC)

FSC sau programul modificărilor este un rezultat al procesului, acesta conține detaliile și programul tuturor modificărilor aprobate. FSC este utilizat pentru a permite tuturor grupurilor implicate să-și planifice propriile versiuni. FSC trebuie să aibă un program detaliat pe termen scurt și un program dur pe termen lung. De asemenea, trebuie să conțină, atunci când este prevăzut, perioadele de nefuncționare care trebuie comunicate utilizatorilor.

Disponibilitatea serviciului proiectat (PSA)

PSA este un document utilizat de Managementul schimbărilor pentru a evidenția efectele schimbării asupra nivelurilor de disponibilitate definite în acordurile de nivel de serviciu (SLA). Acest document este legat de FSC. Ambele documente sunt convenite cu clientul, biroul de service și managementul disponibilității. Biroul de service va fi responsabil pentru comunicarea timpilor de nefuncționare planificați utilizatorilor.

Schimbați modelul

Un model de schimbare este o categorie de RFC-uri pentru care a fost predefinită o cale specifică, această cale de implementare a modificării este definită de Managementul schimbărilor în conformitate cu organizația. Un model este definit în raport cu tipul, severitatea, impactul sau mai general în raport cu variabilele definite de organizație. De exemplu, se poate decide că unele tipuri de schimbări, cu impact marginal, nu trebuie autorizate de CAB, ci pot fi aprobate direct de către managerul direct al inițiatorului schimbării.

Procesul

Acum că am văzut elementele cheie și actorii implicați în procesul de gestionare a schimbării, explicăm modul în care interacționează între ei și care sunt activitățile specifice schimbării. Mai jos este un exemplu de activități necesare pentru implementarea unei schimbări:

Cronologia procesului de gestionare a schimbărilor

Propunere

ChangeManagementProposta.jpg

Fiecare membru al organizației ar trebui să aibă permisiunea de a solicita o schimbare, ceea ce permite să încurajeze inovația și să scoată în evidență potențiale probleme. Centrele de competențe IT vor putea avea acces direct la inserarea RFC-urilor, în timp ce se sugerează transmiterea cererilor utilizatorilor și clienților printr-o structură capabilă să le filtreze, cum ar fi managerii de linie frontală sau o structură de gestionare a cererii. Prima sarcină a Managerului de schimbări, așa cum este deja ilustrat, este de a filtra toate RFC-urile care le resping pe cele neaplicabile, apoi verificați dacă există modificări de urgență care trebuie să aibă prioritate prin aplicarea procedurilor pentru schimbarea de urgență sau RFC-uri care se încadrează în modelul de schimbare predefinit. . Pentru RFC reziduale va trebui să definească categoria căreia îi aparține, ITIL identifică 3 categorii de bază în raport cu impactul așteptat și resursele necesare:

  • Minor
  • Semnificativ
  • Major

Evident, acestea sunt categoriile definite de cele mai bune practici, fiecare organizație poate apoi defini cea mai adecvată categorizare pentru structura sa.

Aprobare

ChangeManagementAppapproval.jpg

Scopul fazei „Aprobare” este discutarea și evaluarea tuturor modificărilor propuse de centrele de competență, pentru a evita apariția efectelor nedorite în mediul de producție. Nivelul de aprobare a modificării ar trebui legat de nivelul de risc al schimbării. Pentru a asigura evaluarea impactului, costurilor, beneficiilor și riscurilor există trei procese de aprobare:

  • Tehnician, care face parte din procesul de asistență pentru servicii
  • Financiar
  • Business, care face parte din procesul de gestionare a cererii și constă în dezvoltarea justificărilor de afaceri pentru schimbare.

Pe baza categoriei definite de Managerul de schimbări, aprobarea poate fi în sarcina managerului de schimbări însuși, CAB sau delegată unei echipe executive. Odată ce procesul de aprobare a fost finalizat, este posibil să continuați cu executarea modificării.

Execuţie

ChangeManagementEsuzione.jpg

Scopul fazei „Executare” este de a gestiona și coordona implementările cerute de RFC, pentru a le lansa în mediul de producție. Este necesar să se acorde un nivel adecvat de atenție atunci când se implementează schimbarea pentru a evita impacturile nedorite asupra serviciilor furnizate. Două aspecte importante care deseori tind să fie trecute cu vederea sunt: ​​faza de testare - pentru care trebuie definit un plan detaliat și, acolo unde este posibil, să fie realizat de un tester independent - și retragerea sau procedura de urmat pentru anularea modificați și reveniți la configurația inițială. De fapt, tendința este de a defini scrupulos planul de migrație și riscurile asociate schimbării, acordând puțină atenție procedurii de testare și revenind la configurația inițială.

Închidere

Scopul fazei „Închidere” sau Revizuire este de a confirma implementarea cu succes a RFC. Toate RFC-urile ar trebui verificate după o perioadă predefinită pentru a se asigura că efectele dorite au fost realizate și că resursele utilizate au fost estimate cu exactitate. În cele din urmă, Managerul de schimbări trebuie să se asigure că toată documentația a fost actualizată.

Relația cu alte procese

Managementul schimbărilor nu este un proces autonom, ci face parte dintr-un cadru mai complex. Prin urmare, este necesar să înțelegem care sunt relațiile cu alte procese.

Managementul configurației

Gestionarea schimbărilor și gestionarea configurației sunt strâns legate. De fapt, doar cu informații actualizate, exacte și ușor de înțeles despre toate componentele infrastructurii, managementul schimbărilor poate fi mai eficient și mai eficient.

Prin Configuration Management ne referim la implementarea unei baze de date (Configuration Management Database - CMDB), care conține detaliile tuturor elementelor organizației (Configuration Item - CI) care sunt utilizate pentru furnizarea și gestionarea serviciilor IT. Este mai mult decât un jurnal de active, conține informații legate de întreținere și probleme care apar pe IC. CMDB conține, de asemenea, o gamă largă de informații și relații între IC și serviciile furnizate. Această gamă de informații include:

  • Hardware
  • Software
  • Documentație
  • Personal

Managementul incidentelor și gestionarea problemelor

Există o legătură strânsă între aceste două procese și gestionarea schimbărilor. Solicitările de modificare nouă pot proveni din modificările necesare pentru restabilirea disponibilității serviciului în urma unui incident sau analiza unui incident prin gestionarea problemelor ar putea duce la crearea unui RFC sau implementarea incorectă a unei modificări ar putea genera un incident. Prin urmare, există multe scenarii și fluxuri de corelații între cele trei procese. Este important să se definească în cadrul organizației metodologiile cu care vor interacționa aceste procese.

Managementul capacității

S-ar putea genera o propunere de modificare pentru a asigura disponibilitatea unei capacități adecvate. Aceste RFC sunt supuse procesului de gestionare a schimbărilor și executarea lor poate implica diferite IC. În schimb, Managementul capacității poate fi implicat pentru a evalua toate modificările, pentru a stabili efectele asupra capacității și performanței furnizării de servicii.

Managementul disponibilității

El este implicat în evaluarea impactului modificărilor asupra disponibilității Serviciilor. În special, este angajat pentru producția de FSC și PSA.

Managementul continuității serviciului IT

Acesta interacționează cu Managementul schimbării pentru a evalua cerințele de recuperare ale schimbării, poate fi invocat și dacă executarea unei modificări continuă să eșueze, afectând disponibilitatea serviciilor. La rândul său, Managementul schimbării asistă ITCM în menținerea actualizată a planului de continuitate și se asigură că site-urile de recuperare în caz de dezastru sunt menținute aliniate cu infrastructura operațională.

Management financiar

El este implicat în evaluarea impactului financiar al unui RFC.

Birou de servicii

Biroul de service este implicat pentru a oferi asistență în timpul implementării schimbării. De asemenea, se ocupă de informarea utilizatorilor cu privire la executarea modificărilor și cu privire la orice întrerupere a serviciului, așa cum este raportat în FSC.

Managementul nivelului de serviciu

Oferă Managementului Schimbării lista nivelurilor de servicii convenite pentru a clasifica corect Schimbarea.

Managementul programului / proiectului

Managementul schimbărilor are, de asemenea, relații cu procesele de management al programului / proiectului. Limitele, dependențele și regulile trebuie să fie clar definite. Mai jos este un exemplu de integrare între procese:

Exemplu de relație între managementul schimbării și managementul proiectelor

Probleme posibile

Procesul de gestionare a schimbărilor care este implementat ar trebui să fie adecvat pentru dimensiunea organizației. De fapt, un proces extrem de birocratic ar putea duce la ineficiența procesului în sine. Problemele posibile ar putea veni din dificultățile legate de schimbarea culturală pe care o generează introducerea procesului în personal, clienți și utilizatori. Nu este ușor să îi faci pe toți să înțeleagă că va trebui adoptat un singur sistem de management al schimbărilor. Un alt aspect fundamental este educația, adică să îi facă pe toți să înțeleagă că numai prin aceste sisteme și în special datorită CMDb este posibil să se înțeleagă relațiile și impactul oricărei modificări a infrastructurii. Cunoașterea informațiilor referitoare la legăturile dintre diferitele componente ale infrastructurii și serviciile furnizate este importantă, deoarece numai astfel cei care pun în aplicare schimbarea vor fi clari cu privire la impactul potențial al manevrei lor asupra serviciilor.

Pentru a preveni apariția problemelor descrise mai sus, ar putea fi util să:

  • Efectuați periodic audituri independente, cu scopul de a verifica dacă echipa de management al schimbării și managementul serviciilor în general, precum și utilizatorii, se comportă în conformitate cu procedurile de gestionare a schimbărilor
  • Prin Service Desk pentru a detecta utilizatorii care folosesc echipamente sau software care nu sunt prezente în CMDb
  • Implementați controlul constant al tuturor CI (Elementelor de configurare) și versiunilor acestora.
  • Actualizarea constantă a personalului implicat în managementul serviciilor IT

Publicația BSI „Un cod de practică pentru managementul serviciilor IT” raportează, de asemenea, o serie de puncte care ar trebui considerate ca fiind potențiale probleme și care, dacă sunt abordate în mod corespunzător, s-ar putea transforma în beneficii:

  • Atunci când nu este clar definit cine este competent în ceea ce privește sistemele afectate, pot fi efectuate evaluări ale modificărilor tardive și incomplete
  • Dacă Managementul schimbărilor este implementat fără Managementul configurației, soluția va fi cu siguranță mai puțin eficientă
  • Dacă procesul este prea birocratic, va oferi scuze pentru a nu-l aplica
  • Datele inexacte din CMDB pot duce la evaluări incorecte ale impactului și implicarea persoanelor greșite
  • Procedurile de retragere sunt adesea absente sau netestate
  • Procesul eșuează adesea atunci când trebuie făcute modificări de urgență

Costuri, beneficii

Beneficii

Gestionarea eficientă a serviciilor necesită abilitatea de a schimba lucrurile într-un mod ordonat, fără a greși și a lua deciziile corecte. Gestionarea eficientă a schimbărilor este imperativă pentru furnizarea de servicii satisfăcătoare, care poate absorbi o cantitate mare de schimbări. Beneficiile specifice care decurg dintr-o implementare eficientă a procesului de management al schimbării sunt:

  • o mai bună aliniere între serviciile IT și nevoile afacerii
  • o mai mare vizibilitate și comunicare a schimbărilor atât de către întreprindere, cât și de către serviciul de asistență
  • o mai bună evaluare a riscurilor
  • impact mai puțin negativ al schimbărilor asupra calității serviciilor și a SLA-urilor (niveluri de servicii)
  • o mai bună evaluare a costurilor schimbării înainte ca acestea să fie efectuate
  • mai puține modificări care vor necesita retrogradare
  • productivitate mai mare a utilizatorilor, datorită unei scăderi a ineficiențelor și a unei calități superioare a serviciilor furnizate
  • capacitate mai mare de a gestiona volume mari de modificări
  • o mai bună percepție a IT-ului de către companie datorită unei calități superioare a serviciilor și unei abordări profesionale

Cheltuieli

Cele două elemente de cost principale ale Managementului schimbării sunt cele pentru personal și software de asistență.

Costuri de personal Acestea sunt costurile aferente personalului implicat în echipa de conducere a procesului de management al schimbării, precum și costurile legate de angajamentul membrilor CAB. Atunci când estimăm aceste costuri, pentru a evalua comoditatea implementării unui proces structurat de management al schimbării, nu trebuie să uităm că cel mai probabil există deja un număr de persoane în cadrul organizației care se angajează să urmeze, în mod nestructurat, procesul de schimbare.

Instrumente de asistență Este important să se ia în considerare costurile dezvoltării instrumentelor, precum și costul cerințelor hardware. Costul instrumentelor va fi mai mare cu cât este mai mare integrarea între diferitele procese ITSM. Cu toate acestea, trebuie considerat că în organizațiile mari, gestionarea acestor procese devine practic imposibilă fără instrumente de sprijin puternic integrate.

Bibliografie

  • Office of Government Commerce (OGC) - Carte de asistență pentru servicii - TSO (Biroul de papetărie)
  • Office of Government Commerce (OGC) - Service Transition Book - TSO (The Stationery Office)
  • Hewlett - Compania de dezvoltare Packard - ITIL Service Manager pentru Service Sapport