Tipi di cambiamento: Standard vs Normale vs Emergenza

Il mondo degli affari è noto per l’uso di parole d’ordine confuse e gergo industriale. Questo è il caso quando si tratta di differenziare tra cambiamento standard e cambiamento normale.

Non è una sorpresa che molte persone si chiedano: “Qual è la differenza tra cambiamento normale e standard?” Questo è particolarmente vero dato che standard e normale sono sinonimi che sono relativamente intercambiabili nella maggior parte delle circostanze.

Prima di addentrarci ulteriormente nella tana del coniglio del cambiamento, assicuriamoci di essere sulla stessa pagina di ciò che intendiamo quando diciamo “cambiamento” in primo luogo.

Che cos’è il cambiamento?

Nel contesto del mondo dell’IT business e, più specificamente, nel mondo della gestione ITIL, il cambiamento si riferisce alle modifiche alle applicazioni software dell’organizzazione, siano esse applicazioni interne o prodotti rivolti ai clienti. Il cambiamento in questo contesto include gli aggiornamenti al codice e ai sistemi esistenti che vengono testati e implementati negli ambienti live.

Questo processo di gestione del cambiamento è gestito dal Change Manager e dai Change Advisory Boards (CAB). Il CAB generalmente gestisce due tipi principali di cambiamenti sui quali raccoglie informazioni prima di dare il via libera finale all’implementazione:

• Modifica standard
• Modifica normale

Queste definizioni e designazioni specifiche possono cambiare da un’organizzazione all’altra a seconda delle loro esigenze, ma ci sono alcune regole generali sotto le quali tendono ad operare. Cominciamo ad esplorare questi processi esaminando un cambiamento standard.

(I cambiamenti di emergenza, che esamineremo più avanti, sono cambiamenti più urgenti e sensibili, gestiti dall’Emergency Change Advisory Board o ECAB, che è tipicamente un sottoinsieme del CAB.)

Cos’è un cambiamento standard?

I cambiamenti standard, a volte chiamati cambiamenti di routine, tendono ad essere cambiamenti pre-autorizzati che sono considerati avere poco o nessun rischio associato ad essi. Sono eventi abbastanza comuni che hanno linee guida e procedure specifiche che seguono. I cambiamenti standard sono implementati spesso con passi ripetibili che raramente richiedono modifiche. Il CAB di solito non esamina ogni caso di un cambiamento standard e invece stabilisce un protocollo e una panoramica delle linee guida per l’attuazione dei cambiamenti standard.

I cambiamenti standard sono spesso aree in cui l’automazione può essere implementata per aiutare a velocizzare il processo e aumentare l’efficienza. Questi cambiamenti sono stati raffinati in un approccio ordinato e sistematico che porta al successo in modo affidabile. Automatizzare gli aspetti di queste modifiche standard può ridurre drasticamente il tempo sprecato nel processo e liberare ore di lavoro per il lavoro che richiede un po’ di ingegno umano.

ITIL change management definisce la modifica standard come:

“Una modifica pre-autorizzata che è a basso rischio, relativamente comune e segue una procedura o un’istruzione di lavoro”.

Considera standard i servizi che l’IT offre ai suoi utenti finali. Servizi come:

• Sostituzione del ciclo di vita dell’hardware
• Patching e aggiornamenti del software
• Modifiche al firewall
• Nuove voci DNS

Questi sono tutti esempi di attività pre-autorizzate che l’IT può seguire immediatamente una volta che si presenta una richiesta di cambiamento o un’esigenza. Dopo l’autorizzazione di tali cambiamenti, è necessaria una pianificazione minima per eseguire una richiesta di cambiamento. Queste modifiche nascono tipicamente come richieste di servizio da parte degli utenti finali e sono ben anticipate in anticipo, non necessariamente in termini di un lasso di tempo specifico.

Le modifiche standard possono anche includere modifiche operative che seguono un programma specifico, come i cicli di aggiornamento di stampanti, stazioni di lavoro e dispositivi di rete.

La procedura di implementazione delle modifiche è semplice e raramente introduce un problema o un rischio. Una procedura completa di valutazione del rischio viene eseguita prima dell’autorizzazione dei cambiamenti standard. Solo un cambiamento aziendale o un incidente informatico richiederebbe una nuova valutazione dei rischi associati ai cambiamenti standard.

E’ descritto come un cambiamento standard poiché l’approvazione e la pre-autorizzazione sono a discrezione dell’organizzazione o del fornitore di servizi. La procedura coinvolta nell’implementazione del cambiamento è ben documentata. I rischi associati sono calcolati e contabilizzati con largo anticipo. Le misure di mitigazione del rischio necessarie sono prese come parte della procedura di implementazione del cambiamento. Una volta ricevuta la richiesta di cambiamento, non è necessaria un’ulteriore approvazione da parte dei decisori o del Change Advisory Board (CAB).

Avere una richiesta di servizio IT come Standard Change ha i suoi vantaggi da una prospettiva di IT Service Management (ITSM). Il processo di cambiamento scorre con un attrito minimo, specialmente quando le informazioni e i silos dipartimentali possono causare inutili ritardi e limitazioni nell’implementazione del cambiamento. Avere una pre-autorizzazione, una procedura di implementazione documentata e un’ampia valutazione dei rischi già in atto permette all’IT di fornire il servizio richiesto in modo efficiente ed efficace, che è esattamente l’obiettivo del framework ITIL associato alla gestione dei cambiamenti.

Ci possono essere momenti in cui il CAB interviene e si rende conto che le voci devono essere aggiunte o rimosse dall’elenco dei cambiamenti Standard che richiedono una supervisione molto piccola. Generalmente, una modifica Standard va via senza problemi durante una finestra di manutenzione programmata e ha un impatto minimo, se non nullo, sui servizi attivi. Questo è in diretto contrasto con le modifiche di emergenza che richiedono una supervisione diretta e un’attenta considerazione.

Cos’è una modifica di emergenza?

Le modifiche di emergenza sono fondamentalmente l’esatto opposto delle modifiche standard. ITIL definisce i cambiamenti di emergenza come:

“Un cambiamento che deve essere introdotto il prima possibile”.

Esempi di cambiamento di emergenza includono:

• Implementazione di una patch di sicurezza per un exploit zero-day
• Isoluzione della rete da un attacco DDoS (Distributed Denial of Service) su larga scala

Questi cambiamenti rappresentano tipicamente una crisi o un’opportunità che deve essere affrontata senza rischi eccessivi. Ci si aspetta quindi un livello di rischio accettabile e si seguono procedure specifiche come strategia di mitigazione del rischio. Sono anche richieste approvazioni e autorizzazioni specifiche prima dell’implementazione di un Cambiamento di Emergenza.

Questo non significa lunghe riunioni tra i membri del CAB, ma una supervisione di alto livello sul processo di gestione del cambiamento. Il processo deve seguire un’azione rapida da parte di tutte le parti interessate in ogni fase del processo di gestione del cambiamento. Di conseguenza, le modifiche di emergenza non sono testate a fondo e le decisioni appropriate sono prese come un compromesso equilibrato tra rischio e ricompensa.

L’agilità dell’organizzazione determina quanto bene può gestire le modifiche di emergenza. Segue un flusso di processo di gestione del cambiamento simile a quello delle modifiche normali, ma in tempi accelerati secondo le linee guida ITIL. Il successo nella gestione di un Emergency Change determina la stabilità dei servizi IT forniti agli utenti finali. Pertanto, l’impatto di un cambiamento di emergenza dovrebbe essere documentato e valutato per i miglioramenti futuri nel processo di gestione del cambiamento.

Si dovrebbe anche includere un processo di rimedio o di back-out nei protocolli di gestione del cambiamento di emergenza. Questo per poter ripristinare lo stato originale quando le attività di implementazione del cambiamento introducono ulteriori rischi e problemi.

Non arrivano nei momenti previsti e sono tutt’altro che ordinari. I cambiamenti di emergenza sono portati come risposta a ostacoli imprevisti come falle di sicurezza e exploit. I cambiamenti di emergenza sono portati all’attenzione immediata di un Change Manager e sono poi inviati all’ECAB per ulteriori analisi. È dovere dell’ECAB valutare il rischio delle modifiche di emergenza proposte e soppesare il pericolo che il problema sottostante rappresenta per l’organizzazione e i suoi servizi.

L’ECAB cerca di trovare un rimedio rapido ma efficace al problema appena scoperto e lavora con una scadenza stretta che non lascia spazio alla burocrazia tipica della maggior parte delle operazioni di cambiamento. Le informazioni devono essere raccolte e analizzate rapidamente per decidere la migliore linea d’azione per porre rimedio al problema in questione. I cambiamenti di emergenza sono testati rapidamente e implementati immediatamente quando necessario. L’obiettivo dei cambiamenti d’emergenza è quello di impattare i servizi attivi il meno possibile e fermare l’emorragia il più rapidamente possibile. Questo lascia poche opportunità per le procedure standard, dato che spesso sono richieste soluzioni fuori dagli schemi.

Quello che rimane in mezzo alle modifiche di emergenza e alle modifiche standard è la modifica normale.

Cos’è una modifica normale?

La maggior parte delle organizzazioni definisce le modifiche normali come qualsiasi modifica che NON è una modifica di emergenza o una modifica standard. Le modifiche normali non sono pre-autorizzate come lo sono le modifiche standard, ma non operano nemmeno con la tempistica più rigida e la natura più da Far West delle modifiche di emergenza che richiedono la libertà dalla burocrazia e dalle linee guida costrittive. Le modifiche normali passano attraverso il processo CAB per ogni modifica che viene effettuata.

Questo permette la supervisione delle modifiche e fornisce al CAB l’opportunità di valutare se questa modifica normale si verifica con una frequenza tale da poter essere dotata di linee guida ripetibili che potrebbero convertirla in una modifica standard. Ogni cambiamento normale viene elaborato come una Richiesta di Cambiamento (RFC), che viene alimentata al CAB e infine approvata o abbattuta dal Change Manager.

I cambiamenti normali sono abbastanza comuni, ma tipicamente richiedono approcci un po’ unici o nuovi, a differenza dei cambiamenti standard che generalmente possono essere realizzati attraverso l’uso di guide passo dopo passo o alcuni schemi di base. I cambiamenti normali sono sottoposti a un’auto-riesame in cui il team analizza il cambiamento nell’ambito dell’incarico e valuta la sua fattibilità prima di passarlo al CAB. Il CAB esamina quindi il cambiamento proposto e si assicura che soddisfi la conformità e tutti i protocolli di sicurezza prima di essere finalmente consegnato al Change Manager per l’approvazione finale.

ITIL definisce il cambiamento normale come:

“Un cambiamento che non è un cambiamento di emergenza o un cambiamento standard. I cambiamenti normali seguono le fasi definite del processo di gestione del cambiamento”.

Sono i cambiamenti che devono essere valutati, autorizzati e poi programmati secondo un processo standardizzato. Questi cambiamenti sono anticipati e pianificati in anticipo e adeguati controlli standardizzati di gestione del cambiamento possono essere concepiti di conseguenza. Tuttavia, il cambiamento normale viene implementato solo dopo aver ricevuto l’autorizzazione formale e l’approvazione. Le modifiche a basso rischio possono richiedere l’autorizzazione dei team IT locali, mentre le modifiche ad alto rischio possono richiedere l’approvazione del CAB o dei dirigenti senior di business e IT. Tutte le attività all’interno dei controlli del processo di gestione delle modifiche sono praticate per le modifiche normali.

Gli esempi possono includere la migrazione di risorse informative critiche, applicazioni e carichi di lavoro da server on-premise a data center cloud.

Definire le modifiche come normali riduce il rischio per l’organizzazione e i fornitori di servizi IT, poiché la pianificazione di ogni modifica assicura che i rischi siano attentamente mitigati e le richieste di modifica producano i risultati desiderati. Tuttavia, l’implementazione di modifiche normali è anche un processo lungo e dispendioso in termini di tempo. Oltre al processo di approvazione e autorizzazione, il fornitore di servizi ha bisogno di una forte visibilità e controllo sul processo di cambiamento, sui sistemi sottoposti e sulle dipendenze associate.

La gestione e l’implementazione di Normal Changes richiede quindi tecnologie ITSM avanzate per analizzare, testare, gestire ed eseguire attentamente il processo di cambiamento e i sistemi. Una volta che il Normal Change è stato implementato, l’IT valuta il successo dell’implementazione e i requisiti futuri di cambiamenti simili. Idealmente, l’IT fa maturare il suo processo di gestione dei cambiamenti, gli strumenti e le capacità per trasformare un cambiamento normale in un cambiamento standard. Questo riduce l’onere per l’IT e per i fornitori di servizi di gestire i cambiamenti, ottenendo al contempo il controllo sul processo di gestione dei cambiamenti come ottenuto per i Cambiamenti Standard.

Sommario

Questo processo di gestione dei cambiamenti aiuta ad aumentare il successo delle implementazioni, riducendo al contempo il rischio e minimizzando i tempi di inattività. I diversi tipi di cambiamento e la loro categorizzazione aiutano il buon funzionamento dell’intero processo di cambiamento. I cambiamenti standard sono fatti con poca o nessuna supervisione, mentre i cambiamenti di emergenza richiedono una gestione attenta e un’analisi dettagliata. I cambiamenti normali si collocano felicemente tra questi due estremi.

La distinzione tra cambiamento standard, normale e di emergenza dovrebbe essere osservata da una prospettiva concettuale, al di là delle differenze nella convenzione di denominazione. I termini Standard e Normale possono sembrare sinonimi, ma le differenze sottostanti rappresentano l’efficacia delle procedure e dei controlli di gestione del cambiamento. È quindi importante avere una forte pratica di change enablement nel discriminare tra i tre tipi di cambiamento attraverso un’attenta valutazione delle richieste di cambiamento e degli incidenti che portano a una richiesta di cambiamento.

Questi tre tipi di cambiamento aiutano le organizzazioni ad affrontare i problemi man mano che si verificano, mantenendo il ritmo costante che ci si aspetta dalle moderne organizzazioni DevOps.

Lettura correlata

• BMC Service Management Blog
• Tipi & Livelli di Change Management
• Gestione del cambiamento nel cloud
• Organizational Change Management (OCM): A Template for Reorganizing IT
• Facilitating Change through Effective Communication