La scena è ricorrente: un gestionale scelto con cura, mesi di lavoro, un budget importante, e dopo il rilascio le persone tornano ai vecchi fogli Excel. Il software «non andava bene». Quasi mai è vero. Il software era uno strumento ragionevole, ma è arrivato in un'azienda che non aveva ancora capito cosa gli stava chiedendo di fare.
Quando un progetto gestionale fallisce in una PMI, la causa è raramente tecnica. È quasi sempre qualcosa che andava fatto prima di toccare il software, e che è stato saltato per fretta o per ottimismo.
Il problema non è il software. È quello che viene prima.
I dati sui progetti software dicono una cosa scomoda da decenni. Lo storico CHAOS Report dello Standish Group, che misura da anni l'esito dei progetti IT, racconta che una quota minoritaria arriva in porto come previsto, una larga fascia resta «problematica» (in ritardo, oltre budget o ridotta nelle funzioni) e una parte viene abbandonata. Le percentuali variano per anno e per definizione di «successo», ma la fotografia di fondo non cambia: i progetti che si arenano sono tanti, e non perché manchino sviluppatori capaci.
La verità è meno glamour del codice: un gestionale eredita i problemi dell'azienda che lo adotta. Se il processo è confuso, il software lo renderà confuso più in fretta. Se i dati sono sporchi, li mostrerà sporchi a tutti. Lo strumento amplifica ciò che trova, non lo corregge da solo.
Le quattro cause vere del fallimento
Cambiano i settori e le dimensioni, ma le ragioni per cui un progetto gestionale deraglia sono quasi sempre queste quattro, e nessuna è una riga di codice:
- Processo mai mappato: si digitalizza il modo in cui si crede di lavorare, non quello reale, e il software descrive un'azienda che non esiste.
- Dati sporchi: anagrafiche doppie, codici incoerenti, storici incompleti che il nuovo sistema si limita a ereditare e mostrare a tutti.
- Aspettative non allineate: la direzione immagina un risultato, chi userà il sistema ne immagina un altro, e nessuno l'ha scritto nero su bianco.
- Cambiamento non accompagnato: il sistema viene consegnato e basta, senza che nessuno aiuti le persone a cambiare il modo di lavorare.
Notale: tre su quattro non riguardano il software. Riguardano la logica del lavoro e le persone. È lì che un progetto si decide, molto prima della prima schermata.
Mappare il processo è un deliverable, non un riempitivo
Mappare il processo significa ricostruire come il lavoro accade davvero: dove nasce ogni informazione, chi la tocca, dove si ferma, dove si duplica, quali eccezioni esistono che nessuno ha mai scritto. Non è una formalità da spuntare prima di «partire con lo sviluppo»: è il momento in cui si capisce cosa va digitalizzato e cosa conviene lasciare semplice.
È anche il momento in cui emergono le cose scomode: il passaggio che funziona solo perché una persona lo tiene insieme a mano, la regola che cambia da cliente a cliente, il foglio Excel parallelo che in realtà è il vero gestionale dell'azienda. Se queste cose non emergono in analisi, emergono dopo il rilascio, quando costano dieci volte tanto.
Per questo l'analisi del processo è un deliverable concreto, con un valore suo, non un costo da comprimere. È la fase che noi chiamiamo Ascolto, e da cui parte ogni software su misura: si entra nella logica del lavoro prima di decidere lo strumento, perché lo strumento si sceglie dopo il problema, non prima.
I dati sporchi che nessuno guarda
La migrazione dei dati è la parte che viene quasi sempre sottovalutata, perché sembra noiosa e «tecnica». In realtà è dove tanti progetti perdono la fiducia delle persone: il sistema nuovo si apre, e dentro ci sono i clienti doppi, gli articoli senza codice, gli storici a metà. La prima impressione è che il software sbagli, anche quando il software sta solo mostrando lo stato reale dei dati di partenza.
Mettere ordine nei dati prima della migrazione non è un dettaglio, è parte del progetto. E quando i sistemi che restano sono più di uno, va deciso fin dall'inizio come faranno a parlarsi, è il tema dell'integrazione dati tra CRM ed ERP: un gestionale che vive isolato ricrea il doppio inserimento che doveva eliminare.
Le aspettative si scrivono, non si immaginano
«Voglio un gestionale che mi semplifichi la vita» non è un requisito, è un desiderio. Il progetto fallisce quando questo desiderio resta non detto e ognuno lo riempie a modo suo: la direzione pensa ai report, l'amministrazione alle fatture, le squadre sul campo a non dover reinserire nulla a fine giornata. Tutti legittimi, tutti diversi.
Allineare le aspettative vuol dire decidere insieme, prima, cosa significa «successo» per questo progetto: quali problemi specifici risolve, quali no per ora, come ce ne accorgeremo. Un perimetro chiaro, non una lista di sogni. È più scomodo all'inizio e molto più economico alla fine.
Il cambiamento riguarda le persone, non i menu
Un gestionale cambia il modo di lavorare di chi lo usa ogni giorno. Se chi sta sul campo o allo sportello non è stato coinvolto, lo vivrà come un peso imposto e troverà il modo di aggirarlo, di solito tornando al vecchio foglio Excel. Lo strumento tecnicamente funziona, ma nei fatti nessuno lo usa: è il fallimento più silenzioso e più frequente.
Coinvolgere presto chi userà il sistema non è gentilezza, è progettazione. Sono loro che conoscono le eccezioni reali, e sono loro che decretano se un progetto vive o muore. Un sistema pensato con le persone, non solo per le persone, è un sistema che resta in uso.
Cosa fare prima di toccare il software
Se hai un progetto gestionale in mente, o uno fermo che non ha mai decollato, la sequenza che riduce davvero il rischio è questa, e si svolge quasi tutta prima del codice:
- Mappa il processo reale, eccezioni comprese, non quello descritto nei manuali.
- Guarda i dati di partenza e mettili in ordine prima di pensare alla migrazione.
- Scrivi cosa significa «successo»: quali problemi risolve e come lo misurerai.
- Coinvolgi presto chi userà il sistema, perché conosce il lavoro meglio di chi decide.
- Solo a questo punto scegli lo strumento, su misura o pronto, e parti da un nucleo, non dalla cattedrale.
È lo stesso ordine con cui lavoriamo noi: prima l'Ascolto del processo, poi la progettazione, poi il codice. Lo racconta la storia di come affianchiamo chi costruisce, e lo dimostra Verso Flow, il nostro gestionale per il lavoro sul campo, nato esattamente così, dalla logica operativa di chi coordina squadre e interventi, non da una lista di funzioni.
Se un progetto gestionale ti è già costato tempo e fiducia, o vuoi evitare che succeda, il primo passo non è scegliere un software. È capire il processo. Raccontaci come lavori oggi: partiamo da lì, non dal codice.