Sostituire un gestionale legacy senza fermare la produzione

In breve

Un gestionale legacy si sostituisce a fasi, non in un weekend: si isola un processo alla volta, si fanno convivere vecchio e nuovo sistema con i dati sincronizzati e si spegne il vecchio solo quando il nuovo ha già gestito quel processo in produzione per un ciclo completo.

• Il rischio vero non è tecnico, è operativo: fermare la fatturazione o la spedizione anche per un giorno costa più di tutto il progetto.
• La convivenza temporanea dei due sistemi non è uno spreco, è l'assicurazione che rende reversibile ogni passo.
• La migrazione dei dati è un progetto dentro il progetto e va iniziata molto prima del primo rilascio.
• Serve sempre un piano di rientro scritto: cosa si fa, chi decide e in quanto tempo si torna indietro se qualcosa non regge.

Perché il gestionale vecchio resta al suo posto per anni

Non resta per affezione. Resta perché è diventato il punto in cui si incontrano decine di prassi non scritte. Dentro un sistema che ha dieci o quindici anni non ci sono solo tabelle: ci sono campi usati per scopi diversi da quelli per cui erano nati, note che contengono informazioni strutturali, stampe che qualcuno usa ogni lunedì mattina e che nessuno ha mai documentato.

Il risultato è che nessuno sa dire con precisione cosa succederebbe spegnendolo. E quando nessuno sa rispondere, la decisione si rimanda. Nel frattempo il costo cresce in modo silenzioso: manutenzione su tecnologie che pochi sanno ancora toccare, impossibilità di integrare strumenti nuovi, lavoro manuale che compensa quello che il sistema non fa più.

Il primo passo di una sostituzione seria non è scegliere il nuovo sistema. È capire cosa fa davvero il vecchio.

Che cosa significa davvero "legacy"

Legacy non vuol dire vecchio. Vuol dire che il sistema è ancora indispensabile ma non è più evolvibile con costi e rischi ragionevoli. Sono segnali concreti di un legacy che sta diventando un problema:

• Le modifiche richiedono settimane anche quando la richiesta è banale, oppure nessuno se la sente di toccare certe parti.
• Non esiste un ambiente di prova: ogni modifica si fa direttamente sui dati reali.
• L'integrazione con qualsiasi strumento esterno passa da esportazioni manuali in file.
• Le competenze sono concentrate in una o due persone, interne o esterne.
• Il fornitore originario non esiste più, o il contratto copre solo l'assistenza sui malfunzionamenti.

Se riconoscete tre di questi punti, la domanda non è più se sostituirlo, ma con quale ordine.

Big bang o sostituzione progressiva?

Esistono due strategie e una sola è ragionevole nella maggior parte dei casi.

Il big bang è attraente sulla carta perché evita il costo della convivenza. Ma quel costo è un premio assicurativo: si paga per avere la possibilità di fermarsi. In un'azienda che produce o spedisce ogni giorno, la possibilità di fermarsi vale molto più di qualche mese di doppia licenza.

Le cinque fasi di una sostituzione controllata

1. Mappatura del reale. Si ricostruisce cosa fa il sistema oggi partendo da chi lo usa, non dalla documentazione. Si elencano processi, stampe, esportazioni, integrazioni e prassi manuali. Questa fase produce l'unico documento che conta: la lista di ciò che non può smettere di funzionare.
2. Scelta dell'ordine. Si decide quale processo si sposta per primo. La regola è partire da un processo con confini chiari, impatto verificabile e nessuna dipendenza bloccante a monte: spesso è l'anagrafica clienti o il ciclo degli ordini in ingresso, quasi mai la fatturazione.
3. Convivenza. Il nuovo sistema entra in produzione su quel processo mentre il vecchio continua a funzionare su tutto il resto. I dati condivisi vengono sincronizzati in una direzione sola, decisa a tavolino, per evitare che due sistemi scrivano lo stesso dato.
4. Collaudo in parallelo. Per un ciclo completo — un mese, un trimestre, a seconda del processo — gli stessi dati passano da entrambi i sistemi e i risultati si confrontano. Le differenze si spiegano tutte, una per una. Un progetto che tollera differenze inspiegate sta accumulando debito.
5. Spegnimento. Il vecchio sistema si spegne per quel processo solo quando il collaudo ha chiuso senza differenze. I dati storici si conservano in sola lettura, in un formato consultabile anche fra dieci anni.

Poi si ricomincia dal punto due con il processo successivo. È lento e sembra poco efficiente. È l'unico modo in cui l'azienda non si ferma mai.

La migrazione dei dati è un progetto a sé

È la parte che viene sistematicamente sottostimata. Non si tratta di copiare tabelle: si tratta di decidere cosa portare, in che forma e con quale significato.

Le domande da risolvere prima di scrivere una riga

• Quanto storico serve davvero? Spesso bastano tre anni di documenti e l'intera anagrafica. Il resto può restare consultabile in archivio senza entrare nel nuovo sistema.
• Cosa facciamo dei dati sporchi? Migrare duplicati e anagrafiche incoerenti significa portarsi il problema nel sistema nuovo. Conviene affrontarlo prima, con il metodo descritto nella guida sulla pulizia delle anagrafiche.
• Quali campi hanno cambiato significato nel tempo? È la scoperta più frequente: un campo nato per una cosa che da cinque anni ne contiene un'altra. Va deciso caso per caso con chi lo usa.
• Come verifichiamo che la migrazione sia corretta? Servono controlli numerici definiti in anticipo: totali per anno, conteggi per stato, saldi. Se i totali non tornano, la migrazione non è finita.

Il metodo che funziona

La migrazione non si fa una volta sola. Si fa decine di volte, in prova, su un ambiente separato, finché il procedimento non è ripetibile e automatico. L'ultima esecuzione, quella vera, deve essere l'ennesima ripetizione di un procedimento già collaudato, non un evento.

Come far convivere due sistemi senza creare caos

La convivenza funziona a una condizione: per ogni dato condiviso esiste un solo sistema che ha il diritto di modificarlo. L'altro lo riceve e lo usa, ma non lo tocca. Questa regola, chiamata proprietà del dato, evita il problema peggiore di tutti — due versioni divergenti dello stesso cliente o dello stesso ordine — che è molto più difficile da risolvere dopo che da prevenire.

Tecnicamente la sincronizzazione si realizza con integrazioni dirette tra i due sistemi, con la stessa logica descritta nella guida sull'integrazione tra sistemi aziendali. Operativamente servono tre cose: una frequenza di allineamento dichiarata, un registro degli scambi consultabile e un avviso automatico quando una sincronizzazione fallisce. Senza il terzo punto, i disallineamenti si scoprono dai clienti.

Le persone: la variabile che decide l'esito

Un progetto di sostituzione fallisce quasi sempre per resistenza, non per bug. Chi usa il vecchio sistema da dieci anni ci è velocissimo e, nelle prime settimane, con il sistema nuovo sarà più lento. Se questa fase non viene gestita, il nuovo sistema viene percepito come un peggioramento e si creano scorciatoie parallele.

• Coinvolgere presto chi lavora. Le persone che conoscono le prassi non scritte sono la fonte principale della mappatura. Coinvolgerle nella fase uno le rende partecipi, non vittime.
• Formare sul processo, non sui pulsanti. Chi capisce perché una cosa è cambiata la accetta. Chi impara solo dove cliccare si blocca alla prima eccezione.
• Dichiarare che le prime settimane saranno più lente. Dirlo prima trasforma un problema in una previsione rispettata.
• Dare un canale per segnalare. Le segnalazioni vanno raccolte in un punto solo, con un tempo di risposta dichiarato. Una segnalazione ignorata genera dieci scorciatoie.

Il piano di rientro

Ogni fase deve avere un piano di rientro scritto prima del rilascio, non improvvisato dopo. Deve contenere quattro elementi:

1. Le condizioni. Quali sintomi fanno scattare il rientro: un blocco superiore a un certo numero di ore, differenze nei totali oltre una soglia, impossibilità di emettere documenti.
2. Chi decide. Una persona sola, con un sostituto. Nelle situazioni di tensione una decisione collegiale non arriva mai.
3. Le operazioni. Cosa si riattiva, in che ordine, chi lo fa e quanto tempo richiede. Va provato almeno una volta, non solo scritto.
4. I dati inseriti nel frattempo. Come si recuperano i documenti creati nel nuovo sistema durante le ore di esercizio. È la parte che tutti dimenticano.

Un piano di rientro provato è ciò che permette di rilasciare con calma. Paradossalmente, chi lo prepara non lo usa quasi mai, perché la stessa prova fa emergere in anticipo i problemi che lo avrebbero reso necessario.

Quanto dura e quanto costa

Non esistono numeri validi per tutti, ma esistono ordini di grandezza ragionevoli. Un progetto di sostituzione su un'azienda con più reparti si misura in mesi, non in settimane, e il tempo si distribuisce in modo controintuitivo: la mappatura e la migrazione dei dati pesano spesso più dello sviluppo.

Le percentuali sono indicative e servono solo a fissare le proporzioni: se un preventivo attribuisce alla migrazione dei dati il cinque per cento del progetto, quel preventivo non ha ancora guardato i dati. Il ragionamento su come si costruisce una stima credibile è approfondito nella guida su gestionale su misura o standard.

Come interveniamo in NuvioLab

Partiamo sempre dalla mappatura, prima di qualsiasi proposta tecnica: parliamo con chi usa il sistema tutti i giorni e ricostruiamo la lista di ciò che non può smettere di funzionare. Da lì proponiamo un ordine delle fasi, non un preventivo unico per il progetto intero.

Ogni fase è pensata per essere reversibile: il vecchio sistema resta acceso finché il nuovo non ha già gestito lo stesso processo in produzione. Costruiamo la sincronizzazione dei dati, il collaudo in parallelo e il piano di rientro prima del primo rilascio, perché sono le tre cose che rendono possibile procedere senza fermare l'azienda.

Raccontaci qual è il sistema che non osate toccare: la prima cosa che facciamo è capire cosa c'è davvero dentro.