La maggior parte dei disservizi e delle brutte sorprese non nasce da hacker o hardware, ma da qualcuno che ha cambiato qualcosa: un'impostazione, un aggiornamento, un fornitore, un listino. La gestione del cambiamento consiste nel fare queste modifiche in modo consapevole, con un secondo paio d'occhi e una via d'uscita. Sembra roba da grande azienda, ma un piccolo team può applicarne una versione in circa quindici minuti per modifica.
Che cos'è un processo di gestione del cambiamento?
È un modo semplice e ripetibile per proporre, valutare, approvare, eseguire e rivedere le modifiche a sistemi, strumenti o modi di lavorare. Lo scopo non è rallentare le persone, ma assicurarsi che quando qualcosa cambia le persone giuste lo sappiano, i rischi siano stati valutati e ci sia un piano se qualcosa va storto. La modifica può essere tecnica, come l'aggiornamento di un server, oppure operativa, come una nuova procedura di inserimento.
I sei passaggi
1. Richiesta
Annoti la modifica in un unico posto, anche con un modulo minimo: cosa cambia, perché, chi la chiede, la data desiderata e chi ne è toccato. Bastano un modulo condiviso, un ticket o un documento fissato in alto. Ciò che non è scritto non si può rivedere.
2. Valutazione del rischio
Si ponga tre domande: cosa potrebbe andare storto, quante persone o clienti se ne accorgerebbero e quanto è difficile tornare indietro. Classifichi la modifica a rischio basso, medio o alto. Correggere un refuso in una pagina interna è basso; cambiare il modo in cui si generano le fatture è alto. Il livello decide quanta parte del resto del processo serve.
3. Approvazione
Il via libera deve darlo una persona diversa da chi richiede. Per il rischio basso basta un breve messaggio di un collega. Per il rischio alto coinvolga il responsabile dell'area interessata e concordi un momento lontano dai periodi di punta, come la chiusura del mese o un lancio.
4. Rilascio
Scelga una finestra, avvisi in anticipo gli interessati e indichi chi svolge il lavoro. Se possibile, rilasci prima a un piccolo gruppo e poi a tutti. Una breve checklist evita che tutto dipenda dalla memoria.
5. Piano di ripristino
Prima di iniziare, scriva come tornare allo stato precedente e da cosa capirà che serve: ripristinare un backup, riportare un'impostazione al valore di prima, tornare al vecchio fornitore. Stabilisca la soglia in anticipo, per esempio: se gli errori durano 30 minuti, torniamo indietro.
6. Revisione
Dopo qualche giorno verifichi se la modifica ha funzionato e se è successo qualcosa di inatteso. Registri il risultato e una lezione appresa. È qui che il processo migliora: gli schemi nelle modifiche andate male mostrano dove le sue valutazioni del rischio erano troppo ottimistiche.
Come mantenerlo leggero in un piccolo team?
- Due o tre livelli di rischio. Basso: una nota e un controllo da parte di un collega. Medio: approvazione scritta. Alto: piano di ripristino e finestra programmata.
- Pre-approvi la routine. Le modifiche ricorrenti e ben note, come gli aggiornamenti mensili, si possono approvare una volta come modifiche standard e poi solo registrare.
- Un solo registro. Basta un elenco con data, responsabile, rischio, esito e link ai dettagli. Eviti di disperdere le tracce tra chat e caselle di posta.
- Una finestra fissa. Uno slot settimanale, per esempio il martedì mattina, semplifica la pianificazione e tiene le modifiche rischiose lontane dal venerdì pomeriggio.
- Preveda le emergenze. Quando qualcosa è guasto, lo ripari subito e lo documenti entro un giorno. Riveda poi le emergenze perché restino l'eccezione.
Un esempio semplice
Un'azienda di dieci persone vuole spostare i file condivisi presso un nuovo fornitore di archiviazione. La richiesta indica il motivo, un risparmio di costi, e che riguarda tutti. Il rischio è valutato alto, perché file persi bloccherebbero il lavoro e lo spostamento è difficile da annullare. Il responsabile operativo lo approva per una finestra di sabato e il team viene avvisato una settimana prima. Per primi si spostano due colleghi. Il piano di ripristino prevede di tenere il vecchio archivio in sola lettura per 30 giorni e di tornarci se il gruppo pilota segnala file mancanti. Una settimana dopo la revisione scopre che i collegamenti alle vecchie cartelle non funzionano più, e il team aggiunge un passaggio di correzione alla checklist successiva.
Errori comuni
- Trattare tutte le modifiche allo stesso modo. Se rinominare una cartella richiede la stessa burocrazia che sostituire il database, le persone aggireranno il processo.
- Saltare il piano di ripristino. La maggior parte dei team pianifica l'andata e dà per scontato che nulla andrà storto. È il piano di ritorno a limitare i danni.
- Approvare il proprio lavoro. Un secondo sguardo vede ciò che l'autore, troppo vicino al lavoro, non nota più.
- Non rivedere mai. Senza uno sguardo indietro il processo diventa un modulo e smette di insegnare qualcosa.
Come farlo durare
Parta dalla prossima modifica in programma, non da una policy completa. Bastano un modello di una pagina, un registro e uno slot settimanale; si aggiusti dopo un mese. Se il suo team segue già progetti e attività in FulcrumGrid Command Center, può registrare ogni modifica come attività con responsabile, data e checklist, così approvazioni e ripristini restano visibili accanto al resto del lavoro. Va bene anche un foglio di calcolo: conta più l'abitudine dello strumento.
Una buona gestione del cambiamento è soprattutto buona comunicazione: metterlo per iscritto, farlo controllare, sapere come annullare e imparare dal risultato.
Domande frequenti
Qual è la differenza tra gestione del cambiamento e gestione dei progetti?
La gestione dei progetti consegna lavoro nuovo con obiettivo, ambito e calendario. La gestione del cambiamento controlla come si approvano e si rilasciano le modifiche a sistemi e processi esistenti, per evitare disservizi. Si sovrappongono, e un progetto contiene spesso più modifiche.
Un team di cinque persone ha davvero bisogno di un processo di modifica?
Di uno molto leggero, sì. Un registro condiviso, un secondo controllo sulle modifiche rischiose e un piano di ripristino scritto costano poco e prevengono errori che un piccolo team non può permettersi di riparare.
Chi dovrebbe approvare le modifiche in un piccolo team?
Una persona diversa da chi richiede, che conosca l'area interessata, di solito il responsabile di quel sistema o processo. Per il rischio basso basta la conferma di un collega.
Che cosa si considera una modifica di emergenza?
Una modifica necessaria subito per ripristinare il servizio o fermare un danno in corso. La si esegue in fretta, la si documenta entro un giorno e la si rivede dopo, perché l'eccezione resti tale.
FulcrumGrid Command Center
Tenga le modifiche visibili e assegnate
FulcrumGrid Command Center permette di seguire ogni modifica come attività con responsabile, data e checklist, accanto a progetti e indicatori.