Gestionale su misura o Excel? Quando il foglio diventa un rischio, e come si migra senza fermarsi

Excel è uno strumento straordinario, e la maggior parte dei gestionali su misura che ho costruito ha sostituito un foglio di calcolo che aveva fatto egregiamente il suo lavoro per anni. Il punto non è che Excel sia sbagliato: è che, oltre una certa soglia, il foglio smette di essere uno strumento e diventa il punto più fragile dell'attività. Riconoscere quella soglia, e attraversarla senza fermare il lavoro, è il tema di questo articolo.

I segnali, letti da sviluppatore

Integrità dei dati

Un foglio senza convalida dei dati e protezioni adeguate lascia passare errori: una data scritta come testo, un codice cliente con uno spazio in più, una formula sovrascritta da un valore. Ogni errore si propaga in silenzio. Un database può imporre tipi, vincoli e relazioni, se progettati esplicitamente. La validazione applicativa e i controlli sulle regole di business restano necessari.

Concorrenza e versioni

Due persone lavorano sullo stesso file, o su due copie. Nascono «finale_v3_corretto.xlsx» e la domanda «qual è quello giusto?». La modifica condivisa nel cloud riduce copie e conflitti, ma non sostituisce transazioni e regole di concorrenza progettate per il processo.

Permessi

Chi deve vedere i propri dati vede anche quelli degli altri, o non può accedere affatto. Un foglio condiviso ha permessi per file, non per riga o per ruolo.

Tracciabilità

Chi ha modificato quel prezzo, quando, e cosa c'era prima? La cronologia del file può aiutare, ma va distinta da un audit log applicativo che registri le operazioni di business e i valori modificati.

Dipendenza da una persona

«Il file» lo capisce solo chi l'ha costruito. Formule annidate, macro, fogli nascosti. Quando quella persona non c'è, l'attività rallenta.

Funzioni che il foglio non ha

Accesso da telefono sul campo, notifiche e scadenze, pagamenti, documenti generati, integrazioni con altri sistemi. A quel punto si costruiscono catene di file, macro e copie a mano.

Prima di decidere: pronto o su misura

Esiste un software pronto che copre i requisiti indispensabili senza piegare il processo? Allora va valutato seriamente, con le sue API e il suo costo nel tempo. Il su misura ha senso quando il processo è specifico, centrale per l'attività, e i prodotti pronti obbligano a lavorare peggio di prima.

Come si progetta

Il modello dei dati prima delle schermate

Entità, relazioni, vincoli: clienti, pratiche, risorse, prenotazioni, pagamenti, e come si collegano. È la parte che dura di più e quella più costosa da cambiare dopo. Le schermate vengono di conseguenza.

Ruoli e permessi

Chi vede cosa e chi può fare cosa, definito per ruolo e applicato lato server, non nascondendo pulsanti nell'interfaccia.

Registro delle modifiche

Ogni operazione importante lascia traccia: chi, quando, valori prima e dopo. È una traccia applicativa distinta dalla cronologia delle versioni di un file.

Integrazioni

Pagamenti, fatturazione, email, calendario, sito. Ognuna come modulo separato, con gestione degli errori.

Come si migra senza fermarsi

1. Analisi dei fogli esistenti: colonne, formule, eccezioni, usi impropri. Spesso il foglio contiene regole di business mai scritte altrove.
2. Script di importazione ripetibile: mappatura sul nuovo modello, normalizzazione, deduplicazione, rapporto delle righe scartate.
3. Prove di migrazione ripetute su dati reali, finché il rapporto degli scarti è vuoto o spiegato.
4. Rilascio per moduli: prima la funzione più dolorosa, poi le altre. Per qualche settimana il foglio resta in sola lettura come riferimento.
5. Formazione breve sui flussi reali, non sul manuale.

Gli errori più comuni nei progetti su misura

• Riprodurre il foglio così com'è: le stesse colonne, le stesse abitudini, compresi i rimedi nati dai limiti di Excel. Il processo va ripensato, non copiato.
• Partire dalle schermate: senza un modello dei dati solido, ogni funzione nuova diventa un'eccezione.
• Tutto subito: un rilascio unico e completo, invece di moduli successivi, aumenta il rischio e ritarda il valore.
• Permessi rimandati: aggiungere ruoli e restrizioni a sistema finito costa molto più che progettarli all'inizio.
• Nessuna esportazione: i dati devono poter uscire in formati aperti, sempre.
• Chi lo usa escluso dall'analisi: chi lavora sul foglio ogni giorno conosce le eccezioni che nessun documento riporta.

Un buon progetto parte da poche funzioni che risolvono il problema più costoso, viene usato davvero, e cresce sulla base di ciò che emerge dall'uso.

Un caso vero: Altura Vela

Quando ho conosciuto Altura Vela, la gestione viveva in fogli Excel enormi, ingestibili. Eppure per loro erano la salvezza: avevano tenuto in piedi l'attività per anni e non potevano essere tolti dall'oggi al domani. Per questo non ho proposto di sostituirli: abbiamo costruito il gestionale insieme, con uno sviluppo attento e meticoloso, passo dopo passo, confrontando ogni risultato con quello dei fogli. Barche, skipper e soci sono finiti in un unico posto, con pagamenti con Stripe e alcune funzioni di intelligenza artificiale che tolgono lavoro ripetitivo a chi organizza corsi e uscite.

Oggi si usa solo il gestionale, e ai vecchi fogli si ripensa con un sorriso. Il risultato più concreto è operativo: la scuola riesce a gestire più barche di prima senza che l'organizzazione diventi più pesante. È il percorso che considero giusto: il foglio non è un nemico da abbattere, è il documento che ti dice cosa deve fare il nuovo sistema.

Esempio: impedire una sovrascrittura silenziosa

In un esempio con PostgreSQL, una prenotazione ha una colonna version intera. Il client invia la versione che ha letto; il server applica l’aggiornamento solo se corrisponde:

UPDATE prenotazioni
SET stato = $1, version = version + 1
WHERE id = $2 AND version = $3
RETURNING id, stato, version;

La query usa parametri, non stringhe concatenate. I controlli di autorizzazione restano obbligatori sul server. Se non viene aggiornata alcuna riga, l’applicazione distingue record non accessibile, record assente e conflitto senza esporre informazioni a utenti non autorizzati. Un conflitto richiede rilettura e una scelta esplicita, non un secondo invio cieco.

Nella migrazione confronto anche totali e relazioni, non solo il numero delle righe. Registro gli scarti e stabilisco quando cessano le scritture sui vecchi fogli, così il passaggio non crea due fonti di verità.

Come la vedo io

Il caso di Altura Vela è il progetto a cui penso quando scrivo questo articolo: il gestionale è un'applicazione che ho progettato e sviluppato da zero in Nuxt.js.

Per questo tipo di strumenti scelgo un'applicazione web: un solo codice, usabile da computer e da telefono, aggiornata con un deploy. E costruisco con il modello dei dati al centro, perché è lì che un gestionale vive o muore.

Aggiungo un consiglio pratico: non buttare via il foglio troppo presto. Nelle prime settimane è il riferimento con cui si verifica che il nuovo sistema produca gli stessi risultati, e spesso rivela regole che nessuno aveva detto. Lo si archivia quando i numeri coincidono, non prima.

Perché affidarlo a me

Programmo dal 1999: più di 300 progetti consegnati e più di 30 agenzie con cui ho collaborato, da Roma e da remoto. Progetto gestionali su misura partendo dal modello dei dati, con permessi per ruolo, registro delle modifiche e migrazione dei fogli esistenti.

Se il tuo lavoro dipende da un file che solo una persona capisce, scrivimi: in una chiacchierata di circa 20 minuti guardiamo il processo e capiamo se conviene un prodotto pronto o uno su misura. Il servizio è in App e gestionali su misura.