Decidere di consolidare è di solito la parte facile. Lo stack è costoso, nessuno si fida dei numeri e il caso si costruisce da solo. Ciò che affonda questi progetti è l'ordine in cui accadono le cose.
Quasi ogni consolidamento fallito appare uguale visto da dentro: mesi di costruzione, una grande data di passaggio, due settimane difficili e un team che continua in silenzio a usare il vecchio foglio perché il nuovo sistema non fa l'unica cosa che serviva il primo giorno. Dopo di che la fiducia è andata, e non torna a buon mercato.
Ecco la sequenza che lo evita.
Regola 1: parti dal dolore, non da dove l'architettura è ordinata
C'è sempre un punto di partenza tecnicamente soddisfacente — di solito il modello dati sotto a tutto, o il modulo con meno dipendenze.
Resisti. La prima cosa che rilasci dovrebbe essere quella di cui la gente si lamenta di più, anche se è scomoda dal punto di vista architetturale, perché il primo rilascio ha un compito oltre alle sue funzioni: deve convincere le persone che vivranno dentro questo sistema che sarà meglio. Un primo rilascio che elimina un fastidio quotidiano vero ti compra pazienza per tutto il resto. Un primo rilascio tecnicamente elegante di cui nessuno si accorge non ti compra nulla.
Chiedi al team quale parte della loro settimana cancellerebbero. Costruisci quella.
Regola 2: fai girare vecchio e nuovo in parallelo, deliberatamente
Il funzionamento in parallelo viene trattato come mancanza di coraggio. È l'opposto — è ciò che rende il passaggio reversibile.
Per un periodo definito il nuovo modulo fa fede e il vecchio strumento resta consultabile. Nessuno è costretto a fidarsi dei nuovi numeri per fede; può verificare. Quasi tutti verificano due volte e poi smettono, ed è esattamente il punto. Il costo è un po' di lavoro duplicato per qualche settimana. L'alternativa è un passaggio senza via di ritorno.
Due cose da decidere in anticipo, o il parallelo diventa permanente:
- Cosa lo chiude. Una data, o una condizione — "due cicli di fatturazione completi senza discrepanze". Mettilo per iscritto.
- Quale sistema vince in caso di disaccordo. Dal primo giorno di parallelo il nuovo sistema è la fonte di verità e il vecchio è un riferimento. Se fanno fede entrambi, hai peggiorato il problema dei dati, non risolto.
Regola 3: migra i dati in tre passate, non in una
La migrazione dei dati è dove i consolidamenti muoiono in silenzio, perché il problema non è mai lo spostamento — è scoprire com'è fatto davvero il tuo dato.
Prima passata: un campione. Qualche centinaio di record, presto, prima che ci si costruisca sopra qualcosa. È qui che scopri che lo stesso cliente esiste quattro volte con quattro grafie diverse, che un campo obbligatorio è stato usato per tre scopi diversi dal 2019 e che una colonna data contiene testo libero. Ogni azienda ha una sua versione di questo. Scoprirlo la seconda settimana è una scoperta; scoprirlo la settimana prima del go-live è una crisi.
Seconda passata: prova generale completa. Tutto, in un ambiente di staging, con un report di riconciliazione: conteggi per entità, totali che devono quadrare col vecchio sistema e un elenco esplicito dei record falliti e del perché. Mostra quell'elenco a chi possiede i dati. Riconosceranno cose che tu non puoi vedere.
Terza passata: quella vera. A questo punto è meccanica, perché le sorprese sono già successe.
La trappola è trattare la migrazione come un'attività di fine progetto. È un'attività di scoperta, e va all'inizio.
Non stai migrando dati. Stai scoprendo cosa i tuoi dati nascondevano.
Regola 4: non ricostruire le soluzioni di ripiego
Ogni stack frammentato ha accumulato workaround — il campo stato usato come flag, la convenzione di nomenclatura che codifica una categoria, il foglio che esiste perché il sistema non sapeva esprimere qualcosa.
Sono tutti requisiti travestiti, e vanno divisi in due pile. Alcuni codificano una regola di business vera che il vecchio software non sapeva esprimere: modellala per bene nel nuovo sistema. Altri sono cicatrici di un limite che non esiste più: cancellali.
Il modo di fallire è riprodurli fedelmente tutti, cioè pagare un sistema nuovo che si comporta esattamente come il vecchio. Se esiste un workaround, chiedi cosa stava aggirando e se quel vincolo esiste ancora. Spesso nessuno se lo chiede da anni.
Regola 5: automatizza dopo l'adozione, non prima
È tentante lanciare gli agenti AI col primo modulo. Non farlo.
Gli agenti agiscono sui tuoi dati, quindi servono dati puliti e un processo che si sia assestato. Automatizzare un processo ancora in movimento significa rifare l'automazione a ogni spostamento — e se un agente produce un risultato sbagliato la prima settimana, le persone concludono che l'intero sistema è inaffidabile, non che la regola andava tarata.
Lascia che un modulo giri manualmente finché non diventa noioso. Poi automatizza la parte noiosa. È anche il motivo per cui lo strato agentico arriva per ultimo nel modo in cui organizziamo le fasi.
Una forma realistica
Per un'azienda di media dimensione che consolida sei-otto strumenti, tende ad apparire così:
- Settimane 1–2: mappatura dei processi e primo campione dati. Aspettati scoperte scomode.
- Settimane 3–6: il modulo di massimo dolore live, in parallelo.
- Settimane 6–12: altri due o tre moduli, ciascuno in parallelo e poi in esclusiva. I vecchi strumenti iniziano a essere disdetti.
- Dal mese 4: i moduli restanti, poi gli agenti sui processi che si sono assestati.
Nota cosa manca: una singola data in cui cambia tutto. Non c'è, e un piano che ne ha una merita di essere riesaminato.
La cosa che nessuno mette a budget
Il tempo del tuo team. Non la costruzione — la discovery.
Le persone che sanno come il lavoro accade davvero sono, senza eccezioni, le più occupate che hai. Mappare un processo per bene significa osservare lavoro reale, non leggere un documento, perché il documento descrive il processo come progettato e il valore sta nella differenza tra quello e ciò che le persone fanno davvero.
Metti a budget quell'accesso in modo esplicito e presto. Cala nettamente una volta concordata la mappa, ma un consolidamento che non riesce a ottenere un'ora a settimana dal responsabile operations produrrà un sistema costruito su supposizioni — e scoprirai quali erano sbagliate nel momento peggiore.
Se vuoi un secondo parere sulla tua sequenza prima di impegnarti, è più o meno ciò che copre la nostra prima call. Prenotane una, o leggi prima le FAQ.
