Software gestionale non usato: le cause vere e come salvare il progetto

shares

Software gestionale non usato: le cause vere e come salvare il progetto

Esiste una categoria di investimento che molte PMI italiane conoscono bene.

Il software gestionale comprato, implementato e mai davvero usato.

Il sistema è lì. La licenza si paga ogni mese. Ma il team continua a lavorare con i vecchi Excel. Le fatture si fanno ancora a mano. Il magazzino lo conosce solo chi ci lavora da vent’anni.

Non è un problema raro. Secondo il Panorama Consulting Group, il 67% dei progetti ERP nelle PMI non raggiunge gli obiettivi prefissati. E nella maggior parte dei casi, il software funziona. Il problema è altrove.

Questa guida analizza le cause reali — non quelle tecniche — e il metodo per recuperare un progetto che si è inceppato.

In sintesi

[LINK INTERNO 1]

Causa 1 — Nessuno ha spiegato il perché del cambiamento

Il problema più comune e più sottovalutato

Quando un’azienda adotta un nuovo gestionale, la direzione sa perché. Il team operativo quasi mai lo sa davvero.

Sa che deve usare un nuovo sistema. Non sa perché il vecchio non andava bene. Non sa cosa cambierà nel suo lavoro quotidiano. Non sa se il cambiamento è definitivo o se tra sei mesi si torna indietro.

In assenza di informazioni, le persone riempiono il vuoto con le proprie conclusioni. E quasi sempre quelle conclusioni sono negative.

Un’azienda di servizi logistici con 28 dipendenti ha implementato un ERP per 18 mesi senza risultati. Il sistema era configurato correttamente. Il problema era che nessuno aveva mai comunicato al team operativo cosa cambiava e perché. I responsabili di magazzino continuavano a usare i fogli carta perché “il computer si blocca e non ho tempo”. In realtà il sistema non si bloccava. Si bloccava la fiducia.

La soluzione non è stata tecnica. È stata una riunione di 90 minuti con tutto il team operativo in cui si è spiegato — per la prima volta — quale problema specifico il gestionale risolveva per ciascuno di loro.

Nel mese successivo l’adozione è salita dal 20% all’80%.

💡 Le persone non resistono al cambiamento. Resistono ai cambiamenti che non capiscono.

Errore da evitare: comunicare solo cosa cambia operativamente senza spiegare perché. Il perché è la leva che muove le persone.

Causa 2 — Gli obiettivi erano vaghi o irrealistici

"Migliorare l'efficienza" non è un obiettivo

Molti progetti ERP partono con obiettivi del tipo: “vogliamo essere più efficienti”, “vogliamo avere tutto sotto controllo”, “vogliamo digitalizzare i processi”.

Non sono obiettivi. Sono intenzioni.

Un obiettivo misurabile suona così: “ridurre il tempo di chiusura mensile da 8 giorni a 3 entro il sesto mese dall’avvio”. Oppure: “azzerare gli errori di evasione ordini entro il primo anno”.

Senza obiettivi misurabili, non c’è modo di sapere se il progetto sta funzionando. E senza quella misura, il team non ha un motivo concreto per adottare il sistema.

Un’azienda di produzione alimentare con 40 dipendenti ha avviato un ERP con l’obiettivo dichiarato di “avere più visibilità sui costi”. Dopo 12 mesi, nessuno sapeva dire se l’obiettivo era stato raggiunto. I dati c’erano nel sistema, ma nessuno li guardava. Nessuno aveva mai definito quale report, con quale frequenza, doveva essere letto da chi.

Il progetto è stato recuperato ridefinendo tre KPI specifici — margine per lotto di produzione, costo materie prime per unità, ore di fermo macchina — con un cruscotto dedicato per la direzione e un meeting mensile di revisione.

In sei mesi i KPI erano stabili e il team aveva finalmente un motivo concreto per mantenere i dati aggiornati nel sistema.

💡 Un KPI non misura solo il risultato. Dà al team un motivo per inserire i dati correttamente ogni giorno.

Errore da evitare: definire gli obiettivi solo per la fase di acquisto e dimenticarli durante l’implementazione. I KPI devono guidare ogni decisione di configurazione.

Causa 3 — I dati di partenza erano sporchi

Il problema che nessuno vuole affrontare

Migrare dati sbagliati in un sistema nuovo non risolve il problema. Lo trasferisce.

Anagrafiche clienti duplicate, codici prodotto obsoleti, giacenze di magazzino che non corrispondono alla realtà, listini prezzi non aggiornati da anni. Questi dati esistono in quasi ogni PMI che ha lavorato per anni con sistemi frammentati.

Quando arrivano in un ERP nuovo, creano errori immediati. Il team perde fiducia nel sistema. Torna ai vecchi metodi. Il gestionale diventa una fonte di problemi invece che di soluzioni.

Un’azienda di distribuzione materiali edili con 22 dipendenti ha migrato 12.000 codici prodotto nel nuovo ERP senza una pulizia preventiva. Il 34% dei codici era duplicato o obsoleto. Le giacenze migrate avevano uno scarto medio del 22% rispetto alla realtà fisica.

Risultato: i magazzinieri smettono di usare il sistema dopo tre settimane perché “le quantità sono sempre sbagliate”. L’azienda ha dovuto fermare l’operatività per due settimane per un’attività di pulizia e riconciliazione dati che avrebbe richiesto quattro giorni se fatta prima della migrazione.

La pulizia dei dati non è un’attività tecnica. È un’attività di business che richiede il coinvolgimento delle persone che quei dati li usano ogni giorno.

💡 Quattro giorni di pulizia dati prima della migrazione valgono più di due settimane di correzioni dopo il go-live.

Errore da evitare: delegare la pulizia dati al fornitore o al reparto IT. Solo chi usa i dati ogni giorno sa quali sono corretti e quali no.

Causa 4 — Troppe personalizzazioni hanno bloccato il progetto

Il paradosso della personalizzazione

Più si personalizza un ERP, più il progetto rallenta. Più rallenta, più cresce la lista delle personalizzazioni richieste. Alla fine il sistema non va mai in produzione perché “manca ancora qualcosa”.

È una trappola in cui cadono molte PMI, soprattutto quelle con processi molto consolidati e team con anni di esperienza nel vecchio sistema.

Ogni richiesta di personalizzazione nasce da un bisogno reale. Ma non ogni bisogno reale richiede una personalizzazione.

Un’azienda di arredamento su misura con 35 dipendenti ha accumulato 47 richieste di sviluppo custom nei primi sei mesi di progetto. Il fornitore non riusciva a stare dietro. Il go-live si spostava ogni mese. Il team era frustrato perché il sistema non era mai pronto.

La soluzione è stata una sessione di prioritizzazione con la direzione e i responsabili operativi. Di 47 richieste, 8 erano davvero bloccanti per il business. Le altre 39 erano miglioramenti desiderabili ma non indispensabili per partire.

L’azienda è andata in produzione con le 8 personalizzazioni core. Le altre sono state pianificate in rilasci successivi. Il go-live è avvenuto sei settimane dopo la sessione di prioritizzazione.

💡 Distingui tra ciò che ti serve per partire e ciò che ti serve per ottimizzare. Sono due fasi diverse.

Errore da evitare: approvare ogni richiesta di personalizzazione senza valutarne l’impatto sui tempi. Ogni sviluppo custom aggiunge settimane al progetto e rischi a ogni aggiornamento futuro.

Come recuperare un progetto ERP bloccato

Il metodo in 4 step

Se hai un gestionale che nessuno usa davvero, il progetto non è perduto. Ma richiede un intervento strutturato.

Step 1 — Diagnosi onesta. Organizza una sessione con i responsabili di ogni reparto. Fai una sola domanda: qual è la cosa che ti impedisce di usare il sistema ogni giorno? Raccogli le risposte senza giudicare. Troverai un pattern chiaro in 30 minuti.

Step 2 — Separa i problemi tecnici da quelli organizzativi. I problemi tecnici si risolvono con il fornitore. I problemi organizzativi si risolvono internamente. Non fare l’errore di portare al fornitore problemi che appartengono alla tua organizzazione.

Step 3 — Ridefinisci gli obiettivi con KPI misurabili. Scegli 2-3 KPI che il team operativo capisce e che dipendono dall’uso del sistema. Comunicali chiaramente. Inserisci una revisione mensile in calendario.

Step 4 — Pulisci i dati critici. Identifica le anagrafiche e i dati che generano più errori. Dedica una settimana alla pulizia con le persone che li usano. Non serve perfezionare tutto — serve rendere affidabili i dati che il team tocca ogni giorno.

Un progetto recuperato in questo modo non torna mai allo stesso livello di un progetto fatto bene dall’inizio. Ma può arrivare a un livello di adozione sufficiente per generare valore reale.

Domande frequenti

Quanto tempo serve per recuperare un progetto ERP bloccato?

Dipende dalla causa principale. Se il problema è organizzativo — comunicazione assente, obiettivi vaghi — un intervento strutturato produce risultati visibili in 4-8 settimane. Se il problema è nei dati, la pulizia richiede da 1 a 4 settimane a seconda del volume. Se il problema è tecnico — personalizzazioni mal sviluppate — i tempi dipendono dal fornitore. [LINK INTERNO FAQ]

È meglio recuperare il sistema attuale o cambiare gestionale?

Cambia sistema solo se il problema è nel prodotto — funzionalità mancanti strutturali, fornitore che non risponde, architettura tecnica obsoleta. Se il problema è organizzativo, cambiare software non risolve nulla. Porta gli stessi problemi nel nuovo sistema. Prima di decidere, fai la diagnosi con onestà. [LINK INTERNO FAQ]

Come convinco la direzione a investire ancora su un progetto che ha già fallito?

Presenta la diagnosi con dati concreti: quale percentuale del team usa il sistema, quali KPI non sono stati raggiunti, qual è il costo mensile stimato della non adozione. Poi presenta un piano di recupero con obiettivi misurabili e milestone chiare. Un piano credibile con numeri reali è molto più persuasivo di promesse generiche. [LINK INTERNO FAQ]

Hai un gestionale che nessuno usa davvero e vuoi capire come recuperarlo? Clion affianca le PMI italiane nella diagnosi e nel rilancio dei progetti ERP bloccati — senza partire da zero quando non è necessario. [LINK-CTA]

Il problema quasi mai è il software. Quasi sempre è il metodo. [LINK-CTA]

Wahab Shafiq — Digital Marketing Strategist, Clion spa. Segue progetti di recupero e rilancio di implementazioni ERP per PMI italiane, con focus su adozione, change management e ridefinizione degli obiettivi di progetto. Hai domande su come salvare un progetto gestionale bloccato? [LINK-CONTATTI]

Leave a Reply

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *