Change Management (lett. "gestione del cambiamento") è una disciplina dell'IT Service Management che si interessa dei cambiamenti nell'infrastruttura IT.Tali cambiamenti possono essere: la conseguenza di una reazione attuata in risposta ad un problema, imposti esternamente (ad es. per cambiamenti legislativi), 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 l'impatto potenzialmente dannoso del cambiamento stesso.

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 l'impatto 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 all'interno dell'organizzazione, 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 l'ITSM, 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: Hardware Apparati di comunicazione e software Sistemi software Tutta la documentazione e le procedure legate alla gestione, supporto e manutenzione dell'ambiente di produzione. Sarà quindi il processo di change management che dovrà fornire l'approvazione ad ogni richiesta di cambiamento. L'organo che ha l'autorità 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.

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 è l'unico meccanismo previsto da ITIL per richiedere un cambiamento all'infrastruttura. 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: Risoluzione di un Incident o di un Problem; Insoddisfazione di un cliente su un servizio (attraverso il SLM); Introduzione, upgrade o rimozione di un CI (Configuration Item); Cambiamenti in seguito a richieste del business; Spostamenti di sede; Cambiamenti legislativi; Cambiamenti di prodotti o servizi da parte di fornitori.

Change Manager

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

Change Advisory Board (CAB)

I compiti principali dei membri del CAB sono elencati di seguito: Analizzare tutte le RFC che vengono proposte in sede di CAB, determinandone gli impatti e le risorse necessarie per l'implementazione. Partecipare a tutti i meeting del CAB, esprimendo il proprio parere sui change in agenda al fine di autorizzarne l'esecuzione. Nel caso di CAB convocati per EC (Emergency Change) essere disponibili per una consultazione.

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

Change Executor, coloro che sono coinvolti nell'attività di implementazione della RFC.

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

Forward Schedule of Changes (FSC)

L'FSC o calendario dei cambiamenti è un output del processo, contiene i dettagli e la pianificazione di tutti i Change approvati. L'FSC è utilizzato per consentire a tutti i gruppi coinvolti di pianificare i propri rilasci. L'FSC 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 l'organizzazione. Un modello è definito in relazione a tipo, gravità, impatto o più in generale in relazione a delle variabili definite dall'organizzazione. 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.

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 l'implementazione di un Change:

Proposta

Ogni membro dell'organizzazione dovrebbe essere autorizzato a richiedere un cambiamento, questo consente di incoraggiare l'innovazione e di far emergere potenziali problemi. Gli IT Competence Center potranno avere un accesso diretto all'inserimento 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 Significant Major Ovviamente questo sono le categorie definite dalle best practice, ogni organizzazione può poi definire la categorizzazione più appropriata per la propria struttura.

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 nell'ambiente 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: Tecnico, che è parte del processo di Service Support Finanziario 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 l'approvazione potrà essere in carico al Change Manager stesso, al CAB oppure demandata ad un Executive Team. Concluso il processo di approvazione è possibile passare all'esecuzione del Change.

Esecuzione

Scopo della fase di “Esecuzione” e quello di gestire e coordinare le implementazioni richieste dalla RFC, al fine di rilasciarle nell'ambiente 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.

Chiusura Scopo della fase di “Chiusura “ o Reviewed è quello di confermare il buon esito dell'implementazione 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.

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 un'informazione aggiornata, accurata e comprensibile di tutti i componenti dell'infrastruttura la gestione del cambiamento sarà più efficace ed efficiente.

Con Configuration Management si intende l'implementazione di un database (Configuration Management Database- CMDB), che contenga il dettaglio di tutti gli elementi dell'organizzazione (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 i CI e i servizi erogati. Questa gamma di informazioni comprende: Hardware Software Documentazione Personale

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 l'analisi di un Incident attraverso il Problem Management potrebbe portare alla creazione di una RFC, o ancora l'errata implementazione di un Change potrebbe generare un Incident. Sono quindi molteplici gli scenari e i flussi di interrelazione tra i tre processi. È importante definire all'interno dell'organizzazione le metodologie con cui questi processi interagiranno.

Capacity Management