Rifare il gestionale o recuperarlo? Il conto vero

La conclusione, subito

Rifare un gestionale da zero costa quasi sempre più del previsto, richiede più tempo di quanto ti dicono e non risolve i problemi che pensi di risolvere. La maggior parte delle volte conviene recuperare, migrare o rifattorizzare il codice esistente. Questo articolo mostra perché, attraverso gli errori più frequenti che si vedono sul campo, uno per uno.

Le sette voci che compongono il conto

Quasi tutti i preventivi di riscrittura contengono una voce sola: lo sviluppo. È la ragione per cui il conto finale non torna quasi mai. Un progetto di sostituzione del gestionale ne ha almeno sette, e sei di queste restano fuori dal preventivo che ti mettono davanti.

1. Analisi del sistema esistente. Capire cosa fa davvero il software prima di rifarlo. Si misura in giornate di lettura del codice e di interviste a chi lo usa. Saltarla non la elimina: la sposta a progetto avviato, dove costa il triplo.
2. Sviluppo del nuovo sistema. L’unica voce che di solito trovi scritta. Va chiesta divisa per modulo, non a corpo unico: è l’unico modo per accorgersi di cosa è stato dimenticato.
3. Migrazione dei dati. Estrazione, pulizia, normalizzazione, riconciliazione, e almeno un ciclo di test su dati veri. Si prezza a parte, sempre.
4. Doppio esercizio. I mesi in cui paghi il vecchio sistema e il nuovo insieme, e il personale lavora su entrambi.
5. Formazione e calo di produttività. Le settimane in cui il team va più piano perché sta imparando. Si contano in ore-persona, e sono ore che l’azienda paga comunque.
6. Integrazioni. Ogni sistema che oggi parla con il gestionale — fatturazione elettronica, e-commerce, banche, corrieri, CRM — va ricollegato. Contale una per una: è l’elenco che fa saltare le stime.
7. Recupero della conoscenza. Le regole di business che stanno solo nel codice e nella testa di chi ci lavora da anni. Ricostruirle richiede tempo e metodo.

Il modo di usare questo elenco è semplice: prendi il preventivo che hai in mano e verifica quante di queste sette voci sono scritte, con un numero accanto. Se ne trovi una o due, non stai guardando il costo del progetto: stai guardando il costo di una parte del progetto.

Il termine di paragone che manca

Il conto della riscrittura ha senso solo accanto a quello dell’alternativa. La domanda giusta non è “quanto costa rifarlo”, ma “quanto costa rifarlo rispetto a mettere in sicurezza e far evolvere quello che c’è”. Il secondo numero quasi nessuno lo calcola, e quasi sempre è più basso — a volte di un ordine di grandezza, perché lavora su un sistema che le regole di business le conosce già.

L’errore più costoso: decidere senza misurare

Molti progetti di riscrittura totale partono da una sensazione, non da un’analisi. Il gestionale è lento, qualcuno si lamenta, l’interfaccia è brutta. Quindi si decide di rifare tutto.
Quello che manca, quasi sempre, è una risposta a tre domande precise: quanto codice è effettivamente rotto? Quante funzioni vengono usate ogni giorno? Quanto costerebbe sistemare solo le parti critiche?
Senza queste risposte, il budget per la riscrittura viene stimato su aspettative, non su dati. E le aspettative, in questo campo, sono sistematicamente ottimistiche.

Come si manifesta

Il progetto parte con uno scope definito. Dopo qualche settimana emergono dipendenze non documentate, logiche di business sepolte nel codice vecchio, integrazioni con altri sistemi che nessuno aveva mappato. Lo scope si allarga. I tempi slittano. Il costo finale supera il preventivo iniziale di una percentuale che, nella nostra esperienza, raramente è sotto il 40%.

Come si evita

Prima di decidere se rifare o recuperare, serve un’analisi tecnica del codice esistente: quante righe attive, quali moduli funzionano, dove stanno i colli di bottiglia reali. Non è un lavoro lungo, ma va fatto. Il risultato cambia spesso la decisione iniziale.

Sottovalutare la migrazione dei dati

La riscrittura del gestionale è una cosa. Spostare anni di dati operativi è un’altra, e spesso viene trattata come un dettaglio dell’ultima settimana.
I dati di un gestionale aziendale non sono mai puliti. Ci sono duplicati, campi usati in modo non convenzionale, logiche implicite che il software vecchio gestiva in silenzio. Quando li porti in un sistema nuovo, queste anomalie vengono a galla tutte insieme.
Un’azienda con qualche anno di storico può trovarsi a gestire una migrazione che richiede settimane di lavoro manuale di verifica, normalizzazione e riconciliazione. Settimane che non erano nel piano.

Come si manifesta

Il go-live viene posticipato perché i dati migrati non tornano. Le fatture del mese precedente non corrispondono. Il magazzino mostra quantità sbagliate. Si lavora in parallelo sui due sistemi per mesi, con il doppio del carico operativo.

Come si evita

La migrazione dei dati va pianificata e prezzata separatamente, prima di firmare qualsiasi contratto. Va incluso almeno un ciclo completo di test su dati reali, non su dati campione costruiti ad hoc. Se il fornitore non lo propone, chiediglielo tu esplicitamente.

Confondere “vecchio” con “da buttare”

Un gestionale scritto dieci anni fa non è automaticamente da riscrivere. Dipende da cosa fa, come è scritto e quanto è documentato.
Codice vecchio può essere affidabile, testato sul campo e ben conosciuto dal team. Codice nuovo può essere fragile, privo di test e scritto in fretta. L’età del software non dice nulla sulla sua qualità.
Questa confusione porta a un errore specifico: buttare via funzionalità che funzionavano bene per ricostruirle da zero, peggio di prima, con più bug e meno conoscenza del dominio.

Come si manifesta

La decisione viene presa in riunione, sull’impressione che il software “sembri di vent’anni fa”. Nessuno apre il codice. Dopo sei mesi il sistema nuovo ha meno funzioni del vecchio e più bug, perché le funzioni che il vecchio gestiva in silenzio non erano nell’elenco dei requisiti: nessuno le aveva scritte da nessuna parte.

Come si evita

Separa due giudizi che vengono sempre confusi: l’aspetto dell’interfaccia e la salute del codice sotto. Un gestionale può avere una grafica del 2010 e un motore solido, e in quel caso rifare la sola interfaccia costa una frazione della riscrittura totale. La valutazione va fatta sul codice: dipendenze aggiornabili, test presenti, moduli isolati o tutto intrecciato.

Ignorare il costo del “mentre si rifà”

Rifare un gestionale richiede mesi. Durante quei mesi, l’azienda continua a lavorare con il sistema vecchio, che non riceve aggiornamenti, non viene migliorato e si deteriora ulteriormente.
Chi gestisce le richieste operative nel frattempo? Chi fa manutenzione sul vecchio sistema se si rompe qualcosa? Chi forma il personale sul sistema nuovo quando è pronto?
Questi costi non compaiono quasi mai nel preventivo iniziale. Compaiono però nella realtà operativa, sotto forma di ore extra, errori manuali e rallentamenti produttivi.

Come si manifesta

L’azienda si trova a pagare contemporaneamente per il vecchio sistema (manutenzione minima) e per il nuovo (sviluppo). Il personale operativo lavora con strumenti in transizione e commette più errori del solito. Il progetto, che doveva durare sei mesi, ne dura dodici. Il costo effettivo raddoppia.

Come si evita

Prima di avviare qualsiasi progetto di riscrittura, definisci esplicitamente il piano di transizione: chi mantiene il vecchio, chi sviluppa il nuovo, come avviene il passaggio, in quante fasi. Se questo piano non esiste, il progetto non è pronto per partire.
Se stai valutando questo tipo di percorso e vuoi capire da dove partire, raccontaci il tuo caso: spesso bastano poche domande per capire se la riscrittura è l’unica strada o se ci sono alternative più rapide.

Il preventivo “a forfait” che non regge

Rifare un gestionale è un progetto ad alta incertezza. I preventivi a forfait su progetti ad alta incertezza sono, per definizione, sbagliati: o sono gonfiati per coprire i rischi, o sono ottimistici e salteranno.
Eppure molti committenti li preferiscono perché danno una sensazione di controllo. Conoscere il numero finale prima di iniziare sembra più sicuro. Non lo è.
Quando il fornitore firma un forfait su un progetto che non capisce ancora fino in fondo, ha due opzioni: chiedere varianti a pagamento appena emergono i dettagli, oppure tagliare qualità e funzionalità per restare nei numeri. Entrambe le opzioni danneggiano il committente.
La nostra opinione netta su questo: il contratto a forfait su riscritture software complesse è uno strumento sbagliato per entrambe le parti. Un approccio a fasi con stime riviste a ogni fase è più onesto e produce risultati migliori.
Per capire come funziona la strutturazione corretta di un progetto software, vale la pena leggere come si articolano le fasi di sviluppo software in ordine corretto: cambia il modo in cui si stima e si gestisce il rischio.

Come si manifesta

Il forfait tiene per i primi due mesi. Poi arriva la prima variante, e la trattativa si sposta dal prodotto al contratto: cosa era compreso, cosa no, chi paga la differenza. Da quel momento ogni riunione è una negoziazione, e le decisioni tecniche vengono prese per ragioni contrattuali.

Come si evita

Dividi il progetto in due contratti separati. Il primo, a prezzo fisso e di durata breve, produce l’analisi: cosa c’è, cosa si tiene, cosa si rifà, con le sette voci quantificate. Il secondo si firma dopo, quando entrambe le parti sanno di cosa stanno parlando. Un fornitore che rifiuta di lavorare così ti sta dicendo che il numero che ha scritto non lo ha calcolato.

Quando recuperare è meglio che rifare

Ci sono situazioni in cui la riscrittura totale ha senso: stack tecnologico non più supportato, architettura che non può reggere i volumi attuali, codice senza documentazione e senza chi lo conosce. Ma sono casi specifici, non la norma.
Nella maggior parte dei casi, un approccio misto funziona meglio: si identifica il nucleo del sistema che vale la pena mantenere, si riscrivono i moduli critici o obsoleti, si migra gradualmente. Questo riduce il rischio, mantiene l’operatività e distribuisce il costo nel tempo.
La riscrittura totale ha un fascino comprensibile: si riparte puliti, senza il peso del passato. Ma quel peso spesso contiene anni di logica di business che non è documentata da nessuna parte, solo nel codice. Buttarla via significa ricostruirla da zero, con tutti gli errori che si faranno lungo la strada.
Chi si trova in questa situazione per via di un fornitore sparito o di codice non più manutenibile può trovare utile la guida su come recuperare software e dati quando il fornitore ha chiuso: molte delle stesse logiche si applicano anche quando il fornitore è ancora attivo ma il codice è in uno stato critico.

Come si riconosce il caso

Il recupero conviene quando il sistema regge il carico di oggi, le regole di business dentro sono corrette e il problema vero è altrove: dipendenze non aggiornate, nessun test, nessuna documentazione, un fornitore che non risponde. Sono problemi di manutenzione, non di architettura, e si risolvono senza buttare via niente. Vedi anche come funziona un intervento di software rescue.

Il costo che non si vede: la conoscenza persa

Ogni gestionale aziendale incorpora anni di decisioni: come si calcola uno sconto, come si gestisce un’eccezione, come si tratta un cliente particolare. Queste regole sono nel codice, spesso senza documentazione.
Quando si riscrive da zero, queste regole vanno ricostruite. Chi le conosce? Di solito, le persone che lavorano con il sistema da anni. Ma intervistarle tutte, sistematicamente, richiede tempo e metodo. Quasi nessun progetto di riscrittura lo fa in modo adeguato.
Il risultato: il sistema nuovo manca di comportamenti che nel vecchio erano ovvi. Gli utenti si lamentano. Si aprono ticket. Si aggiungono funzionalità che “nel vecchio c’erano”. Il costo sale ancora.
Documentare le regole di business prima di iniziare qualsiasi riscrittura non è un lusso. È il lavoro che determina se il progetto avrà successo o no. E sulla manutenzione del software custom come pratica strategica c’è un ragionamento più ampio che vale la pena fare prima di trovarsi in questa situazione.

Se stai valutando se rifare il tuo gestionale o trovare un percorso alternativo, scrivici: analizziamo il codice esistente e ti diciamo cosa vale la pena tenere e cosa no, senza partire dalla soluzione.
“`json
“`