Da Excel a gestionale web: come un'azienda ha recuperato 20 ore di lavoro manuale a settimana

Il contesto: un'azienda intrappolata nei fogli di calcolo

Questa è la storia di un progetto per un'azienda manifatturiera con 15 dipendenti distribuiti tra ufficio commerciale, magazzino e amministrazione. Il loro flusso operativo si basava interamente su fogli Excel condivisi su Google Drive: ordini clienti, giacenze di magazzino, fatturazione e reportistica mensile. Ogni reparto aveva il proprio file, aggiornato manualmente, con formule fragili e dati che spesso non tornavano.

Il problema non era solo tecnologico. Era organizzativo. Ogni settimana si perdevano circa 20 ore tra copie manuali, errori di formula e dati duplicati. Il rischio di sovrascritture era costante: bastava che due persone aprissero lo stesso file e una delle due modifiche andava persa. Nessuno aveva una visione aggiornata in tempo reale dello stato degli ordini o delle giacenze. Le riunioni settimanali servivano principalmente a riallineare dati che avrebbero dovuto essere già coerenti.

Gestionale dedicato o software pronto?

La prima domanda posta dal cliente è stata: "Non possiamo usare un gestionale già pronto?". La risposta onesta è stata: dipende. Sono state valutate tre opzioni commerciali (Odoo, Dolibarr, un SaaS verticale di settore) e tutte presentavano lo stesso problema: richiedevano di adattare i processi aziendali al software, non il contrario. L'azienda aveva flussi specifici, come la gestione degli ordini con stati personalizzati legati alla produzione interna, che nessun software standard copriva senza pesanti customizzazioni.

In questo caso il costo di uno sviluppo dedicato in PHP era comparabile a un anno di licenze SaaS più l'adattamento. Va detto che un SaaS offre in cambio aggiornamenti, assistenza e tempi di avvio rapidi: con processi più standard sarebbe stata probabilmente la scelta migliore.

La raccolta dei requisiti

Sono state dedicate due giornate in azienda, una per reparto, a osservare come si lavorava realmente, non come si pensava di lavorare. La differenza è fondamentale: spesso i processi documentati non corrispondono a quelli effettivi. È stato mappato ogni passaggio, ogni scambio di email, ogni copia-incolla tra fogli. Il risultato è stato un documento di 12 pagine con wireframe e flussi operativi che il cliente ha validato prima di scrivere una riga di codice.

La soluzione tecnica: architettura del gestionale web

Il gestionale web è stato costruito in PHP con architettura MVC, database MySQL e un pannello admin dedicato. La scelta di PHP non è stata casuale: l'azienda aveva già un hosting Linux con supporto PHP, il che ha azzerato i costi infrastrutturali iniziali. L'applicativo è stato progettato per essere leggero, veloce e manutenibile nel tempo.

Moduli principali sviluppati

• Gestione ordini: inserimento con stati personalizzati (ricevuto, in lavorazione, pronto, spedito, fatturato), assegnazione a operatori, note interne per ogni stato
• Dashboard operativa: KPI aggiornati in tempo reale — ordini in corso, valore medio ordine, tempi medi di evasione, alert su ritardi
• Gestione magazzino: giacenze aggiornate automaticamente ad ogni movimento, soglie minime con alert, storico movimenti per prodotto
• Gestione ruoli: permessi per reparto — il magazziniere vede solo le giacenze, il commerciale vede ordini e clienti, l'admin vede tutto
• Export automatico: generazione file XML compatibile con il gestionale di fatturazione esistente, eliminando il doppio inserimento

Scelte tecniche rilevanti

È stato implementato un sistema di audit trail completo: ogni modifica a qualsiasi record viene tracciata con utente, timestamp e valore precedente. Questo ha risolto uno dei problemi più sentiti dal cliente, ovvero sapere chi ha cambiato cosa e quando. Il sistema di cache è basato su file per le query più pesanti della dashboard, con invalidazione automatica su ogni write. L'autenticazione usa sessioni PHP con token CSRF su ogni form.

Il processo di migrazione: da Excel al gestionale

La migrazione dei dati è stata la fase più delicata. Uno script PHP ha importato i dati dai fogli Excel esistenti, normalizzandoli e verificandone la coerenza. Su circa 4.000 righe di ordini storici, lo script ha identificato 127 incongruenze — dati che in Excel erano "corretti" solo in apparenza. Questo da solo ha giustificato l'investimento agli occhi del cliente.

Il passaggio è stato graduale: per due settimane i reparti hanno usato sia Excel che il gestionale, fino a quando tutti si sono sentiti sicuri di abbandonare i fogli. Il team è stato formato in una sessione di 3 ore, con un manuale operativo di 8 pagine scritto appositamente.

Risultati misurabili dopo 12 mesi

• 20 ore settimanali recuperate tra data entry, correzione errori e riallineamento dati — equivalenti a mezza risorsa full-time
• Zero sovrascritture: ogni modifica è tracciata con utente e timestamp, conflitti eliminati alla radice
• Dashboard operativa consultata ogni mattina dal team — il dato è diventato la base delle decisioni, non le sensazioni
• Tempo di onboarding nuovi dipendenti ridotto da 2 giorni a 3 ore grazie all'interfaccia intuitiva
• Errori di fatturazione ridotti del 90% grazie all'export automatico verso il gestionale contabile
• ROI raggiunto in 4 mesi considerando le ore risparmiate e gli errori eliminati

Cosa insegna questo progetto

Questo case study conferma tre principi utili in qualsiasi progetto di digitalizzazione. Primo: osservare prima di progettare. Passare tempo in azienda a vedere come le persone lavorano davvero vale più di qualsiasi documento di requisiti. Secondo: migrare gradualmente. Il big bang non funziona — le persone hanno bisogno di tempo per fidarsi del nuovo strumento. Terzo: la scelta tra software pronto e sviluppo dedicato è un calcolo, non una questione di principio. Se i processi sono standard un prodotto esistente conviene quasi sempre; se sono molto specifici, adattare un software generico può costare di più.

Il gestionale è in produzione da oltre un anno senza downtime significativi. Le richieste di nuove funzionalità arrivano dal team stesso — segno che lo strumento è stato adottato davvero, non imposto dall'alto.