Change management (IT service management)

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:

Timeline del processo di change management

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

Una proposta di change potrebbe essere generata per assicurare che un'adeguata 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 dell'impatto 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 l'esecuzione di un Change continua a fallire impattando la disponibilità dei servizi. Dal canto suo il Change Management assiste l'ITCM nel mantenere aggiornato il piano di continuità e assicura che i siti di disaster recovery siano mantenuti allineati all'infrastruttura operativa.

Financial Management

È coinvolto nella valutazione degli impatti finanziari di una RFC.

Service Desk

Il Service Desk è coinvolto per fornire supporto durante l'implementazione del Change. Si occupa inoltre di informare gli utenti in merito all'esecuzione dei Change e in merito ad eventuali interruzioni di servizio secondo quanto riportato nell'FSC.

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 e le regole. Di seguito è riportato un esempio di integrazione tra i processi:

Esempio di relazione tra change management e project management

Possibili Problemi

Il processo di change management che viene implementato dovrebbe essere appropriato per le dimensioni dell'organizzazione. Infatti un processo altamente burocratizzato potrebbe portare all'inefficienza del processo stesso. Possibili problemi potrebbero venire dalla difficoltà legate al cambio culturale che l'introduzione 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 è l'educazione, 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 all'infrastruttura. La conoscenza delle informazioni relative ai legami tra le varie componenti dell'infrastruttura 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:

• 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
• Implementare un controllo costante di tutti i CI (Configuration Item) e delle loro versioni.
• Costante aggiornamento del personale coinvolto nell'IT 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:

• Quando non è chiaramente definito chi è competente sui sistemi impattati, si possono effettuare valutazioni del Change tardive e incomplete
• Se il Change Management viene implementato senza il Configuration Management, la soluzione sarà sicuramente meno efficace
• 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
• Spesso le procedure di back-out sono assenti o non testate
• Il processo spesso fallisce quando dei Change in emergenza devono essere effettuati

Costi, Benefici

Benefici

Una gestione efficiente dei servizi richiede l'abilità di cambiare le cose in modo ordinato, senza fare errori e prendendo le giuste decisioni. Un'efficace 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:

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

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 all'impegno dei membri del CAB. Quando si effettua la stima di questi costi, per valutare la convenienza dell'implementazione di un processo strutturato di change management, non bisogna dimenticarsi del fatto che molto probabilmente all'interno dell'organizzazione 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à l'integrazione tra i vari processi dell'ITSM. Bisogna però considerare che nelle organizzazioni di ampie dimensioni, la gestione di questi processi, diventa praticamente impossibile senza dei tool di supporto fortemente integrati.

Bibliografia

• Office of Government Commerce (OGC) – Service Support Book - TSO (The Stationery Office)
• Office of Government Commerce (OGC) – Service Transition Book - TSO (The Stationery Office)
• Hewlett–Packard Development Company - ITIL Service Manager for Service Sapport