L'evoluzione della gestione delle modifiche IT

Modifiche standard

Le modifiche standard sono a basso rischio, comunemente ripetute e pre-approvate. Vengono eseguite spesso e seguono un processo documentato e approvato.

Ad esempio, l'aggiunta di memoria o di spazio di archiviazione è una modifica standard. La sostituzione di un router guasto con un router funzionante identico è una modifica standard. La creazione di una nuova istanza di un database è una modifica standard.

Tutte queste modifiche sono comuni e seguono un processo ben definito. Inoltre, dal momento che il processo di valutazione e approvazione dei rischi della gestione delle modifiche è già stato effettuato una volta, non occorre ripeterlo ogni volta che occorre sostituire un router.

Per molte aziende, le modifiche standard rappresentano un'opportunità primaria per l'automazione. Alcune aziende riferiscono che è possibile automatizzare fino al 70% delle modifiche standard e questo consente ai loro team di concentrarsi su modifiche normali e di emergenza.

Modifiche normali

Le modifiche normali sono modifiche non urgenti per le quali non è previsto un processo definito e pre-approvato.

Ad esempio, costituiscono modifiche normali l'upgrade a un nuovo sistema di gestione dei contenuti, la migrazione a un nuovo data center, i miglioramenti delle prestazioni. Non sono modifiche standard e ripetibili, perché comportano dei rischi; tuttavia, non sono neppure emergenze. Ciò significa che possono essere inserite nella normale coda di gestione delle modifiche per la valutazione e l'approvazione del rischio.

Alcune modifiche normali, come una sostituzione del data center, sono comunque a rischio elevato e potrebbero richiedere una valutazione dei rischi e l'approvazione da parte di un CAB (Change Advisory Board). Altre modifiche, come quelle apportate a un sito Web, potrebbero essere a basso rischio e venire approvate con una timeline più rapida da un'autorità di modifica designata o tramite controlli automatici e peer review.

Modifiche di emergenza

Queste modifiche derivano da una minaccia o da un errore imprevisto e devono essere affrontate immediatamente, in genere per ripristinare il servizio per i clienti o i dipendenti o per proteggere i sistemi da una minaccia.

Ad esempio, è una modifica di emergenza l'implementazione di una patch di sicurezza, la gestione di un'interruzione del server, la risoluzione di un imprevisto grave.

L'urgenza delle modifiche di emergenza indica che queste devono essere gestite in una timeline molto più breve, poiché il rischio di un lungo processo di revisione è maggiore dei rischi associati alla risoluzione rapida del ticket.

Il modo in cui si categorizzano le modifiche dipende da fattori che includono l'organizzazione, i processi e la tolleranza al rischio. Sosteniamo che sia necessario abbandonare un approccio unico e gestire invece ogni modifica in modo diverso in base alla valutazione dei rischi. Via via che l'organizzazione impara dagli imprevisti precedenti e dai sistemi specifici e incorpora altri dati pertinenti, dovrebbe essere possibile designare una parte maggiore di modifiche come standard e pre-approvarle. La gestione delle modifiche moderna deve rendere le richieste di modifica il più semplici e snelle possibile.

Che cos'è un CAB (Change Advisory Board)?

Nella maggior parte delle organizzazioni IT tradizionali, un CAB )(hange Advisory Board) ha il compito di valutare i rischi e approvare (o non approvare) ogni modifica. In genere, un CAB tiene riunioni regolarmente programmate per esaminare tutte le modifiche imminenti proposte e coinvolge degli esperti, come necessario, che spieghino, difendano o valutino la modifica insieme a loro.

Da un lato, i Change Advisory Board possono contribuire a ridurre i rischi e a lanciare l'allarme quando una modifica semplicemente non funziona per l'azienda. Dall'altra, possono anche creare colli di bottiglia, specialmente quando sono costituiti da persone che non si occupano direttamente dell'implementazione delle modifiche. In molte aziende, il processo di approvazione dei Change Advisory Board (CAB) è complesso e richiede molto tempo, il che rallenta il processo di modifica.

Molti team IT stanno abbandonando le tradizionali riunioni CAB o limitandone l'ambito alle modifiche più rischiose e alle principali preoccupazioni dell'organizzazione. In questo paradigma, i CAB possono diventare consulenti di fiducia con il compito di monitorare le tendenze, fornire consigli sul modo in cui le pratiche possono gestire le modifiche e svolgere un ruolo di coordinamento tra i team e le loro esigenze.

ITIL 4 promuove anche la decentralizzazione dell'autorità di modifica a livello di stakeholder aziendale o tra pari. Invece di utilizzare un comitato distinto, integra la gestione delle modifiche nei normali flussi di lavoro con gli stakeholder pertinenti. Per evitare i colli di bottiglia, considera l'automazione, le checklist virtuali e la peer review come un'alternativa più Agile e collaborativa.

Best practice per la gestione delle modifiche

Come accennato in precedenza, la gestione delle modifiche provoca lo stesso tipo di terrore che alcuni di noi avvertono davanti a un piatto di verdure a foglia verde. Sicuramente non ci fa impazzire l'idea di mangiarle, ma sappiamo quanto siano importanti e possiamo adottare delle misure per renderle più allettanti.

Ecco alcune best practice per la moderna gestione delle modifiche:

• Comprendere la tolleranza al rischio e gli obblighi normativi dell'organizzazione.
• Semplificare e automatizzare i processi di gestione delle modifiche, laddove possibile.
• Offrire ai CAB un focus più strategico.
• Adottare nuove pratiche in grado di rendere le modifiche standard la nuova normalità.
• Prendere in considerazione vari framework come ITIL e DevOps per trovare le linee guida più efficaci per l'organizzazione.
• Dare priorità alla collaborazione.
• Utilizzare l'ingegneria del caos per ridurre il rischio.
• Semplificare l'acquisizione delle richieste di modifica per i team IT e di sviluppo.
• Promuovere l'apprendimento con le metriche e i KPI relativi alle modifiche .
• Adottare un approccio alla gestione dei rilasci basato su DevOps.

Affrontare le sfide della gestione delle modifiche.

Gli sviluppatori desiderano implementare il codice in modo rapido e senza impiegare tempo e attività aggiuntive per la documentazione manuale. I team operativi IT vogliono ridurre i rischi, mantenere dati dettagliati per gli audit ed evitare imprevisti. Chiedere agli sviluppatori di aggiungere un ulteriore passaggio ai loro processi, prendere nota delle osservazioni, timbrare il cartellino può dare l'impressione che si voglia distoglierli dal raggiungimento degli obiettivi finali del loro lavoro. Chiedere al team operativo di rivedere i processi esistenti, revocare i controlli delle approvazioni ed estendere l'automazione non è facile e può dare l'impressione che sembrare che si stiano creando più rischi.

Nel frattempo, la posta in gioco è più alta che mai. L'aumento dei servizi basati su software ha aumentato le aspettative dei clienti e la domanda di servizi sempre attivi e ad alte prestazioni. In un ambiente sempre più dinamico, il lavoro necessario per gestire i servizi continua a crescere.

Quindi, come possiamo superare queste sfide? Innanzitutto, bisogna sfatare il mito secondo cui un processo pesante riduce i rischi. Si deve poi adottare una cultura, pratiche e strumenti che aiutino i team a collaborare e a effettuare i rilasci. Infine, bisogna includere continuamente informazioni per dimostrare il valore dei passaggi precedenti e proseguire lungo un percorso di ricerca di miglioramento.