Una guida completa alla gestione dei cambiamenti in ITIL®

I panorami aziendali e le aspettative dei clienti sono in costante mutazione e la trasformazione digitale è diventata un fattore chiave del successo delle attività in ogni settore. La trasformazione digitale è incentrata sullo sfruttamento delle tecnologie disponibili per fronteggiare le sfide aziendali e cogliere al meglio ogni opportunità. Andando al nocciolo della questione, la trasformazione digitale non è altro che una gestione IT fatta bene, in grado di eliminare le aree problematiche ed equipaggiare la tua infrastruttura IT con gli strumenti per affrontare le sfide aziendali. Quindi, comporta l’implementazione di cambiamenti IT che aiutino la tua organizzazione ad applicar tecnologie nuove ad attività e processi IT già esistenti.

Questi cambiamenti possono essere semplici tanto quanto spostare le app di collaborazione sul cloud, per una migliore efficienza operativa, oppure scegliere un approccio mobile-first per una migliore consumer experience. Nonostante l’apparente semplicità, questi cambiamenti nascondono una serie di sfide logistiche. L’implementazione non corretta di un cambiamento significa far fare alla tua organizzazione un passo avanti e due indietro.

L’errore nell'aggiornamento della app mobile di una famosa banca, nel dicembre 2018, è un ottimo esempio di come non implementare un cambiamento. Il piano della banca di introdurre una nuova app di banking per dispositivi mobili, aggiornata e migliorata, era un’ottima idea e un’evoluzione necessaria. Ma già al momento del lancio, la nuova app era piena di problemi. La banca aveva introdotto la nuova app dopo aver ritirato quella vecchia. Quando la nuova app ha smesso di funzionare, migliaia di clienti sono rimasti senza la possibilità di accedere ai propri conti correnti tramite app. A peggiorare le cose, la comunicazione riguardo alla correzione dei problemi della nuova app è stata lacunosa, generando malcontento tra i clienti. La app mobile è rimasta inattiva per quattro giorni prima che la banca decidesse di ripristinare la vecchia applicazione.

Possiamo notare come la banca abbia sbagliato in varie fasi del cambiamento proposto: il rilascio di una app non pronta per la distribuzione, la mancanza di comunicazione e trasparenza verso gli utenti finali riguardo ai tempi di inattività associati all’aggiornamento fallito e l’assenza di un piano alternativo in caso di errore. Non è di certo questo il modo in cui vorresti implementare un tuo cambiamento.

Ed è qui che entra in gioco la gestione dei cambiamenti: è un aiuto nel gestire i vari cambiamenti della tua organizzazione, impostando un processo capace di introdurli in modo efficiente, senza ripercussioni sul resto dell’attività. La gestione dei cambiamenti riduce la probabilità di interruzioni simili a quella affrontata dalla banca dell’esempio.

In questa guida ci occuperemo del cosa, del perché e del come implementare una gestione dei cambiamenti. Imparerai come aiutare la tua organizzazione a restare al passo con l’andamento del settore grazie a cambiamenti più efficaci.

Diamoci dentro!

Che cos'è la gestione dei cambiamenti?

ITIL descrive la gestione dei cambiamenti come il processo di monitoraggio e gestione di un cambiamento attraverso il tuo intero ciclo di via, dalla proposta alla chiusura, con l’obiettivo di minimizzarne i rischi.

L’impostazione di un processo sistematico di gestione dei cambiamenti aiuta la tua organizzazione a implementare i propri cambiamenti senza incidenti e con un elevato tasso di successo.

Che cos’è un cambiamento?

Secondo ITIL, un cambiamento è una “aggiunta, modifica o rimozione di qualsiasi cosa possa avere un effetto diretto o indiretto sui servizi”.

In sostanza, qualsiasi cambiamento all’infrastruttura IT di un’organizzazione che abbia un effetto sulle sue operazioni è un cambiamento IT. Il che comprende la sostituzione di stampanti, proiettori, server e molto altro.

Qual è la differenza tra un incidente, un problem e un cambiamento?

Perché un’organizzazione ha bisogno della gestione dei cambiamenti?

Ora che sappiamo che cos’è la gestione dei cambiamenti, diamo un’occhiata al perché le organizzazioni ne hanno bisogno, a partire dagli obiettivi della gestione dei cambiamenti.

Gli obiettivi della gestione dei cambiamenti ITIL

Dare alle organizzazioni il potere di assumere il controllo e gestire i propri cambiamenti:

La gestione dei cambiamenti ti darà un maggiore controllo sul processo di cambiamento e ti aiuterà a implementare cambiamenti con un rischio minimo. Seguendo le procedure standardizzate, la gestione dei cambiamenti assicura che tutti gli aspetti di ogni cambiamento, come pianificazione, valutazione dei rischi e monitoraggio dell’implementazione, vengano gestiti efficacemente. L’utilizzo di uno strumento di service desk per il monitoraggio dei cambiamenti dall’inizio alla fine può fare miracoli e consentire all’organizzazione di gestire meglio la propria infrastruttura IT con cambiamenti ben pianificati ed eseguiti.

Aiutare le organizzazioni a implementare meglio i cambiamenti:

Monitorando l’intero processo, la gestione dei cambiamenti rende possibile alle organizzazioni di mantenere il controllo su tutte le richieste di cambiamento. Inoltre, rende più semplice l’identificazione e la riduzione del numero di cambiamenti non autorizzati. Consentendo agli utenti di presentare una richiesta di cambiamento (RFC) solamente tramite lo strumento di service desk, le organizzazioni potranno raccogliere immediatamente tutte le informazioni necessarie riguardo al cambiamento e quindi decidere se abbia bisogno di essere implementato. Un solido meccanismo di approvazione assicura che i cambiamenti ricevano tutti i permessi necessari prima di essere implementati.

Rendere possibile un miglioramento continuo:

La gestione dei cambiamenti non serve solo nei periodi grigi: il suo scopo è quello di aiutare le organizzazioni a migliorare continuamente infrastrutture e processi, così come restare al passo con l’andamento del settore assicurando la possibilità di introdurre i cambiamenti necessari in modo indolore e senza ripercussioni sull'attuale operatività dei servizi.

Benefit della gestione dei cambiamenti

Per l’organizzazione:

• Meno conflitti tra cambiamento grazie a una gestione più efficace.
• La possibilità di introdurre upgrade senza ripercussioni sulle operazioni.
• Meno cambiamenti non andati a buon fine.
• Un’accurata classificazione dei cambiamenti.

Per gli utenti finali:

• Una miglior comunicazione riguardo ai tempi di inattività e alla mancata disponibilità dei servizi dovuti a cambiamenti programmati.
• Un’operatività dei servizi più omogenea e con meno interruzioni causate da cambiamenti mal pianificati.

Come si può mettere in pratica la gestione dei cambiamenti?

Diamo un’occhiata a come si possa implementare la gestione dei cambiamenti nella tua organizzazione. La prima cosa da impostare è una procedura di cambiamento efficace che renda possibile pianificare e implementare i cambiamenti, dopo aver ottenuto l’approvazione necessaria. Ecco una procedura di gestione che puoi seguire per apportare dei cambiamenti in modo efficace.

Il processo di gestione dei cambiamenti

Fase 1: Presentazione

La prima fase è l’avvio del cambiamento. Comporta la raccolta delle informazioni di base tramite ticket, come il tipo di cambiamento e la sua priorità.

• Creazione: I ticket di cambiamento nascono dallo strumento di service desk. Le informazioni necessarie vengono raccolte direttamente all’inizio tramite un modulo di cambiamento con gli opportuni campi obbligatori.
• Definizione dei ruoli di cambiamento : Tramite l’uso dei ruoli di cambiamento, le organizzazioni possono delegare le responsabilità dei cambiamenti alle varie parti in causa e controllare il livello di accesso attribuito a ciascun ruolo in ognuna delle fasi del cambiamento.

Fase 2: Pianificazione

La fase successiva è quella in cui avviene la pianificazione dell’intero cambiamento. Un cambiamento ben programmato è il segreto di un’implementazione ben riuscita. Inoltre, è essenziale per ottenere le approvazioni necessarie ad implementare il cambiamento. Dettagli come l’impatto, i piani di implementazione e di backout e i relativi tempi di inattività vengono documentati per informare chiaramente tutte le parti in causa sul piano di cambiamento e convincerli che si tratti di una modifica che valga la pena realizzare.

Fase 3: Approvazione

In seguito, il piano di cambiamento deve essere approvato dal comitato consultivo per le modifiche (CAB), dal comitato consultivo per le modifiche di emergenza (ECAB) o da qualsiasi altra autorità che sia interessata dal cambiamento o che faccia parte dell’infrastruttura coinvolta nella modifica. La creazione di CAB su misura aiuta le organizzazioni a raggruppare il personale rilevante per una più facile gestione delle approvazioni. L'automazione del processo di approvazione velocizza l’intero cambiamento e assicura che nessuna richiesta di approvazione venga ignorata.

Nota: Il CAB è una combinazione di vari team e ruoli professionali. Potrebbe comprendere dirigenti di alto livello, manager dei team, personale tecnico, amministrativo, ecc. a seconda della gravità e della portata del cambiamento.

Fase 4: Implementazione

Una volta ottenute le necessarie approvazioni, il cambiamento può essere implementato. Le organizzazioni possono monitorare e gestire l’implementazione delle modifiche creando dei task o tramite un progetto.

• Delega del lavoro tramite task: I task sono creati e assegnati a vari tecnici di diversi team per gestire con facilità il lavoro svolto da tutte le persone coinvolte nell’implementazione del cambiamento. Task primari e secondari possono essere usati per impostare le dipendenze tra i task e assicurare che vengano eseguiti in un particolare ordine e che nessun task venga trascurato.
• Sfruttamento della gestione dei progetti: Le organizzazioni possono utilizzare i progetti per la gestione di cambiamenti su larga scala, come il trasferimento dell’intera struttura dell’organizzazione su cloud. I progetti supportano una maggiore portata di implementazione e possono aiutare a gestire meglio un numero elevato di task, persone e milestone. Una forte integrazione tra la gestione dei cambiamenti e dei progetti può apportare grandi benefici alle organizzazioni.

Fase 5: Revisione

A seguire, viene effettuata una revisione post-implementazione per assicurarsi che non ci siano deviazioni dall’implementazione voluta e per smussare qualsiasi problematica prima della chiusura del cambiamento.

Fase 6: Chiusura

Siamo arrivati all’ultimo passaggio nella procedura di gestione dei cambiamenti. L’esito del cambiamento è registrato come riuscito, fallito o incompleto. La registrazione dell’opportuno codice di chiusura rende le metriche di un’organizzazione molto più accurate e utili.

I cambiamenti non sono tutti uguali, dato che ognuno ha il proprio insieme di requisiti. Alcuni cambiamenti devono essere implementati il prima possibile, altri necessitano dell’approvazione dei vertici aziendali, altri ancora sono solo normali modifiche che vengono implementate ogni settimana.

Secondo ITIL, i cambiamenti possono essere suddivisi in tre tipi: standard, normali e cambiamenti di emergenza.

Cambiamenti standard:

Si tratta di modifiche già approvate, dal basso impatto, ben note e documentate. I cambiamenti standard richiedono una valutazione dei rischi e un’autorizzazione per la prima implementazione, ma le implementazioni successive possono essere effettuate senza tali precauzioni, a patto che il cambiamento non abbia subito modifiche.
Esempio: Sostituire la cartuccia di una stampante

Cambiamenti normali:

Un cambiamento normale deve percorrere l’intera procedura di cambiamento; va programmato, sottoposto a una valutazione dei rischi e autorizzato. I cambiamenti normali comprendono modifiche minori (con impatto e urgenza bassi o medi) e rilevanti (con impatto e urgenza elevati). Tutte le modifiche che non sono standard o di emergenza andrebbero trattare come cambiamenti normali e dovrebbero rispettare le procedure di cambiamento.
Esempio: Il trasferimento dei servizi locali su cloud

Cambiamenti di emergenza:

I cambiamenti di emergenza hanno impatto e urgenza elevati e richiedono di essere valutati, approvati e implementati rapidamente per poter ripristinare i servizi il prima possibile. Le modifiche ai componenti che interessano l’attività aziendale, e che quindi causano un periodo di inattività, sono trattate come cambiamenti di emergenza.
Esempi: Malfunzionamento del server primario, Interruzione del servizio di un data center, una patch di emergenza per una vulnerabilità di sicurezza.

Titolare del cambiamento:

Il titolare del cambiamento deve rispondere dell’intero processo di gestione del cambiamento, compreso il suo miglioramento. Dato che è il responsabile della gestione dei cambiamenti dell’organizzazione, di solito si tratta di un dirigente di alto livello.

Change manager:

Il Change manager gestisce l’implementazione del cambiamento e le attività ad esso correlate. Inoltre, dirige il CAB, i vari team e le parti in causa coinvolte e si coordina con loro.

Change initiator:

Il Change initiator è colui che avvia il cambiamento e aggiunge i piani di modifica e di implementazione, oltre agli altri dettagli richiesti. È anche colui che organizza il piano di implementazione del cambiamento. Un change initiator può essere un tecnico o un utente finale.

CAB:

Il CAB è un collettivo di vari membri dei diversi team e con vari titoli professionali. Essi analizzano insieme il cambiamento proposto, gli concedono l’approvazione e forniscono suggerimenti relativi alla modifica e alla sua implementazione.

Ruoli aggiuntivi:

Alcune organizzazioni utilizzano ruoli aggiuntivi oltre ai quattro principali, per delegare il lavoro e spalmare le responsabilità. Poter creare dei ruoli personalizzati aiuta ad aggiustare la gestione dei cambiamenti su misura per le esigenze della propria organizzazione. Alcuni ruoli aggiuntivi comunemente usati sono:

• Responsabile approvazione del cambiamento
• Responsabile implementazione del cambiamento
• Revisore del cambiamento
• Pianificatore del cambiamento

Ecco quattro sfide comuni che ostacolano la gestione dei cambiamenti.

1. Cambiamenti falliti:

   I cambiamenti possono impiegare un considerevole quantitativo di risorse, dato che la loro pianificazione richiede parecchio tempo e ricerche. Un gran numero di cambiamenti falliti può diventare rapidamente troppo costoso se viene lasciato incontrollato. Nel caso di cambiamenti all’infrastruttura, un tasso di fallimenti elevati può sfociare in problemi più grandi in fase di implementazione o durante l’esecuzione dei piani di backout. Un’elevata quantità di cambiamenti falliti è anche indice di un pessimo processo di gestione dei cambiamenti.

   Esempio: Zylker aveva programmato di aggiornare la propria infrastruttura di rete primaria, configurando una rete alternativa con un provider esterno; l’implementazione del cambiamento doveva avvenire dell’arco di un weekend. Durante la fase di implementazione, Zylker ha cominciato a ricevere ticket per l’interruzione del servizio, il che sembrava strano, vista l’esistenza di una rete alternativa. Quel che Zylker non sapeva era che anche il provider di rete stava effettuando la propria manutenzione programmata proprio in quel weekend, il che voleva dire che entrambe le reti erano inattive e, quindi, i servizi di Zylker non erano disponibili. Dato che il cambiamento non era stato pianificato a dovere, è finito per essere un fallimento.

2. Cambiamenti non autorizzati:

   I cambiamenti non autorizzati sono il risultato di un meccanismo di approvazione mediocre e dell’incapacità di coinvolgere le giuste parti in causa nella fase di approvazione. Questi cambiamenti aggirano i permessi necessari e possono finire per essere implementati se non vengono segnalati in tempo. I cambiamenti non autorizzati possono risultare in modifiche di cui la tua organizzazione non ha bisogno o che non è pronta a implementare. La morale è che i cambiamenti non autorizzati sono decisamente negativi, oltre che una spesa ingiustificata.

3. Troppi cambiamenti di emergenza:

   Come spiegato in precedenza, i cambiamenti di emergenza richiedono un’approvazione rapida affinché possano essere implementati al più presto. Considerare troppe modifiche come cambiamenti di emergenza può portare a ritardi nel caso capiti un vero cambiamento di emergenza che necessiti di essere implementato velocemente. É sempre bene esercitare cautela quando si classifica una modifica come cambiamenti di emergenza.

   Nota: La popolare favola del ragazzo che gridava al lupo è un’ottima analogia del perché il considerare troppe modifiche come cambiamenti di emergenza ci si possa ritorcere contro. Nel caso di una vera emergenza, la tua organizzazione potrebbe non prendere il cambiamento con la dovuta serietà e potresti trovarti senza le risorse necessarie a gestire l’emergenza.

4. Conflitti di cambiamenti:

   Una programmazione poco curata può dar luogo a conflitti di cambiamenti. Un conflitto di cambiamenti avviene quando due o più cambiamenti vengono inavvertitamente pianificati per essere implementati in contemporanea, ostacolandosi reciprocamente. Utilizzare un calendario dei cambiamenti per programmare meglio le modifiche può aiutare a evitare i conflitti di cambiamenti.

Ecco le modalità migliori per affrontare la gestione dei cambiamenti.

1. Identificare i tipi di cambiamento:

   Non tutti i cambiamenti sono uguali. Le modifiche hanno vari livelli di priorità e diversi requisiti, come spiegato nella sezione a proposito dei tipi di cambiamento. Di conseguenza, è importante identificare innanzitutto le tipologie di modifiche che la tua organizzazione potrebbe effettuare e, quindi, creare i diversi tipi di cambiamento per introdurli con efficacia.

2. Ideare procedure diverse per tipi di cambiamento differenti:

   Dato che tipi di modifiche diverse hanno ognuna il proprio insieme di requisiti, è necessario ideare processi differenti per soddisfare determinate esigenze. Utilizzare la medesima procedura di cambiamento per tutti i tipi di modifiche genererà solamente ritardi e implementazioni dei cambiamenti incomplete.

   Nota: Puoi creare vari flussi di lavoro di cambiamento per ognuno dei tuoi tipi di modifica.

3. Definire ruoli e responsabilità chiave:

   La definizione dei ruoli consente al change manager di delegare le attività e le responsabilità agli altri. I ruoli rendono più semplice la gestione delle modifiche e definiscono chiaramente le attività che ogni persona può eseguire.

4. Registrare, gestire e assegnare la priorità alle proposte di cambiamento:

   Una delle best practice è quella di avere un metodo organizzato per registrare tutti i tuoi cambiamenti, oltre che per gestirli e assegnare le priorità, il tutto in un unico luogo. Con una migliore visione d’insieme dei cambiamenti della tua organizzazione, potrai meglio decidere quale modifica abbia priorità sulle altre.

5. Ottenere informazioni chiare e utili sul rischio e l’impatto dei cambiamenti:

   Tutti i cambiamenti devono attraversare una fase di analisi di rischio e impatto per una miglior comprensione della modifica e per l’allocazione delle risorse necessarie. I dettagli di rischio e impatto dovrebbero essere noti in fase di pianificazione, in modo che il CAB abbia un quadro chiaro del cambiamento e possa fornire i propri suggerimenti.

6. Allestire un meccanismo di approvazione efficace:

   Definire il processo di approvazione rende più facile ottenere i permessi necessari affinché il cambiamento venga implementato. Assicura che tutti gli attori chiave siano a conoscenza delle modifiche e possano fornire i propri suggerimenti prima che il cambiamento venga implementato. Ciò aiuta a ridurre le modifiche non autorizzate.

7. Comunicare la programmazione e i tempi di inattività alle parti in causa:

   Mantenere informate le parti in causa riguardo alle modifiche programmate riduce il numero di incidenti provocati dai cambiamenti. Comunicare informazioni puntuali assicura inoltre che i cambiamenti non incidano negativamente su alcun servizio e che vengano effettuati in modo efficace. Come extra bonus, in genere la dirigenza è più contenta quando è informata durante l’intero ciclo di vita del cambiamento.

8. Misurare il progresso e l’efficacia dell’implementazione dei cambiamenti:

   Tenere d’occhio le modifiche per l’intero ciclo di vita assicura che nulla vada storto e che i cambiamenti siano implementati secondo il rispettivo piano. La misura delle metriche chiave dà un quadro chiaro dell’efficacia del tuo processo di cambiamento e consente di identificare le aree in cui apportare dei miglioramenti.

9. Essere dotati di un piano di emergenza:

   Non si è mai troppo preparati, quindi è sempre un’ottima idea considerare lo scenario peggiore e ideare un piano di backout durante la fase di pianificazione del cambiamento. Una pianificazione approfondita può fare la differenza tra una banale modifica fallita e un danno irreversibile alla tua struttura IT:

10. Implementare il miglioramento continuo del servizio:

    Sebbene la capacità di reagire alle emergenze sia una funzione cruciale della gestione dei cambiamenti, le modifiche devono avere una portata più ampia all’interno della tua organizzazione. Usare i cambiamenti per potenziare la tecnologia e i processi, e dunque continuare a incrementare la capacità della tua organizzazione di fornire servizi migliori, sta diventando un’importante funzione della gestione dei cambiamenti.

La gestione dei cambiamenti non termina necessariamente col completamento di una modifica. L’abilità della gestione dei cambiamenti ti introdurre modifiche in modo efficace può tratte grande beneficio dalle informazioni raccolte coi processi ITSM, e viceversa. La capacità di associare gli incidenti ai cambiamenti che hanno causato o che ne sono stati causa, o di aggiornare il CMDB basandosi sulle modifiche all’infrastruttura IT, sono solo l’inizio della creazione di una sana procedura ITSM che collabora con tutta la tua organizzazione per una gestione migliore.

Ecco come la gestione dei cambiamenti può integrarsi con i tuoi altri processi ITSM:

1. Gestione degli incidenti:

   Il monitoraggio degli incidenti che causano un cambiamento e di quelli causati da un cambiamento offre una miglior comprensione dell’impatto delle modifiche sulla tua organizzazione. Ad esempio, quando si eseguire l’aggiornamento di un router, potresti ricevere dei ticket che lamentano l’interruzione del traffico internet. Associare le modifiche agli incidenti che esse hanno causato aiuta a identificare rapidamente la causa di un incidente ed evita di dover assegnare delle risorse alla soluzione di incidenti che si risolveranno non appena sarà completato il cambiamento.

2. Adempimento delle richieste:

   È importante usare i cambiamenti per le richieste di servizi ad alto impatto, in modo da mantenere la tua infrastruttura sempre aggiornata. Senza i cambiamenti, una richiesta di servizio per l’upgrade di un server o la richiesta di un upgrade dello spazio di archiviazione di Azure hanno come unico risultato la creazione di un nuovo servizio. Invece, quando si usa un cambiamento per implementare una richiesta di servizio, è possibile raccogliere più informazioni, come il motivo del cambiamento e il piano di implementazione, ottenere le necessarie approvazioni da tutte le parti in causa e aggiornare il CMDB con questi nuovi dati.

   Nota: Usare una modifica per l’adempimento di una richiesta funziona al meglio per le richieste di servizi ad alto impatto e per qualsiasi richiesta di servizio che comporti un cambiamento nel CDMB. Se serve un aggiornamento del CMDB, allora serve anche una modifica!

3. Problem management:

   Il problem management richiede la creazione di un cambiamento per correggere la causa radice di un problema. Essere in grado di creare una RFC direttamente all’interno di un ticket di problem rende più semplice il monitoraggio di modifiche e problem associati. Inoltre, fornire un quadro migliore dei motivi per cui è necessario un cambiamento e denota la gravità del problem che ha dato il via alla modifica.

4. Gestione del rilascio e della distribuzione

   Il rilascio e la distribuzione degli aggiornamenti traggono benefici dall’approccio strutturato imposto dal processo di cambiamento. Proprio grazie alle modifiche, è possibile monitorare facilmente i piani di esecuzione, i piani di rollout e l’effettiva implementazione di rilasci e distribuzioni. La trasparenza e la visibilità offerte dai cambiamenti aiutano inoltre a mantenere informate tutte le parti in causa.

5. CMDB:

   Qualsiasi aggiornamento del CMDB deve sempre essere effettuato a mezzo di un cambiamento. Un cambiamento fornisce moltissime informazioni utili sul perché, il come e il quando l’aggiornamento è stato eseguito, L’analisi degli impatti effettuata durante un cambiamento assicura anche che qualsiasi aggiornamento del CMDB sia propriamente analizzato e che non crei alcuna interruzione per il resto dell’organizzazione. Si possono usare i tipi di modifica per registrare aggiornamenti CMDB di varia priorità.

KPI della gestione dei cambiamenti

Ecco alcune importanti metriche con cui misurare l’efficacia della tua procedura di gestione dei cambiamenti.

Esaminiamo un cambiamento nel dettaglio per vedere come sia possibile migliorare il processo di gestione dei cambiamenti.

Zylker, una compagnia con un enorme numero di utenti remoti, ha deciso di intraprendere il percorso verso il cloud.

Al momento, tutte le applicazioni e le risorse di produttività dell’azienda sono in-house, quindi gli utenti remoti sono dotati di accesso alla rete tramite VPN. In modo da fornire un accesso più rapido ai dati, Zylker decide di iniziare a usare le applicazioni cloud. Sceglie Zoho One per la sua suite di produttività e Office 365 per le e-mail. Parte delle risorse della compagnia, come i file server e i database, sono ancora locali, quindi agli utenti remoti deve comunque essere fornito l’accesso.

Per soddisfare questo requisito, il team IT configura un ambiente ibrido di Azure Active Directory (AD). Effettua quindi il provisioning del server federativo per replicare l’AD locale nell’AD basato sul cloud. Ora gli utenti finali, persino quelli remoti, possono accedere alle risorse cloud con le proprie credenziali AD.

Fase 1: Generazione della RFC

Il primo passo è la generazione di un ticket di cambiamento e la raccolta delle informazioni necessarie a proposito della modifica, come il tipo di cambiamento, il suo impatto e la sua urgenza, così come l’assegnazione dei ruoli del cambiamento. Il change initiator può facilmente emettere un ticket di cambiamento usando il proprio portale web e scegliendo il modello e il tipo di cambiamento appropriati. Il modello di cambiamento raccoglie tutte le informazioni necessarie grazie all’uso dei campi obbligatori. È in questa fase che il change initiator imposta il tipo di cambiamento come normale, seleziona l’appropriato modello di cambiamento, assegna i ruoli del cambiamento e fornisce una descrizione del motivo per cui è richiesta la modifica.

Fase 2: Pianificare il cambiamento

In seguito, il change initiator aggiunge le informazioni sul cambiamento, come il motivo della modifica, le informazioni dettagliate sul suo impatto, i piani di implementazione e di backout e il tempo di inattività atteso. Il change initiator aggiunge anche gli incidenti e i problem associati, per monitorare meglio il cambiamento e il suo impatto. Qui sotto sono riportati i vari piani ideati dal change initiator.

Piano di implementazione:

• Aprire account Azure AD e Office 365
• Impostare Active Directory Federation Services (ADFS)
• Avviare la sincronizzazione tra AD locale e Azure AD
• Configurare il single sign-on
• Sincronizzare Exchange locale con Office 365

Piano di backout:

Dato che la configurazione esistente è intatta, tornare alla vecchia configurazione e riprendere il servizio.

Tempo di inattività pianificato: 12 ore

Fase 3: Ottenere le giuste approvazioni

Il change manager sollecita i CAB a revisionare i piani di cambiamento e fornire i propri suggerimenti sull’opportunità di implementare la modifica o sull’eventuale bisogno di una correzione dei piani. Dato che si tratta di un cambiamento su larga scala, sono richieste approvazioni alle più diverse figure professionali sparse tra tutte le funzioni aziendali. Ecco un elenco dei CAB e dei rispettivi membri coinvolti nel processo di approvazione:

1. CAB di direzione:
   • Responsabile informatico (CIO)
   • Direttore tecnico (CTO)
   • Direttore finanziario (CFO)
   • Amministratore delegato (CEO)
2. CAB tecnico:
   • Service delivery manager
   • Responsabile attività operative
   • Information security manager
   • Responsabile per la protezione dei dati
3. CAB amministrativo
   • Direttore amministrativo
   • Responsabile delle risorse umane
   • Business relationship manager

Fase 4: Implementare il cambiamento nel modo giusto

Zylker usa i task per il monitoraggio dell’implementazione I task sono assegnati ai vari tecnici e l’ordine in cui devono essere eseguiti è definito tramite le dipendenze tra task. Il titolare del cambiamento può monitorare facilmente il progresso dell’implementazione della modifica e gestire i task in un unico posto.

Ecco come Zylker ha suddiviso l’implementazione in task che rendessero più semplice gestire l’adozione della modifica:

• Preparare Office 365 e Azure AD
• Impostare un ingest server
• Avviare la migrazione dei dati
• Configurare i proxy Azure AD
• Controllare l’integrità dei dati

Fase 5: Adesione al piano

In seguito, l’implementazione del cambiamento viene revisionata dal titolare/change manager per controllare che non ci siano state deviazioni dal piano. Qualsiasi deviazione è segnalata e risolta prima che il cambiamento possa essere considerato concluso con successo.

Fase 6: Chiusure del ticket di cambiamento

Infine, il cambiamento è chiuso e gli viene assegnato un codice di chiusura in base all’esito alla fine della modifica.

Fase 7: Raccolta delle metriche

Il change manager misurerà certi indicatori chiave di prestazione (KPI) per determinare l’efficienza del processo di cambiamento e identificare le aree che possono essere migliorate.

Ecco un elenco di funzionalità che devi tenere d’occhio quando scegli uno strumento per il service desk. La presenza di queste funzionalità ti aiuterà a implementare un’efficace procedura di gestione dei cambiamenti per la tua organizzazione.

Gestione dei cambiamenti

Creazione e registrazione dei cambiamenti

• Crea cambiamenti a partire da incidenti e problem, trasferendo dagli uni agli altri tutte le informazioni necessarie.
• Raccogli le informazioni utili tramite modelli di cambiamento personalizzati.
• Crea diversi tipi di cambiamento e genera flussi di lavoro univoci per ogni tipo.
• Coinvolgi le opportune parti in causa, come il titolare del cambiamento, il responsabile dell’approvazione, il responsabile di linea e il revisore della modifica grazie ai ruoli del cambiamento.

Pianificazione e valutazione del cambiamento

• Crea piani di cambiamento elaborati, che comprendono l’analisi dell’impatto e dei piani di implementazione, backout e tempo di inattività.
• Crea un elenco con tutti i passaggi essenziali da completare.

Approvazione del cambiamento

• Riunisci vari CAB.
• Configura molteplici livelli di approvazione. Determina se la RFC deve essere approvata da tutti i membri dei CAB o solamente da uno.
• Permetti al change manager di avere l’ultima parola riguardo all’approvazione del cambiamento.
• Salta l’approvazione del change manager e del responsabile dell’approvazione, approvando automaticamente il cambiamento quando tutti i membri del CAB si sono espressi a favore.
• Indica gli utenti finali come responsabili dell’approvazione delle richieste di servizio.

Implementazione coordinata del cambiamento

• Suddividi il cambiamento in task e usa i registri di lavoro per una stima di quanto impiegherà il team di implementazione del cambiamento a completare le attività.
• Semplifica l’implementazione creando dei progetti a partire da un cambiamento o associando un cambiamento a un processo esistente.
• Monitora tutti gli incidenti associati e le problematiche che hanno causato o sono state causate dalla modifica.
• Pianifica il tempo di inattività e annuncialo agli attori chiave.
• Mantieni informate tutte le parti in causa con notifiche regolari.

Revisore del cambiamento e chiusura

• Documenta l’a revisione post-implementazione (PIR).

Flussi di lavoro del cambiamento

• Crea dei flussi di lavoro distinti per i diversi tipi e processi di cambiamento, con vari livelli di complessità e varie funzioni.
• Configura azioni differenti come condizioni, switch, notifiche, aggiornamenti di campo e approvazioni durante la transizione tra le fasi.
• Progetta i flussi di lavoro del cambiamento su un canvas, trascinando blocchi selezionati.

Cambiamento:

Aggiunta, modifica o rimozione di qualsiasi cosa possa avere un effetto diretto o indiretto sui servizi.

Comitato consultivo per le modifiche (CAB):

Un team di varie parti in causa in grado di fornire suggerimenti a proposito della modifica e approvare il piano di cambiamento.

Conflitti di cambiamenti:

Un conflitto di cambiamenti avviene quando due o più cambiamenti vengono inavvertitamente pianificati per essere implementati in contemporanea, ostacolandosi reciprocamente.

Gestione dei cambiamenti:

Processo con cui si portano a compimento i cambiamenti, minimizzando interruzioni e conflitti.

Ruoli del cambiamento:

Delega delle responsabilità dei vari aspetti della modifica tra i diversi membri dell’organizzazione.

Codice di chiusura:

Usato per registrare l’esito della chiusura del cambiamento, come riuscito o fallito.

Configuration Management Database (CMDB):

Repository di tutti gli elementi di configurazione e i rispettivi rapporti.

Miglioramento continuo del servizio:

Processo di identificazione e correzione delle aree che possono essere perfezionate per offrire un servizio migliore.

Tempo di inattività:

Periodo di tempo per cui un particolare servizio non è disponibile.

Incidente:

Interruzione non pianificata o riduzione della qualità di un servizio IT. Anche l’errore di un elemento di configurazione, anche se non ha ancora avuto ripercussioni su alcun servizio, è considerato un incidente (es. errore di uno dei dischi usato per il mirroring).

Problem:

Causa o possibile causa di uno o più incidenti.

Revisione post-implementazione:

Processo di valutazione della bontà dell’adesione al piano di modifica senza deviazioni, oltre che un esame dell’implementazione per controllare che non ci sia qualcosa da cambiare.

Richiesta di cambiamento (RFC):

Processo di avvio di un cambiamento con un valido motivo.

Valutazione dei rischi:

Processo di stima dei rischi potenziali dipendenti da un cambiamento.

Service desk:

Punto di comunicazione tra il provider dei servizi e gli utenti dell’organizzazione.