Change Management - Best Practice e Casi di successo Italiani

[EdoM]

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:

1. Cos'è per voi una Change?
2. Quando aprire un Progetto o gestire il requisito come Change?
3. 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?
4. 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

[S_ Iovieno]

Edoardo,

il tema é molto interessante e complesso.

In ESA abbiamo implementato il processo di Change Management su ServiceNow fin dal go-live a Settembre 2015.

In un certo senso siamo stati facilitati dal fatto che l'Agenzia avesse da lungo tempo un processo consolidato di Change Mgt.

Ci sarebbe molto da scrivere ma cercheró di rispondere brevemente alle tue domande:

1. Cos'è per voi una Change? >>> Per noi é esattamente quello che hai riportato nella definizione
2. Quando aprire un Progetto o gestire il requisito come Change? >>> Il progetto per noi é un'attivitá organizzata per realizzare un cambiamento "complesso" che impatta piú Configuration Items software e/o hardware Stiamo proprio in questo periodo lavorando per realizzare un nuovo set di funzioni che supporti il processo decisionale e di validazione dei progetti che nel nostro caso devono passare dalla valutazione del CAB
3. 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? >>> Il task di progetto per noi é un'attivitá relativa alle fasi di approvazione e chiusura dei progetti Le implementazioni poi le gestiamo con i change e i release (quest'ultimo per gli item software)
4. 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? >>> Questa é la parte piú complicata. Spesso puó accadere che change passino come reazione a richieste che non vengono gestite in modo appropriato secondo i processi definiti. Nel nostro caso non consentiamo come principio che change vengano applicati senza essere opportunamente tracciati come tali, ma abbiamo un contesto di multi-sourcing molto articolato in cui non controlliamo all'interno della piattaforma ServiceNow tutti i CIs che contribuiscono alle funzioni operative.

Come detto il tema richiederebbe una piú ampia discussione.

A disposizione per condividere la nostra esperienza piú dettaglio.

A presto

Salvatore Iovieno

Senior Programme manager
ESA Ground Segment & Data Management Division
ESA - ESRIN

[matteo13]

Ciao a tutti,

il tema è molto articolato e complesso, forse sarebbe meglio spezzare le domande in più thread, così vasto... spaventa un po'!

ti rispondo per come facciamo noi

1. Cos'è per voi una Change? >>> Anche per noi è così
2. Quando aprire un Progetto o gestire il requisito come Change? >>> i change da noi nascono così:
3. 1. da problem: quando per indirizzare la root cause necessita un change, questo viene aperto direttamente dal problem, il change è quindi originato da PRB (un PRB può originare n CHG)
   2. da demand: quando per risolvere una richiesta è necessario fare un CHG, posso nascere (1 o n):
   3. 1. progetto: quando le attività sono articolate (1 PRJ - n CHG, legati direttamente al PRJ e non ai task di progetto)
      2. enhancement: quando l'attività è semplice (1 ENH - 1 CHG)
4. 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? >>> noi facciamo originare i CHG dal progetto per non complicare troppo il processo, quando è necessario rilasciare qualcosa generato dal progetto, il PM o il Service Manager staccano uno o più CHG e lo associano a una o più release, 1 RLS - n CHG)
5. 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? >>> Per noi, tutto quanto viene rilasciato deve essere associato a un CHG e deve essere possibile ricostruire interamente la catena dal rilascio, ai suoi change, alle attività di implementaizone del CHG e perè questo change è stato necessario (un problem o un demand)

Non so se sono ho risposto alle tue domande, il mio consiglio cmq è spezzare un po' la discussione in n, un po' più atomiche per per non perdersi!

Buona giornata,

Matteo