Indietro

ⓘ Change Management (ITSM)




                                     

ⓘ Change Management (ITSM)

Change Management è una disciplina dellIT Service Management che si interessa dei cambiamenti nellinfrastruttura IT. Tali cambiamenti possono essere: la conseguenza di una reazione attuata in risposta ad un problema, imposti esternamente, realizzati proattivamente per cercare di raggiungere livelli imposti di efficienza ed efficacia, per attuare iniziative a supporto del business, o ancora da programmi, progetti o iniziative per il miglioramento dei servizi. Il change management può assicurare un opportuno bilanciamento tra il bisogno di cambiamento e limpatto potenzialmente dannoso del cambiamento stesso.

                                     

1. Obiettivi

Obiettivo del Change Management è assicurare che metodi e procedure standard vengano utilizzati per una efficiente e pronta gestione di tutti i cambiamenti applicativi e di infrastruttura IT, al fine di minimizzare limpatto e gli incidenti in capo ai servizi erogati. È particolarmente importante che il processo di Change Management abbia una buona visibilità e canali di comunicazione aperti allinterno dellorganizzazione, in modo da favorire una transizione fluida quando un cambiamento viene posto in essere.

Le best practice ITIL suggeriscono di pianificare e implementare il processo di" Change Management” contestualmente al processo di" Configuration Management”. Stessa considerazione è presente anche nella documentazione ISO 20000 dove i due processi fanno parte dei cosiddetti" Control Processes”.

Bisogna inoltre considerare che i confini del change management possono andare oltre lITSM, infatti il processo è utilizzato ogni qualvolta si debba introdurre cambiamenti, è quindi un processo utilizzato anche per la realizzazione di programmi o progetti. Il Change Management è responsabile della gestione del cambiamento che coinvolge tutti i sistemi IT, come ad esempio:

  • Apparati di comunicazione e software
  • Sistemi software
  • Hardware
  • Tutta la documentazione le procedure legate alla gestione, supporto e manutenzione dellambiente di produzione.

Sarà quindi il processo di change management che dovrà fornire lapprovazione ad ogni richiesta di cambiamento. Lorgano che ha lautorità per prendere la decisione è il Change Advisory Board CAB, il quale è principalmente costituito da membri rappresentanti le diverse funzioni aziendali. È inoltre importante notare come il processo di" Configuration Management” sia responsabile di fornire le informazioni relative a possibili implicazioni derivanti dalla richiesta di cambiamento.

                                     

2. Elementi Chiave e Attori

Per una visione complessiva delle attività del processo di Change Management si espongono di seguito gli elementi chiave e gli attori coinvolti nel processo.

Request for Change RFC

La RFC è lunico meccanismo previsto da ITIL per richiedere un cambiamento allinfrastruttura. La RFC deve contenere tutte le informazioni necessarie affinché un cambiamento possa essere valutato, approvato e implementato. Tra i motivi per i quali può essere richiesta una RFC, si trovano:

  • Cambiamenti legislativi;
  • Spostamenti di sede;
  • Cambiamenti di prodotti o servizi da parte di fornitori.
  • Introduzione, upgrade o rimozione di un CI Configuration Item;
  • Cambiamenti in seguito a richieste del business;
  • Risoluzione di un Incident o di un Problem;
  • Insoddisfazione di un cliente su un servizio attraverso il SLM;

Change Manager

I compiti principali del change manager, alcuni dei quali possono essere delegati, sono i seguenti:

  • Chiudere le RFC
  • Cooperare con tutte le strutture coinvolte per coordinarne limplementazione e i test secondo la pianificazione definita
  • Decidere quali sono le persone che è opportuno invitare al meeting
  • Analizzare tutti i change per individuare eventuali trend in atto o problemi emergenti
  • Ricevere, tracciare e, insieme ai Change Initiator, assegnare la priorità a tutte le RFC. Rigettare subito le richieste impraticabili;
  • Presiedere a tutti i CAB meeting
  • Predisporre tutte le RFC da presentare al CAB, definirne lagenda e fornire anticipatamente a tutti i membri la lista di RFC in modo che possano effettuare delle valutazioni preliminari.
  • Convocare in caso di urgenza un Emergency CAB
  • Produrre dei report regolari e accurati da presentare al management
  • Verificare tutti i change eseguiti per assicurarsi che si sono raggiunti gli obiettivi prefissati

Change Advisory Board CAB

I compiti principali dei membri del CAB sono elencati di seguito:

  • Nel caso di CAB convocati per EC Emergency Change essere disponibili per una consultazione.
  • Partecipare a tutti i meeting del CAB, esprimendo il proprio parere sui change in agenda al fine di autorizzarne lesecuzione.
  • Analizzare tutte le RFC che vengono proposte in sede di CAB, determinandone gli impatti le risorse necessarie per limplementazione.

Change Initiator ovvero colui che fisicamente scatena il processo inserendo la RFC.

Change Executor, coloro che sono coinvolti nellattività di implementazione della RFC.

Di seguito vengono illustrati due importanti documenti del processo di Change Management:

Forward Schedule of Changes FSC

LFSC o calendario dei cambiamenti è un output del processo, contiene i dettagli e la pianificazione di tutti i Change approvati. LFSC è utilizzato per consentire a tutti i gruppi coinvolti di pianificare i propri rilasci. LFSC deve avere una schedulazione dettagliata per il breve periodo, e una pianificazione di massima per il lungo periodo. Deve inoltre contenere, quando previsti, i periodi di downtime da comunicare agli utilizzatori.

Projected Service Availability PSA

Il PSA è un documento utilizzato dal Change Management per delineare gli effetti del cambiamento sui livelli di disponibilità definiti nei Service Level Agreement SLA. Questo documento è collegato al FSC. Entrambi questi documenti vengono concordati con cliente, Service Desk e Availability Management. Il Service Desk avrà il compito di comunicare i downtime pianificati agli utenti.

Change Model

Un Change Model è una categoria di RFC per la quale è stato predefinito uno specifico percorso, tale percorso di implementazione del Change è definito dal Change Management in accordo con lorganizzazione. Un modello è definito in relazione a tipo, gravità, impatto o più in generale in relazione a delle variabili definite dallorganizzazione. Ad esempio si può decidere che alcuni tipi di Change, con un impatto marginale, non debbano essere autorizzati dal CAB, ma possano essere approvati direttamente dal responsabile diretto del Change Initiator.

                                     

3. Il Processo

Ora che si sono visti gli elementi chiave e gli attori coinvolti dal processo di Change Management si espone come interagiscono tra di loro e quali sono le attività peculiari del change. Di seguito un esempio delle attività necessarie per limplementazione di un Change:

                                     

3.1. Il Processo Proposta

Ogni membro dellorganizzazione dovrebbe essere autorizzato a richiedere un cambiamento, questo consente di incoraggiare linnovazione e di far emergere potenziali problemi. Gli IT Competence Center potranno avere un accesso diretto allinserimento di RFC, mentre si suggerisce di far transitare le richieste di utenti e clienti da una struttura in grado di filtrarle, come ad esempio i manager di prima linea o una struttura di Demand Management. Primo compito del Change Manager, come già illustrato, è quello di filtrare tutte le RFC rigettando quelle inapplicabili, dopodiché verificare se sono presenti Emergency Change a cui dare priorità applicando le procedure per i Change in emergenza o RFC che rientrano in predefiniti Change Model. Per le RFC residue dovrà definire la categoria di appartenenza, ITIL identifica 3 categorie di base in relazione a impatto atteso e risorse richieste:

  • Minor
  • Major
  • Significant

Ovviamente questo sono le categorie definite dalle best practice, ogni organizzazione può poi definire la categorizzazione più appropriata per la propria struttura.



                                     

3.2. Il Processo Approvazione

Scopo della fase di" Approvazione” è la discussione e valutazione di tutte le proposte di cambiamento proposte dai centri di competenza, al fine di evitare il verificarsi di effetti indesiderati nellambiente di produzione. Il livello di approvazione del cambiamento dovrebbe essere legato al livello di rischio del change. Per garantire la valutazione di impatto, costi, benefici e rischi ci sono tre processi di approvazione:

  • Finanziario
  • Tecnico, che è parte del processo di Service Support
  • Business, che è parte del processo di Demand Management e consiste nello sviluppo di giustificazioni di business al cambiamento.

In base alla categoria definita dal Change Manager lapprovazione potrà essere in carico al Change Manager stesso, al CAB oppure demandata ad un Executive Team. Concluso il processo di approvazione è possibile passare allesecuzione del Change.

                                     

3.3. Il Processo Esecuzione

Scopo della fase di" Esecuzione” e quello di gestire e coordinare le implementazioni richieste dalla RFC, al fine di rilasciarle nellambiente di produzione. È necessario porre un adeguato livello di attenzione quando si implementa il Change per evitare impatti indesiderati sui servizi erogati. Due aspetti importanti che spesso si tende a trascurare sono: la fase di test -per la quale occorre definire un piano dettagliato e ove possibile farla eseguire anche da un tester indipendente- e il back-out, ovvero la procedura da seguire per annullare il change e ritornare alla configurazione iniziale. La tendenza è infatti quella di definire scrupolosamente il piano di migrazione e i rischi associati al cambiamento, ponendo scarsa attenzione alla procedura di test e ritorno alla configurazione iniziale.

                                     

3.4. Il Processo Chiusura

Scopo della fase di" Chiusura" o Reviewed è quello di confermare il buon esito dellimplementazione della RFC. Tutte le RFC andrebbero verificate dopo un periodo predefinito per assicurarsi che siano stati raggiunti gli effetti desiderati e che le risorse utilizzate siano state stimate accuratamente. Infine il Change Manager deve assicurarsi che tutta la documentazione sia stata aggiornata.

                                     

4. Relazione con altri processi

Il change management non è un processo stand alone ma fa parte di un framework più articolato. Occorre quindi comprendere quali sono le relazioni con gli altri processi.

Configuration Management

Change Management e Configuration Management sono in stretto legame. Infatti soltanto con uninformazione aggiornata, accurata e comprensibile di tutti i componenti dellinfrastruttura la gestione del cambiamento sarà più efficace ed efficiente.

Con Configuration Management si intende limplementazione di un database Configuration Management Database- CMDB, che contenga il dettaglio di tutti gli elementi dellorganizzazione Configuration Item – CI che sono utilizzati per erogare e gestire i servizi IT. È più di un semplice registro delle risorse, contiene informazioni relative alla manutenzione e ai problemi verificatesi sui CI. Il CMDB contiene inoltre una vasta gamma di informazioni e relazioni tra CI e i servizi erogati. Questa gamma di informazioni comprende:

  • Hardware
  • Software
  • Personale
  • Documentazione

Incident Management & Problem Management

Cè uno stretto legame tra questi due processi e il change management. Nuove richieste di Change possono derivare dalle modifiche richieste per ripristinare la disponibilità del servizio in seguito ad un Incident, oppure lanalisi di un Incident attraverso il Problem Management potrebbe portare alla creazione di una RFC, o ancora lerrata implementazione di un Change potrebbe generare un Incident. Sono quindi molteplici gli scenari e i flussi di interrelazione tra i tre processi. È importante definire allinterno dellorganizzazione le metodologie con cui questi processi interagiranno.

Capacity Management

Una proposta di change potrebbe essere generata per assicurare che unadeguata capacità sia disponibile. Queste RFC sono soggette al processo di Change Management e la loro esecuzione potrebbe coinvolgere differenti CI. Viceversa il Capacity Management può coinvolto per valutare tutti i change, per stabilire gli effetti su capacità e performance di erogazione dei servizi.

Availability Management

Viene coinvolto per la valutazione dellimpatto dei Change sulla disponibilità dei Servizi. In particolare è ingaggiato per la produzione di FSC e PSA.

IT Service Continuity Management

Interagisce con il Change Management per valutare i requisiti di recovery dei Change, può inoltre essere invocato se lesecuzione di un Change continua a fallire impattando la disponibilità dei servizi. Dal canto suo il Change Management assiste lITCM nel mantenere aggiornato il piano di continuità e assicura che i siti di disaster recovery siano mantenuti allineati allinfrastruttura operativa.

Financial Management

È coinvolto nella valutazione degli impatti finanziari di una RFC.

Service Desk

Il Service Desk è coinvolto per fornire supporto durante limplementazione del Change. Si occupa inoltre di informare gli utenti in merito allesecuzione dei Change e in merito ad eventuali interruzioni di servizio secondo quanto riportato nellFSC.

Service Level Management

Fornisce al Change Management la lista dei service level concordati in modo da classificare correttamente i Change.

Program/Project Management

Il change management ha relazioni anche con i processi di Program/Project management. Occorre definire in maniera chiara i confini, le dipendenze le regole. Di seguito è riportato un esempio di integrazione tra i processi:



                                     

4.1. Relazione con altri processi Possibili Problemi

Il processo di change management che viene implementato dovrebbe essere appropriato per le dimensioni dellorganizzazione. Infatti un processo altamente burocratizzato potrebbe portare allinefficienza del processo stesso. Possibili problemi potrebbero venire dalla difficoltà legate al cambio culturale che lintroduzione del processo genera nel personale, nei clienti e negli utenti. Non è facile far comprendere ad ognuno che uno e soltanto un sistema di change management dovrà essere adottato. Un altro aspetto fondamentale è leducazione, ovvero far comprendere a tutti che solo attraverso questi sistemi ed in particolare grazie al CMDb è possibile comprendere le relazioni e gli impatti di ogni cambiamento allinfrastruttura. La conoscenza delle informazioni relative ai legami tra le varie componenti dellinfrastruttura e i servizi erogati è importante, perché solo in questo modo chi porrà in essere il cambiamento avrà chiari i potenziali impatti della sua manovra sui servizi.

Per evitare che i problemi sopra descritti si presentino, potrebbe essere utile:

  • Implementare un controllo costante di tutti CI Configuration Item e delle loro versioni.
  • Condurre regolarmente delle verifiche indipendenti, con lo scopo di controllare che il team di Change Management e in generale del Service Management, nonché gli utenti tengano un comportamento in linea con le procedure di Change Management
  • Attraverso il Service Desk rilevare utenti che utilizzano apparati o software non presenti nel CMDb
  • Costante aggiornamento del personale coinvolto nellIT Service Management

La pubblicazione BSI" A code of practice for IT Service Management” riporta inoltre una serie di punti che andrebbero considerati come potenziali problemi e che se opportunamente indirizzati potrebbero trasformarsi in benefici:

  • Se il Change Management viene implementato senza il Configuration Management, la soluzione sarà sicuramente meno efficace
  • Il processo spesso fallisce quando dei Change in emergenza devono essere effettuati
  • Quando non è chiaramente definito chi è competente sui sistemi impattati, si possono effettuare valutazioni del Change tardive e incomplete
  • Spesso le procedure di back-out sono assenti o non testate
  • Se il processo è troppo burocratico darà delle scuse per non applicarlo
  • Dati non accurati nel CMDB possono portare a valutazioni non corrette degli impatti e al coinvolgimento delle persone sbagliate
                                     

5.1. Costi, Benefici Benefici

Una gestione efficiente dei servizi richiede labilità di cambiare le cose in modo ordinato, senza fare errori e prendendo le giuste decisioni. Unefficace gestione del cambiamento è indispensabile per una fornitura di servizi soddisfacente, in grado di assorbire una quantità elevata di cambiamenti. Benefici specifici derivanti da un efficace implementazione del processo di Change Management sono:

  • minor impatto negativo dei cambiamenti sulla qualità dei servizi e sugli SLA livelli di servizio
  • miglior percezione dellIT da parte del business grazie ad una maggiore qualità dei servizi e ad un approccio professionale
  • miglior valutazione dei costi del cambiamento prima che vengano effettuati
  • miglior allineamento tra i servizi IT le esigenze di business
  • maggior visibilità e comunicazione dei cambiamenti sia da parte del business che da parte del service support
  • minor numero di cambiamenti per cui sarà necessario il back-out
  • maggior capacità di gestire ampi volumi di change
  • miglior valutazione del rischio
  • maggior produttività degli utenti, grazie ad una diminuzione dei disservizi e ad una maggiore qualità dei servizi erogati


                                     

5.2. Costi, Benefici Costi

Le due principali voci di costo del Change Management sono quelle per il personale e per i software di supporto.

Costi Personale Sono i costi relativi al personale coinvolto nel team di gestione del processo di Change Management, nonché i costi relativi allimpegno dei membri del CAB. Quando si effettua la stima di questi costi, per valutare la convenienza dellimplementazione di un processo strutturato di change management, non bisogna dimenticarsi del fatto che molto probabilmente allinterno dellorganizzazione ci sono già un numero di persone impegnate a seguire, in modo non strutturato, il processo di cambiamento.

Tool di supporto È importante considerare i costi relativi allo sviluppo dei tool nonché il costo relativo ai requisiti hardware. Il costo dei tool sarà maggiore quanto maggiore sarà lintegrazione tra i vari processi dellITSM. Bisogna però considerare che nelle organizzazioni di ampie dimensioni, la gestione di questi processi, diventa praticamente impossibile senza dei tool di supporto fortemente integrati.