Introduzione
Il 21 Maggio 2019 ho partecipato per la prima volta allo SNUG Italia e ne sono uscito entusiasta, pieno di idee e spunti per la nostra roadmap e architettura di IT Trasformation. Ho particolarmente apprezzato gli stimoli lanciati dai presentatori per confrontarsi a livello paese ed è per questo che vorrei aprire un dibattito su un processo molto discusso, ostico per molte aziende e talvolta difficilmente utilizzato/digerito dagli utenti finali poiché percepito come burocrazia aggiuntiva: la gestione del cambiamento (a.k.a. Change Management).
In letteratura vi sono diversi framework che ne definiscono principi, ruoli e attività (ITIL, COBIT, IT4IT, etc.), ma ci si scontra spesso nell'operatività quotidiana degli esperti IT con dubbi quali:
- Cos'è per voi una Change?
- Quando aprire un Progetto o gestire il requisito come Change?
- Un Progetto genera una Change per gestire il passaggio in produzione di una modifica o è sufficiente il task di Progetto? Se si, come si correlano e a che livello?
- Quando è possibile gestire l'operatività tracciandola solamente sulla richiesta iniziale (Generica, Incident o Service Request)? Quando è necessario, invece, aprire una Change come follow-up di tale evento?
Noi abbiamo provato a declinare su un livello più operativo tali framework e sarebbe interessante raccogliere le vostre opinioni per confrontarle tra tutti i partecipanti della community.
Di seguito troverete quello che stiamo implementando per provare a rispondere a queste esigenze. Ogni realtà è chiaramente a sé e non esiste il "one-size-fits-all", ma proviamo a trovare un linguaggio comune per confrontarci come community.
Iniziamo!
Definizione di Change
| Una Change è la modifica (creazione, aggiornamento, eliminazione) di qualsiasi componente informatico che potrebbe avere un effetto, diretto o indiretto, su un servizio IT rendendolo temporaneamente indisponibile o degradato. |
Esempi pratici per identificare una attività come Change, suddiviso per layer informatico:
Il processo di Change è da attivare quando si modifica:
- CMDB: componente informatico (logico/fisico), relazioni tra i componenti;
- Interfaccia utente: layout, funzionalità, ruoli;
- Algoritmi e dati: logiche di calcolo, relazioni tra dati (schema), tipologia, parametrizzazioni su tabelle critiche (es.: record DNS, Masterdata Organizzativi, parametrizzazioni, etc.);
- Infrastruttura: server fisici/logici, patching S.O., apparati/configurazioni network.
Il processo di Change non è da attivare quando si modifica:
- CMDB: attributi organizzativi o descrittivi di un componente (es.: Business/IT Owner, Gruppi di assegnazione, descrizioni, Categorie APM);
- Interfaccia utente: personalizzazione individuale della propria interfaccia (posizione degli oggetti/campi, layout del report);
- Algoritmi e dati: creazione di un record utente in una struttura dati esistente (modifica dei valori di una lista, creazione di un Ordine, Fattura, Contratto), esecuzione di un batch/report per aggiornamento viste dati
- Infrastruttura: ripristino di un servizio degradato tramite riavvio con procedura automatica/preventiva.
Tipologie di Change
|
Tipologia |
Definizione |
Cosa è |
Cosa non è |
|
Standard |
Cambiamenti che rientrano in casistiche standardizzate e ripetute nel tempo, gestibili attraverso un catalogo predefinito. La procedura per svolgere l’attività è documentata e il rischio relativo è basso. |
La richiesta di un nuovo server, nuove regole firewall, nuovo apparato di rete |
Richiesta di nuova utenza, reset password, nuova postazione telefonica, nuovo asset personale → È una service request a catalogo |
|
Emergenza |
Cambiamenti che devono essere implementati il prima possibile, per risolvere un incidente grave o una minaccia alla sicurezza aziendale. La fase di assessment viene saltata poiché di default il rischio è alto. L’autorizzazione viene effettuata dai Responsabili di Funzione di tutti gli oggetti impattati. La documentazione può essere inserita anche successivamente alla fase di implementazione, ma è necessaria per la chiusura della change. |
L’implementazione di una patch di sicurezza, il ripristino di un servizio degradato o indisponibile, una fix in produzione per un rollback di una modifica errata. |
Un requisito business da implementare con urgenza → è una change Normale ad alta priorità |
|
Normale |
Tutti i cambiamenti che non rientrano nelle categorie Standard o Emergenza. |
La richiesta del business di creare o modificare una funzionalità utente. |
Iniziativa aziendale di media o alta complessità in termini di processi; in questo scenario usare il PPM |
|
Progetto |
Cambiamento assimilabile ad una change di tipo Normale per la gestione delle modifiche informatiche richieste da un progetto. Le attività e la documentazione di analisi sono gestite nel contesto di progetto da cui si origina. La change viene utilizzata per gestire la fase di deploy nei vari ambienti, che viene comunque pianificata nel Gantt di progetto. |
Il rilascio in Produzione di tutte le modifiche nel perimetro del progetto |
Un cambiamento di perimetro del progetto → Issue Una modifica di un servizio IT rilasciato come output di progetto dopo che quest’ultimo è concluso → Change Normale |
Categorie di Change
- Nuovo Requisito → Nuovo perimetro funzionale/tecnico non gestito precedentemente, tipicamente necessita di approvazione budgetaria (es.: nuova tecnologia o applicazione/modulo per supportare nuovi processi o attività di business);
- Evolutiva → Ampliamento di un perimetro funzionale/tecnico esistente per migliorare un servizio gestito, con modifiche al processo business marginali, tipicamente non necessita di approvazione budgetaria (es.: nuova maschera di un modulo esistente, nuovo report su un sistema di reportistica esistente);
- Correttiva → Modifica ad un perimetro funzionale/tecnico esistente per la risoluzione di un bug applicativo/infrastrutturale, tipicamente non necessita di approvazione budgetaria (es.: calcolo di un dato errato, anomalia riscontrata dall'utente finale o dall'esperto IT, requisito utente implementato con errori).
Processo di Change Management
Per semplicità riporto solamente il processo nel caso di Change Normale.
Per le altre tipologie di change non vengono richieste alcune attività/fasi del processo (es.: Valutazione nella Change Standard | Autorizzazione nella Change di Emergenza | Autorizzazione/Implementazione in quella di Progetto).
Relazioni con altri processi e roadmap di adozione
Risk Assessment
Il tema è molto ampio e - probabilmente - servirebbe un altro post per trattare l'argomento in profondità.
Di seguito riporto solamente i Driver oggettivi che vengono analizzati (richiesti o calcolati) per determinare la Valutazione della fase di Risk Assessment (indice che pesa i fattori di Rischio e Impatto).
|
Driver (Domanda / KPI) |
Effetto |
Tipo |
|
Numero di oggetti impattati (CI) |
Rischio |
Calcolato |
|
SLA Business (Il valore massimo tra tutti gli oggetti impattati) |
Impatto |
Calcolato |
|
Categoria della Change |
Impatto |
Calcolato |
|
Rilevanza Privacy degli oggetti impattati |
Impatto |
Calcolato |
|
Numero di utenti interessati |
Impatto |
Questionario |
|
Data desiderata (lead time) |
Rischio |
Calcolato |
|
Interruzione prevista del servizio (Piano di Rilascio) |
Impatto |
Questionario |
|
Durata prevista del ripristino del servizio (Piano di Ripristino) |
Impatto |
Questionario |
|
Completezza e tipologia di test effettuati |
Rischio |
Questionario |
|
Rispetto dei requisiti minimi di sicurezza definiti da Progetto |
Rischio |
Questionario |
Questo Assessment identifica automaticamente e indirettamente la necessità dell'approvazione al rilascio da parte del CAB qualora la Valutazione risultasse "Alto".
Valutazione (indicatore sintetico "x"):
- Calcolo: R*0,75 + I*0,25
- Corrispondenza qualitativo-quantitativo dell'indice "Valutazione":
- Basso → x<2
- Medio → 2<=x<3
- Alto → x>=3
Change Form View e Related Lists (Bozza)
Abbiamo semplificato il numero dei campi obbligatori, selezionando solo quelli propedeutici agli automatismi e alla reportistica.
Change Task Form View (Bozza)
Attendo i vostri feedback nei commenti per animare il dibattito!
Grazie e a presto!
Edoardo Messinese
IT Manager - Enterprise Architecture & Governance @Esselunga
