Come migliorare il flusso di lavoro del supporto IT
L'evoluzione della gestione delle modifiche IT
La gestione delle modifiche, nota anche come abilitazione delle modifiche, è una pratica IT progettata per ridurre al minimo i rischi e le interruzioni dei servizi IT quando si apportano modifiche a sistemi e servizi critici.
Una modifica comporta l'aggiunta, la modifica o la rimozione di qualsiasi elemento che possa avere un effetto diretto o indiretto sui servizi.
Le pratiche di gestione delle modifiche sono progettate per ridurre gli imprevisti e soddisfare gli standard normativi. Garantiscono una gestione efficiente e tempestiva delle modifiche all'infrastruttura e al codice IT. Che tu stia implementando nuovi servizi, gestendo quelli esistenti o risolvendo problemi nel codice, gli approcci di gestione delle modifiche moderni abbattono i silos, forniscono contesto e trasparenza, evitano colli di bottiglia e riducono al minimo il rischio.
La gestione del rischio è una pratica ITIL 4 correlata, seguita "per garantire che l'organizzazione comprenda e gestisca efficacemente i rischi". Sia la gestione delle modifiche che quella del rischio richiedono il monitoraggio e il collegamento delle modifiche per fornire un record verificabile. La capacità di attingere ai dati sulle modifiche precedenti e sulle loro percentuali di successo consente alle organizzazioni di adattare le loro pratiche in una maniera che bilanci in modo intelligente rischio e velocità.
Le pratiche adattive e informate sui dati puntano all'efficienza, a differenza della gestione delle modifiche tradizionale, che spesso può essere inutilmente lenta, pesante e sovraccarica di processi. Poiché la gestione delle modifiche si occupa di sfide relative a rischi e conformità, verificabilità e coordinamento tra team, troppo spesso diventa complessa, burocratica e piena di problemi.
Ma non deve essere per forza così. La gestione delle modifiche è come "mangiare le verdure" dell'ITSM: non sempre è allettante, ma ha un'importanza critica. Con le pratiche e la cultura giuste, la gestione delle modifiche può comportare un minor numero di imprevisti, meno stress per i team e più tempo dedicato da attività che forniscono valore ai clienti.
Definizione della gestione delle modifiche
Quando parliamo di gestione delle modifiche, la nostra definizione riguarda ogni aspetto della modifica: tecnologia, persone, processi e impatto su clienti e sistemi. A titolo di chiarezza nel contesto dell'ITSM, ITIL 4 ha operato una distinzione tra la gestione delle modifiche IT e le pratiche di gestione delle modifiche dell'organizzazione.
- La gestione delle modifiche dell'organizzazione è la "pratica di garantire che le modifiche in un'organizzazione siano implementate in modo fluido ed efficace, e che si ottengano benefici duraturi attraverso la gestione degli aspetti umani delle modifiche".
ITIL 4 ha quindi ridefinito il precedente processo di gestione delle modifiche come la pratica di "controllo delle modifiche".
- La pratica di controllo delle modifiche garantisce "che i rischi siano adeguatamente valutati, autorizzando le modifiche a procedere e gestendo una programmazione delle modifiche al fine di massimizzare il numero di modifiche di servizio e prodotto andate a buon fine".
Questa nuova scelta di nome ha suscitato polemiche e molti team IT hanno rifiutato l'associazione con il concetto di "controllo". Per alcuni, è una parola negativa che evoca un'immagine di burocrazia, colli di bottiglia e inutili passaggi per i quali la gestione delle modifiche tradizionale è diventata tristemente famosa.
Axelos ha ascoltato il feedback e ha fornito una risposta. "Dopo il rilascio di ITIL 4 Foundation, diverse persone in tutto il mondo ci hanno segnalato che "la pratica veniva interpretata male o fraintesa come incentrata sul controllo delle modifiche o sul controllo dei team, invece che sul "controllo del tasso di modifiche".
Alla fine, ITIL ha sostituito il termine con quello di "abilitazione delle modifiche". Il nuovo nome connota una pratica utile per i team, in quanto fornisce loro la capacità e la libertà di portare avanti le modifiche.
In fin dei conti, non pensiamo che il termine utilizzato sia particolarmente importante. In questo articolo e in Atlassian si utilizza il termine "gestione delle modifiche", ma ciò che conta è l'approccio. Avendo come punto di partenza team sani e la giusta cultura, la tua organizzazione si porrà sulla strada giusta per creare una pratica efficace di gestione delle modifiche.
La relazione tra gestione delle modifiche e gestione dei rilasci
La gestione dei rilasci è un'altra pratica importante nella discussione sulla gestione delle modifiche. Secondo ITIL 4, lo "scopo della gestione dei rilasci...è di rendere disponibili all'uso servizi e funzioni nuovi e modificati". I rilasci possono includere qualsiasi cosa, dalle modifiche introdotte nelle funzionalità del software agli aggiornamenti della documentazione e della formazione.
In passato, la gestione dei rilasci prevedeva il raggruppamento delle modifiche, che venivano presentate ai clienti come un pacchetto. La gestione tradizionale dei rilasci sostiene standard rigidi di gestione dei progetti e può creare attriti nel rilascio di aggiornamenti preziosi per i clienti, causando frustrazione nell'ambito dei team che aderiscono ai principi Agile.
Possiamo ridefinire la gestione dei rilasci per il contesto DevOps. Abbandonando la sua tradizionale funzione di gestione dei progetti, la gestione dei rilasci dovrebbe riguardare l'integrazione e l'automazione. Il suo punto di partenza è l'introduzione di pipeline di codice in un sistema sicuro che integri, dove possibile, la revisione automatica e fornisca monitoraggio e supervisione. In questo modo si possono abbattere gli approcci in silos del passato e fornire un percorso di produzione privo di conflitti. La gestione dei rilasci potrebbe riguardare la capacità di semplificare il più possibile la fornitura continua di valore e l'applicazione del principio "You Build It, You Run It".
Perché la gestione delle modifiche IT è importante?
Le organizzazioni moderne hanno alcune aspettative critiche e concorrenti nei confronti del loro team IT. In primo luogo, si aspettano servizi stabili e affidabili che assicurino un'organizzazione produttiva e in grado di soddisfare le aspettative degli utenti finali. In secondo luogo, il team IT deve implementare aggiornamenti regolari dei servizi per consentire all'organizzazione di adattarsi ai requisiti di business, sicurezza e costi in continua evoluzione.
Disattendere queste aspettative può comportare conseguenze disastrose. L'incapacità di mantenere l'affidabilità dei servizi può causare gravi danni alla produttività e ai costi. Secondo Gartner, molte organizzazioni riferiscono un tempo di inattività che può costare più di 300.000 dollari all'ora.Per alcuni servizi basati su Web, questa cifra può essere notevolmente più alta.
Allo stesso tempo, le organizzazioni che non si stanno adattando per il futuro non saranno in grado di stare al passo con la velocità del business e rimarranno indietro rispetto alla concorrenza. Un'eccessiva lentezza nell'implementazione delle modifiche può causare defezioni nei dipendenti, che potrebbero scegliere di lavorare in aziende con sistemi meno pesanti, o la scelta da parte dei clienti di affidare la propria assistenza e il proprio denaro al altre organizzazioni che offrono loro un maggiore valore.
Quindi, in che modo bisogna gestire queste esigenze in conflitto? Una pratica di gestione delle modifiche consente alla tua organizzazione di rilasciare aggiornamenti garantendo allo stesso tempo stabilità e riducendo i rischi. La gestione delle modifiche aiuta ad attuare le modifiche nei seguenti modi:
- Definizione di un framework per gestire il processo delle modifiche
- Definizione delle priorità delle modifiche necessarie per allocare correttamente le risorse
- Integrazione di informazioni pertinenti per un processo decisionale più intelligente
- Approvazioni effettuate con il coinvolgimento degli stakeholder di competenza dei team di sviluppo e IT
- Inclusione di test delle modifiche, per evitare imprevisti
- Semplificazione e miglioramento del flusso delle modifiche per fornire valore più rapidamente
Tipi di modifiche
ITIL definisce tre tipi di modifiche.
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.
Il processo gestione delle modifiche
Per i team Agile e high velocity, il processo di gestione delle modifiche sta abbandonando le lunghe revisioni e dalle approvazioni non tecniche da parte degli stakeholder a favore di processi automatizzati e collaborativi tra i team IT e di sviluppo che aumentano l'agilità pur continuando a bilanciare i rischi.
Ecco una panoramica di base di un processo di gestione delle modifiche, insieme ad alcuni consigli per aumentare la velocità di creazione del valore.
| Step | Best practice |
| Richiesta di modifica: qualcuno richiede una modifica e include delle note sui possibili rischi, l'implementazione prevista e i sistemi interessati. | Configura un portale self-service intuitivo dove gli stakeholder e il personale IT possano inviare facilmente una richiesta di modifica standard. nAssicurati che i team di sviluppo e i team IT possano collaborare sulla stessa piattaforma per ottenere il contesto completo e la trasparenza in tutto il flusso di lavoro di una richiesta di modifica. |
| Revisione della richiesta di modifica: un responsabile delle modifiche o delle peer review esamina la richiesta di modifica iniziale. Quali sono le probabilità che abbia esito positivo? I rischi e i benefici sono indicati in modo preciso? È opportuno procedere? | Usa l'automazione per approvare automaticamente la modifica o avviare un breve processo di approvazione prima che la modifica venga implementata. |
| Piano della modifica: il team crea un piano di gioco per la modifica. Documenta i risultati attesi, le risorse, la timeline, i requisiti di test e le modalità di ripristinare lo stato precedente alla modifica, se necessario. | Allinea rapidamente gli stakeholder con un avvio della gestione delle modifiche. Fai in modo che i team siano sulla stessa pagina con modelli di knowledge base per documentare i piani delle modifiche. |
| Approvazione delle modifiche: il responsabile delle modifiche, il responsabile della peer review o il CAB appropriato esamina il piano e approva la modifica. | Semplifica le approvazioni con le peer review. Evita la creazione di silos attraverso il monitoraggio e la documentazione del lavoro condivisi, affinché le persone possano collaborare in modo semplice e asincrono. |
| Implementazione delle modifiche: il team rilascia la modifica, documentando procedure e risultati lungo il percorso. | Usa l'automazione per abilitare i tuoi processi e standard. L'automazione del flusso di lavoro può instradare e assegnare le richieste alla persona autorizzata successiva in base alle regole aziendali. |
| Chiusura della modifica: se necessario, il responsabile delle modifiche esamina e chiude la modifica quando appropriato. Il loro report dovrebbe indicare se la modifica è stata positiva, tempestiva, stimata in modo preciso, nei limiti del budget e così via. | Mantieni l'accessibilità di articoli e ticket della knowledge base affinché i team possano imparare dal lavoro precedente. In futuro potrebbero emergere opportunità di automatizzare richieste di modifica. |
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.
Vuoi sapere di più su come Jira Service Management può trasformare il tuo processo di gestione delle modifiche?
Atlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
Leggi il whitepaperKnowledge base: la tua soluzione per una migliore collaborazione
Scopri la potenza di una knowledge base per la tua azienda. Aumenta la produttività, migliora il servizio clienti e semplifica la gestione delle informazioni in modo efficace.
Leggi l'articolo