La sesta parte si è occupata del report: di come smette di essere un file che assembli in due giorni e diventa una vista che apri sul momento presente. Con questo si completa il quadro che abbiamo costruito in sei parti: quando un foglio di calcolo smette di essere la risposta, quale file manda davvero avanti l'azienda, la pulizia dei dati prima di migrarli, l'ordine in cui si migrano le cose, chi vede cosa e la fine del report costruito a mano.

Resta la parte che decide se tutto questo darà frutti: il primo mese in produzione. E c'è una cosa che sa chiunque abbia gestito un progetto del genere. La maggior parte delle migrazioni non fallisce durante la realizzazione. Fallisce nelle prime settimane di utilizzo. Il sistema funziona, i dati ci sono, le schermate sono corrette, eppure il lavoro vero torna in silenzio al vecchio file. Questa parte spiega perché succede e propone un piano per evitarlo.

La resistenza non è ostinazione, è un calcolo del rischio

La prima cosa che incontri nella prima settimana è l'esitazione del team. L'errore comune è che il titolare legga quell'esitazione come resistenza al cambiamento o pigrizia e risponda con la pressione. Di solito non è né l'una né l'altra.

Il dipendente che prima apriva un file e chiudeva l'attività in due minuti ora ne ha bisogno di dieci per imparare il percorso nella stessa schermata. Dal suo punto di vista sta pagando oggi il costo di un beneficio di cui gli hanno parlato ma che ancora non vede, e risponde al proprio responsabile del lavoro di oggi, non del successo del progetto. L'esitazione è del tutto razionale.

Si accentua quando il proprietario del vecchio file è una persona la cui posizione in azienda si è costruita proprio sul conoscerlo. Chi era l'unico riferimento per un file può temere che il sistema renda superfluo il suo ruolo. Ignorare quel timore non lo elimina; lo spinge sottotraccia. Affrontarlo apertamente funziona meglio: affida a quella persona un ruolo dichiarato nel nuovo assetto come responsabile della qualità dei dati della sua area, così che passi dal custodire un file all'essere il riferimento per i dati stessi.

Il vero cambiamento del primo mese è che il lavoro è diventato visibile. Quando i dati stavano in un file, una registrazione in ritardo era invisibile. In un sistema resta traccia di chi ha registrato cosa e quando. Questo rassicura chi lavora con costanza e mette a disagio chi è abituato alla flessibilità, ed è meglio dirlo apertamente nella prima riunione che farlo scoprire dopo due settimane.

Il ritorno silenzioso al vecchio file

La cosa più pericolosa del primo mese non accade in modo rumoroso. Nessuno si oppone al sistema in riunione, ma una copia del vecchio file resta aperta sul computer di qualcuno, che ci registra perché è più veloce, con l'intenzione di riportare tutto nel sistema a fine settimana. Di solito non lo fa.

Ne deriva il peggior risultato possibile: due fonti di verità invece di una. Prima del progetto avevi un unico file impreciso che tutti accettavano come riferimento. Ora hai un sistema incompleto e un file incompleto, e nessuno sa quale sia più aggiornato. Sei messo peggio di quando hai iniziato, ed è uno degli schemi trattati in Perché i progetti ERP falliscono e come far riuscire il tuo.

I segnali compaiono presto, se li cerchi: una cifra citata in riunione che nel sistema non esiste, un file condiviso nella chat del team due settimane dopo il lancio, un dipendente che chiede di esportare i dati per lavorarci fuori e non li riporta mai indietro. Non affrontare nessuno di questi casi dando la colpa alla persona. Fai una sola domanda: che cosa gli dava il file che il sistema non gli dà? La risposta di solito è un passaggio mancante, un campo assente o un percorso più lungo del necessario, tutte cose risolvibili in pochi giorni una volta che le conosci.

Le lacune che emergono dopo il passaggio, non prima

Per quanto bene tu abbia pulito i dati in anticipo, come spiegato nella terza parte, emergeranno lacune che si potevano scoprire solo alla prima transazione reale. La logica è semplice: il file tollerava i vuoti, quindi una cella vuota restava vuota e niente ti impediva di emettere la fattura. Il sistema richiede il campo perché un passaggio successivo dipende da esso.

Ciò che di solito emerge in questa fase:

  • Anagrafiche incomplete di clienti e fornitori. Un cliente registrato solo con il nome, senza partita IVA, indirizzo o contatto documentato, dati che prima si chiedevano a voce quando servivano.
  • Saldi iniziali che non quadrano. Il valore di apertura di un cliente o di un articolo non coincide con quello del vecchio file, e la differenza viene fuori al primo estratto conto.
  • Stati mai classificati. Un ordine in sospeso, un pagamento parziale, un reso mai chiuso. Nel file erano una nota a margine; in un sistema hanno bisogno di uno stato definito.
  • Unità e prezzi multipli. Un articolo venduto a cartone e acquistato a pezzo, con un prezzo diverso per una fascia di clienti rispetto a un'altra, il tutto custodito nella testa del responsabile commerciale anziché messo per iscritto.
  • Eccezioni senza una regola alle spalle. Un cliente con condizioni speciali da anni senza alcun documento, per cui nessuno sa come definirlo nel sistema né chi abbia l'autorità per approvarlo.

Niente di tutto questo dimostra che la migrazione sia fallita. È il suo primo vero beneficio: il sistema ha messo a nudo ciò che il file nascondeva. Ma gestirlo richiede disciplina. Registra ogni punto in un'unica lista dichiarata, con la persona responsabile della risposta e una data di chiusura. Se gestisci ogni caso separatamente in una conversazione a parte, tornerà il mese successivo sotto un'altra forma.

Una formazione fatta una sola volta non basta

Lo schema più ricorrente nei progetti in difficoltà è una formazione erogata in un'unica sessione il giorno del lancio, a cui partecipano tutti e che percorre l'intero sistema dall'inizio alla fine. Poi ognuno torna alla propria scrivania avendo dimenticato quasi tutto, perché l'ha sentito prima di averne bisogno.

L'alternativa che funziona si basa su tre principi:

  • Forma il ruolo, non il sistema. Il contabile non ha bisogno delle schermate del magazzino e il responsabile commerciale non ha bisogno delle impostazioni dei permessi. Ogni team impara il percorso che farà ogni giorno, più breve e molto più mirato.
  • Ripeti dopo una settimana di utilizzo. La seconda sessione è quella che rende davvero, perché le domande che vi emergono sono reali, tratte dal lavoro quotidiano e non ipotetiche. E le domande che si ripetono tra i team ti dicono esattamente dove una schermata non è chiara.
  • Documenta con immagini, non con testo. Una pagina per ruolo con i passaggi in ordine e le schermate, appesa in bacheca o inviata a tutti. La maggior parte delle domande dopo il lancio riguarda la memoria, non la comprensione.

Ti serve anche, all'interno di ogni team, una persona a cui ci si rivolge per prima, perché un dipendente chiede a un collega prima di aprire un ticket di assistenza. Quel ruolo informale riduce i tempi di risposta più di qualsiasi canale di assistenza esterno. Questo tipo di gestione del cambiamento non riguarda solo l'abbandono dei fogli di calcolo, e lo abbiamo trattato come parte delle fasi di implementazione in Come implementare un ERP con successo.

Il punto di vista di Origami

Consideriamo il giorno del lancio come la metà di un progetto, non la sua fine. Un sistema non attecchisce in un'azienda solo perché funziona; attecchisce quando diventa la strada più breve per portare a termine il lavoro della giornata. Ogni giorno in cui il vecchio percorso resta più veloce del nuovo è un giorno che lavora in silenzio contro il progetto.

Per questo, nel primo mese, teniamo una lista dichiarata di osservazioni con le date di chiusura e misuriamo l'utilizzo reale anziché le impressioni: chi accede, quali transazioni vengono registrate nel momento in cui avvengono e in quale schermata le persone si bloccano. È ciò che applichiamo quando realizziamo sistemi su misura nell'ambito dei nostri servizi, perché correggere un piccolo intoppo nella sua prima settimana costa un'ora, mentre correggerlo dopo due mesi costa la fiducia di un intero team.

Un piano di trenta giorni

Questo è un piano che puoi applicare così com'è scritto, e la sua caratteristica più importante è che ogni fase ha una fine dichiarata:

  • Giorni 1-7: funzionamento in parallelo delimitato. Il lavoro viene registrato sia nel sistema sia nel vecchio file per un solo motivo: il confronto. A fine settimana prendi un piccolo campione, confronta le due cifre e annota ogni differenza in base alla causa e non all'entità.
  • Giorno 8: il vecchio file diventa di sola lettura. È in assoluto il passaggio più importante del piano. Il file resta disponibile per la consultazione e nessuno ci scrive. Senza una data di chiusura dichiarata, il funzionamento in parallelo prosegue all'infinito e finisce sempre con la vittoria del vecchio file, perché è più comodo.
  • Giorni 8-14: seconda formazione e chiusura delle lacune. Una breve sessione per team sulle domande effettivamente emerse e la chiusura dei primi cinque punti della lista delle lacune.
  • Giorni 15-21: misurare l'utilizzo. Verifica chi usa davvero il sistema e chi no e, per ogni transazione registrata in ritardo, chiedi perché. Ciò che impari è un segnale di quanto sia chiaro il percorso, non della disciplina individuale.
  • Giorni 22-30: stabilizzare e rivedere. Chiudi le osservazioni rimaste, produci il primo report mensile esclusivamente dal sistema e siediti mezz'ora con i responsabili dei team per individuare cosa succede ancora fuori dal sistema e perché.

La misura onesta del successo non è la soddisfazione del team in un sondaggio né il numero di schermate in uso. È un singolo momento: qualcuno smette di aprire il vecchio file senza che nessuno glielo chieda. A quel punto il sistema non è più un progetto che gestisci: è il modo in cui lavora l'azienda.

Chiusura della serie

In sette parti abbiamo percorso l'intero cammino: i segnali che un foglio di calcolo ha superato il suo limite, l'inventario che ti dice quale file sia davvero il tuo sistema, la pulizia dei dati, l'ordine in cui si migrano le cose, la configurazione dei permessi, la trasformazione del report costruito a mano in una vista in tempo reale e, infine, il superamento del primo mese.

La conclusione che vale la pena conservare è questa. Excel è uno strumento eccellente, e il problema non è mai stato lo strumento, ma ciò che gli si chiedeva di sostenere. Passare a un sistema è meno un aggiornamento tecnico che la decisione che i dati dell'azienda appartengono all'azienda e non a un file o a una persona. E si comincia con un piccolo passo: apri il file che oggi manda avanti la tua azienda e chiediti chi lo aggiorna, quando e cosa succede se quella persona è assente.

Fonti