9. Riprogettazione del processo
9.4. Definizione diverse categorie di Change
Major
9.4.1.
Un “Change Major” è un cambiamento con rilevanti ripercussioni su uno o più servizi e con importanti risvolti in termini di effort e di costi. Si tratta normalmente di cambiamenti ad elevata trasversalità, che coinvolge diversi Gruppi di Supporto.
Significant
9.4.2.
Un “Change Significant” è un cambiamento con sostanziali ripercussioni su uno o più servizi e con un impegno consistente in termini di effort e di costi. Si tratta normalmente di cambiamenti con una discreta trasversalità, che coinvolge diversi Gruppi di Supporto.
Minor
9.4.3.
Un “Change Minor” è un cambiamento con lievi o nessuna ripercussione sul servizio e ridotto impegno in termini di effort e di costi. Si tratta di cambiamenti a
80 bassa trasversalità, la cui realizzazione coinvolge esclusivamente o primariamente un Gruppo di Supporto specifico.
Standard
9.4.4.
Un “Change Standard” è un cambiamento diventato parte della pratica operativa, a basso costo e basso rischio, per il quale è definito un chiaro percorso di gestione e dei criteri predefiniti di accettazione della richiesta.
Emergency
9.4.5.
Un “Change Emergency” può essere un cambiamento fortemente prioritario per l’operatività del business. Il più delle volte si tratta di cambiamenti a basso costo ma che richiedono tempi di risposta brevissimi.
Bug
9.4.6.
Un “Change Bug” è da considerarsi la risoluzione ad un malfunzionamento che può essere più o meno prioritario per l’operatività del business.
81
Update
9.4.7.
Un “Change Update” è una modifica cha agisce esclusivamente sui dati su richiesta dell’utente business.
9.5. Change Ownership
Durante tutto il ciclo di vita della richiesta di cambiamento, l’owner responsabile della gestione della richiesta deve essere sempre chiaramente ed univocamente definito.
Ruolo dell’owner della richiesta
9.5.1.
L’owner ha la responsabilità di gestire la richiesta end-to-end svolgendo un ruolo di coordinamento e supervisione nei confronti degli attori organizzativi coinvolti nella realizzazione della richiesta
L’owner ha la responsabilità di gestire e coordinare opportunamente la comunicazione verso gli stakeholder interessati alla realizzazione della richiesta.
Categoria del Change come criterio di
9.5.2.
assegnazione della Ownership
– Per le Change categorizzate come Significant e Major l’owner del Change è il Change Manager.
82 – Per le Change categorizzate come Minor, Bug e Update, l’owner del Change è il Change Coordinator del Gruppo di Supporto principalmente interessato dalla Change.
– Il Change Coordinator può a sua volta delegare l’ownership di gestione del Change ad un membro del suo stesso Gruppo di Supporto in base a criteri di valutazione locali. L’esercizio locale della delega deve salvaguardare il rispetto delle procedure previste dal processo.
– Per le Change categorizzate come Standard, l’ownership è definita dal Change Model.
– Lungo tutto il ciclo di vita del Change qualsiasi valutazione che porti ad un cambiamento di categoria comporta un cambiamento automatico della ownership verso il ruolo appropriato.
9.6. Change Advisory Board
Ruolo del Change Advisory Board
9.6.1.
Il Change Advisory Board (CAB) ha il ruolo di supportare l’autorizzazione dei Change e di assistere il Change Management nelle fasi di assessment e priorizzazione dei Change. Il CAB è chiamato in alcuni casi (Change Significant) a valutare ed approvare le richieste di cambiamento mentre in altri (Change Major o progetti) a fornire raccomandazioni e valutazioni sul Change destinate a fornire supporto informativo alla Change Approval Authority appropriata per il livello di autorizzazione richiesto.
83
Composizione del Change Advisory Board
9.6.2.
I componenti del Change Advisory Board vanno scelti considerando la capacità di produrre (per tutti i Change sotto la giurisdizione del CAB) un adeguata valutazione del Change sia dal punto di vista del Business che dal punto di vista dell’IT.
La composizione dovrebbe vedere la presenza di alcuni membri permanenti ed in particolare (se i processi sono stati implementati) il Change Manager, il Release
Manager, il Configuration Manager, il Security Manager e il responsabile del Service Desk. I restanti membri vanno scelti in funzione della effettiva abilità
richiesta per la valutazione di ciascuna RfC e delle aree su cui impatta.
La selezione dei membri del CAB, per ciascuna RfC, ricade sotto la responsabilità del Change Manager.
Modalità e contenuti dei CAB meetings
9.6.3.
Gli incontri del CAB non richiedono necessariamente la presenza fisica dei partecipanti. È possibile avvalersi di opportuni strumenti o della semplice e-mail, fatti salvi quei casi in cui l’alto rischio o l’alto impatto richiedano la necessità di una convocazione formale. Una combinazione di incontri formali organizzati con cadenza regolare e appuntamenti asincroni realizzati attraverso l’ausilio di strumenti elettronici rappresenta un efficace approccio alla gestione degli incontri del CAB.
Tali incontri sono finalizzati ad una valutazione condivisa dei Change per i quali è richiesto il coinvolgimento del CAB.
84 – Change falliti, non autorizzati, che hanno previsto un piano di ripristino o
avviati senza il coinvolgimento del CAB.
– Change per i quali è richiesta la valutazione da parte del CAB.
– Change per i quali vi è stato un precedente assessment da parte del CAB. – La schedulazione dei Change o il relativo aggiornamento.
– I Change completati nel precedente intervallo temporale.
– Anticipazione dei Change per i quali è prevista la verifica nel successivo incontro del CAB.
– Verifica di eventuali Change non autorizzati che sono stati individuati attraverso l’ausilio del Configuration Management.
9.7. Change Approval Authority
Ruolo della Change Approval Authority
9.7.1.
Il ruolo della Change Approval Authority è quello di approvare o respingere le richieste di cambiamento. La decisione di approvazione o rifiuto deve tenere necessariamente conto delle valutazioni realizzate nella fase di Assessment.
85
Categorie
del
Change
come
Criterio
di
9.7.2.
assegnazione del ruolo di Change Approval Authority
(CAA)
– Per le Change categorizzate come Standard, Bug e Update non è necessaria l’approvazione.
– Per le Change categorizzate come Minor è il Change Manager – Per le Change categorizzate come Significant e Major è il CAB
Delega della Change Authority
9.7.3.
Nell’ambito di ciascun livello di approvazione, è possibile esercitare la delega nei limiti di parametri che tengano conto dei potenziali rischi per il business e degli impatti finanziari. L’esercizio della delega può essere esercitato solo verso ruoli in possesso delle informazioni adeguate a supporto delle decisioni e con il committment del management.
– Il Change Manager può delegare l’autorizzazione di Change Minor al Change Coordinator
– Il CAB può delegare l’autorizzazione di Change Significant al Change Manager
In caso di disaccordo sulla decisione di autorizzazione è possibile realizzare un’escalation verso la Change Authority di livello superiore.
86
9.8. Assessment Team
Nomina e Composizione
9.8.1.
Viene nominato dal Change Owner con il supporto dei Change Coordinator, in base alla specifica RfC, alla sua conoscenza dell’organizzazione e della infrastruttura e con il supporto del CM. Il team può variare da una singola persona, ad un gruppo di persone dello stesso team fino a membri di diversi gruppi di supporto. La composizione del team è dinamica e può essere modificata in qualsiasi momento dell’Assessment da parte del Change Owner in base ai risultati emersi. In particolare è oggetto di revisione quando la successiva fase di approvazione richiede maggiori informazioni a supporto dell’approvazione del Change.
Ruolo
9.8.2.
Ha il compito di valutare il Change, in termini di impatto, effort, costi e tempi al fine di fornire le necessarie informazioni per una conferma della classificazione iniziale e successiva approvazione e pianificazione del Change.
87
9.9. Development e Release Management Team
Nomina e Composizione
9.9.1.
Il Change Owner in base ai risultati dell’Assessment e di eventuali raccomandazioni della fase di approvazione con il coinvolgimento dei Change Coordinator (e/o del Project Manager) nomina i membri del team incaricati di sviluppare la soluzione richiesta nella RfC e quindi di effettuarne il relativo rilascio (sotto la responsabilità del Release Manager all’interno del processo di Release Management).
La composizione dei team è in funzione della RfC da sviluppare e può variare da una singola persona, ad un gruppo di persone dello stesso team fino a membri di diversi gruppi di supporto.
Ruolo
9.9.2.
Eseguono le attività richieste per la progettazione, implementazione, test e preparazione/attivazione remediation plan e rilascio.
88
9.10. Overview ruoli e responsabilità di gestione
del Change.
Nella seguente tabella (Tabella 6) vediamo un riepilogo di quanto definito in precedenza, ovvero un quadro dei ruoli e delle responsabilità in base alle attività e alle categorie del Change.
Attività Categorie di Change
Standard Bug &
Update Minor Significant Major Emergency
Creazione e verifica Ruo li d efi n iti n el Cha n ge M o d el Change Initiator
Change Coordinator Change Manager
Assessment e
valutazione Assessment Team Em
erge n cy Commit te e (EC) Approvazione Change Coordinator Change Manager CAB Coordinamento implementazio ne
Change Coordinator Change Manger
Development Team
Revisione e chiusura
Release Management Team Change Coordinator Change Manager
89
9.11. Classi di priorità del Change
La Priorità
9.11.1.
■ Ad ogni RfC deve essere associata una priorità basata sull’impatto di
Business (inteso nella sua duplice accezione di beneficio da conseguire o
danno da evitare) e sull’urgenza della sua realizzazione.
■ La classificazione di priorità ha lo scopo di definire l’ordine secondo cui le Change devono essere gestite.
■ La priorità di una RFC dovrebbe essere suggerita fin dall’inizio dal Change Initiator per poi essere successivamente valutata ed assegnata in relazione alle altre richieste dal Change Owner.
Le classi di Priorità
9.11.2.
■ EMERGENCY: Si tratta di Change la cui implementazione è finalizzata alla correzione di malfunzionamenti gravi, bloccanti di uno o più Servizi e che, per questa ragione, non possono essere procrastinati.
■ ALTA: Il Change deve essere implementato e rilasciato prima possibile (non appena completato) e deve essere preventivamente testato.
■ MEDIA: Non può attendere la prossima release schedulata a causa dell’impatto conseguente alla non implementazione.
■ BASSA: L’implementazione del cambiamento può attendere fino alla prossima release schedulata.
90
9.12. Tabella delle Priorità del Change
Con l’ausilio della Tabella 7 possiamo dedurre la priorità del Change sulla base del livello di Impatto e Urgenza:
- Impatto : Beneficio da conseguire o danno da evitare.
- Urgenza : Livello di necessità del Change in termini di tempo. - Priorità : Impatto + Urgenza.
URGENZA
Alta
Media
Bassa
IM
PATTO
Alta
Emergency
Alta
Media
Media
Alta
Media
Bassa
Bassa
Media
Bassa
Bassa
91
9.13. Mappature del processo.
Overview del processo
9.13.1.
92 La Figura 17 è la rappresentazione sintetica del processo di Change Management. Come vediamo al suo interno si distingue in tre sotto processi Standard, Normal e Emergency Change Management.
Standard Change Management
In caso di Change con alto grado di ripetitività (frequentemente richiesti sul medesimo o anche su diversi CI), vengono definite procedure specifiche (Change Model) per la loro gestione che prevedono un processo e responsabilità pre- determinati.
L’insieme dei Change standard disponibili ai fini della categorizzazione è consultabile nello Standard Change Catalogue, predisposto ed aggiornato a cura del responsabile del Gruppo di Supporto.
Normal Change Management
Si tratta del flusso ordinario di gestione delle richieste di cambiamento, che prevede una serie di attività standard la cui esecuzione e gli attori coinvolti varia notevolmente in funzione della categoria di Change da gestire.
Il flusso di processo inizia con la registrazione verifica della RfC, finalizzata a valutare la bontà delle informazioni fornite, per poi proseguire con l’Assessment e la valutazione delle richiesta finalizzata a fornire alla fase di autorizzazione tutti gli elementi valutativi per approvare o respingere la richiesta.
Una volta approvata la RfC viene schedulata nel dettaglio, sviluppata e rilasciata sotto il coordinamento e la supervisione del Change Management. Il flusso si chiude con la fase di revisione post implementazione della richiesta finalizzato ad apprendere punti di forza e debolezza dal lavoro svolto, al fine di migliorare la gestione futura.
Emergency Change Management
E’ un flusso di gestione straordinario limitato alle richieste di cambiamento la cui priorità è stata classificata come Emergency, la cui implementazione richiede un
93 percorso di gestione accelerato rispetto al flusso ordinario, garantendo comunque un set minimo di controlli e verifiche volte a preservare l’ambiente di produzione. Viene attivato a seguito di Incident con bloccanti per i Servizi erogati e con notevole impatto sul business, la cui soluzione richiede necessariamente un cambiamento.
94
Creazione e Verfica RFC
9.13.2.
95 La Figura 18 rappresenta le attività di Creazione e Verifica della RfC. La richesta di cambiamento viene attivata dal Change Initiator per diverse ragioni. Come già detto le RfC possono essere scaturite per soddisfare svariate esigenze da parte dei clienti, dei fornitori o dell’IT stesso.
Nell’attività di “Verifica RfC” le informazioni del Change Initiator sono valutate da parte del Change Owner che ne verifica la completezza e qualità rispetto alle policies definite per la sottomissione delle RfC. Se le informazioni fornite sono sufficienti per categorizzare in maniera attendibile la RfC, la ownership sarà automaticamente attribuita secondo la categoria individuata in base a tali informazioni.
Se a seguito della Verifica le informazioni sono valutate come incomplete a cura del Change Owner, questo ha la facoltà di richiedere ulteriori informazioni al Change Initiator. Il C.I. è tenuto a fornire le informazioni richieste entro un ragionevole periodo di tempo (fissate all’interno delle Policy per la sottomissione delle RfC). Acquisite le informazioni richieste l’attività prosegue tornando alla fase di verifica iniziale, utilizzando le nuove informazioni raccolte a supporto.
Nel caso in cui la RfC sia fuori ambito rispetto al processo di Change Management o sia invece respinta da parte del Change Owner la proposta di RfC viene respinta fornendo alle parti interessate le motivazioni del rifiuto.
Normal Change Management
9.13.3.
La Figura 19 rappresenta il sotto-processo di Normal Change Management. Il Change Owner in base alla specifica RfC, alla sua conoscenza dell’organizzazione e della infrastruttura e con il supporto del CMDB e dei responsabili dei reparti It nomina i membri dell’Assessment Team che sono chiamati a valutare nel dettaglio gli impatti del cambiamento richiesto. La composizione del team è in funzione della RfC e può variare da una singola persona, ad un gruppo di persone dello stesso team fino a membri di diversi gruppi di supporto. La composizione del team
96
97 è dinamica e può essere modificata in qualsiasi momento dell’Assessment da parte del Change Owner in base ai risultati emersi ed in particolare è oggetto di revisione quando la successiva fase di approvazione richiede maggiori informazioni a supporto dell’approvazione del Change.
Con il coordinamento del Change Owner i membri nominati per l’Assessment Team, ognuno con il proprio bagaglio di competenze, realizzano una valutazione approfondita del Change in termini di impatti e fattibilità tecnica, impatti sul business, sulla sicurezza, sul piano di continuità oltre che una stima delle risorse finanziarie necessarie. Output di questa fase è un Assessment report che sintetizza i risultati dell’attività di valutazione.
Il Change Owner con il supporto dei membri dell’Assessment e dei criteri di priorizzazione e categorizzazione, assegna una priorità e categoria definitiva alla RfC dell’attività di valutazione. Successivamente con il supporto dei membri dell’Assessment Team, sulla base dei risultati dell’Assessment pianifica lo sviluppo del Change.
A questa punto l’RfC è pronta per la fase di autorizzazione: per le Change categorizzate come Significant e Major il Change Owner provvede a far circolare l’RfC e relativa documentazione verso i membri del CAB ( definiti di volta in volta in base al contenuto specifico della RfC e delle policies che ne disciplinano la composizione; per quelle categorizzate come Minor è direttamente il Change Owner ad effettuare una valutazione e quindi a dare approvazione allo sviluppo della RfC; per i Change di tipo Bug e Update non è richiesta invece approvazione e pertanto si procede direttamente al loro sviluppo.
Ad approvazione ricevuta il flusso prosegue seguendo la pianificazione prevista altrimenti viene informato il Change Initiator con le motivazioni del rifiuto. Per le Change di tipo Bug/Update vengono direttamente sviluppate ed implementate dal gruppo di supporto, per le atre invece viene nominato un Team di Sviluppo. Successivamente il Change viene testato dall’utente (tipicamente il Change Initiator). Se il test va a buon fine si provvede al suo rilascio, altrimenti torna alla fase di sviluppo ed implementazione.
98 Le attività di rilascio devono avvenire causando il minimo impatto sulla qualità del servizio e corredate della documentazione necessaria.
Standard Change Management
9.13.4.
Figura 20 Standard Change Management
Il sotto-processo di Standard Change Management, come si evince dalla Figura 20 è molto semplice e lineare, pensato per rendere il più veloce possibile tutti quei cambiamenti di tipo Standard per cui esiste già un Change Model, ovvero un iter di processo già definito e testato. L’attività che deve portare avanti il Change Owner consiste semplicemente nell’individuare il Change Model da applicare e nominare un Execution Team che pensi al suo sviluppo e quindi al relativo rilascio.
Periodicamente il Change Manager attua una revisione del Change Model Catalogue, verificando che i Change potenzialmente classificabili come Standard soddisifino i seguenti requisiti:
Il Change è implementato sempre usando la stessa sequenza di operazioni;
Il Change è stato implementato almeno una volta con successo;
Le risorse necessarie all’implementazione del Change sono le medesime o comunque facilmente identificabili;
Non ci sono costi di realizzazione significativamente diversi da esecuzione ad esecuzione.
99 La Figura 21 rappresenta il processo di gestione del Change Model Catalogue appena descritto.
Figura 21 Gestione Change Model Catalogue
Emergency Change Management
9.13.5.
La gestione dello stato di Emergency di una RfC si riferisce ad una gestione straordinaria del cambiamento dettata da un motivo di forte urgenza. Pertanto l’obiettivo di tale sotto-processo è quello di attuare il cambiamento nel minor tempo possibile.
La Figura 22 ne rappresenta il flusso. Vediamo come la RfC viene immediatamente presentata al CAB-EC dal Change Owner che la presa in carico. Il CAB-EC è un particolare CAB che viene nominato e presieduto dal Change Manager. Il CAB-EC ha la facoltà di far rientrare l’emergenza (e attivare quindi il processo di consueta gestione) o confermare l’urgenza. In quest’ultimo caso verrà nominato un Execution Team che avrà mandato immediato di sviluppare, implementare e testare il Change nel più breve tempo possibile.
La procedura di Emergency Change segue il processo di Normal Change tranne che per le seguenti fasi:
100
L’approvazione viene data dal CAB-EC;
Le procedure di test possono essere ridotte o in casi estremi evitate completamente se il rilascio è ritenuto come assolutamente necessario;
La redazione della documentazione associata al change viene differita alla prima occasione possibile.
101
Revisione e Chiusura RFC
9.13.6.
Figura 23 Revisione e Chiusura Change
Successivamente al rilascio del Change nell’ambiente di produzione avviene la validazione del rilascio e la sua verifica. L’obiettivo di questa fase, chiamata Post Implementation Review (PIR) è verificare che il Change abbai prodotto gli effetti desiderati e che abbia rispettato i requisiti della RfC originale. Al termine della revisione, il Change potrà essere posto in stato chiuso e, in caso di esito negativo, saranno specificate le causali. Il Change implementato con successo comporta un collegamento con il processo di Configuration Management, al fine di aggiornare i
102 Configuration Items impattati dal cambiamento. Al contrario, si dovrà provvedere alla creazione di un nuovo Change legato alle causali specificate. Di seguito la Figura 23 mostra nel dettaglio questa fase.
103