Un ERP implementato male non si vede il giorno dell’avvio: si vede sei mesi dopo, quando il team tiene un foglio di calcolo parallelo perché il sistema “non va bene per quello che facciamo noi”. A quel punto licenza, consulenza e migrazione sono già state pagate, e tornare indietro costa più che andare avanti.
Quasi tutti i progetti che deragliano lo fanno per le stesse ragioni, e nessuna è tecnica. Questi sono i dieci errori che si ripetono più spesso e come riconoscerli in tempo.
In breve: le implementazioni ERP raramente falliscono per colpa del software. Falliscono per perimetro mal definito, dati di origine sporchi, eccesso di personalizzazione, assenza di un referente interno con potere decisionale e formazione rimandata alla fine. Sono problemi di gestione, e sono tutti evitabili.
1. Partire senza aver mappato i processi
È l’errore di origine da cui nascono quasi tutti gli altri. Si compra l’ERP e solo dopo si scopre come lavora davvero l’azienda, di solito a metà configurazione.
Il processo documentato e il processo reale non coincidono quasi mai. La persona dell’amministrazione applica da otto anni un’eccezione che non è scritta da nessuna parte e che si rivela essere il 30% degli ordini.
Come evitarlo: dedica le prime settimane a documentare il flusso reale — non quello del manuale — dall’ordine all’incasso e dall’acquisto al pagamento. Siediti con chi lo esegue ogni giorno, non solo con chi lo dirige. È quella mappa che poi permette di decidere con criterio cosa si standardizza e cosa si rispetta.
2. Definire il perimetro come una lista dei desideri
Quando si chiede a ogni reparto di cosa ha bisogno, escono duecento requisiti e sono tutti “imprescindibili”. Il risultato è un progetto che non sta nel budget e che viene tagliato a metà strada, quasi sempre dove fa più male.
Come evitarlo: classifica ogni requisito in tre scatole: blocca l’operatività, fa risparmiare tempo misurabile e sarebbe bello averlo. La prima scatola entra nella fase 1, la seconda si ordina per ore risparmiate al mese, e la terza si rivede sei mesi dopo l’avvio. Molti di quei requisiti cadono da soli appena si vede il sistema in funzione.
3. Migrare dati sporchi
È la causa numero uno dei ritardi, e la più sottovalutata. Nessuno vuole ammettere che l’anagrafica clienti ha duplicati, codici obsoleti e campi compilati a mano con criteri diversi a seconda dell’anno.
Un ERP non sistema tutto questo: lo eredita e lo amplifica, perché ora quel dato alimenta contabilità, magazzino e fatturazione contemporaneamente.
Come evitarlo: verifica i dati prima di firmare il calendario. Conta duplicati, buchi e valori fuori range su clienti, articoli e fornitori. Pulisci alla fonte e approfittane per archiviare ciò che non si usa più: migrare quindici anni di storico che nessuno consulta fa lievitare il progetto senza portare nulla. La nostra guida su migrare da Excel a un ERP entra nel dettaglio di questa fase.
4. Personalizzare tutto dal primo giorno
La personalizzazione dà dipendenza perché in riunione sembra sempre ragionevole. Il problema arriva al primo aggiornamento del prodotto, quando bisogna rivedere ogni sviluppo su misura uno per uno.
Ogni personalizzazione si paga tre volte: quando la costruisci, quando la mantieni e a ogni aggiornamento.
Come evitarlo: parti dalla regola di adattare il processo allo standard, e personalizza solo quando quel processo è un reale vantaggio competitivo. Se il tuo modo di calcolare le distinte base è ciò che ti distingue, personalizzalo. Se è il formato del documento di trasporto, adattati. Una prova utile: chiediti cosa succederebbe se quel processo si facesse come lo fa il resto del settore. Se la risposta è “niente di grave”, non personalizzarlo.
5. Non mettere un referente interno con potere decisionale
Il progetto ha bisogno di qualcuno di casa che decida quando due reparti non sono d’accordo su come deve funzionare un flusso. Se questa figura non esiste, ogni decisione sale alla direzione e il calendario si riempie di attese.
L’errore collegato è altrettanto frequente: nominare quella persona e non alleggerirle il carico. Un progetto ERP consuma tempo vero, e chi lo guida con la giornata già piena finisce per gestire l’urgente e rimandare l’importante.
Come evitarlo: nomina un referente con autorità sui processi e assegnagli una percentuale esplicita della sua giornata. Che sia scritto, non sottinteso.
6. Lasciare la formazione alla fine
È il taglio facile quando il budget stringe: la formazione si riduce a una sessione di due ore la settimana prima dell’avvio. Poi il team impara strada facendo, ognuno a modo suo, e si consolidano modi sbagliati di usare il sistema che poi costa molto correggere.
Come evitarlo: forma per ruolo e non per modulo — a ciascuno quello che userà davvero —, fallo con dati reali dell’azienda e programma una seconda sessione due o tre settimane dopo l’avvio, che è quando arrivano le domande vere. Metti da parte quel budget fin dall’inizio e proteggilo.
7. Scegliere l’avvio big bang senza necessità
Avviare tutti i moduli e tutte le sedi lo stesso giorno è allettante perché sembra più pulito. Significa anche che qualsiasi problema si presenta su tutti i fronti insieme e con tutta l’azienda che guarda.
Come evitarlo: in organizzazioni piccole con processi omogenei, il big bang è sostenibile. In strutture multiazienda, multipaese o con produzione, parti per fasi: prima un modulo o una sede, si stabilizza, e si replica quello che si è imparato. Allunga il calendario e riduce moltissimo il rischio.
8. Confondere il go-live con la fine del progetto
Il giorno dell’avvio il sistema funziona, ma l’organizzazione ancora no. Le prime settimane concentrano segnalazioni, dubbi e aggiustamenti, ed è proprio il momento in cui il team di implementazione tende a smobilitare.
Come evitarlo: pianifica una fase di stabilizzazione con supporto rinforzato e un canale unico dove il team possa chiedere senza attriti. Misura le segnalazioni per settimana: se non calano, qualcosa del disegno non combacia con l’operatività reale e conviene rivederlo prima che l’uso di scorciatoie diventi la norma.
9. Non integrare l’ERP con ciò che già funziona
Un ERP che non parla con il negozio online, il CRM o il registratore di cassa trasforma qualcuno del team in un ponte umano che copia dati da un sistema all’altro. Quel lavoro non compare in nessun preventivo eppure si paga tutti i mesi.
Come evitarlo: individua fin dall’inizio i punti di contatto tra i sistemi e trattali come parte del perimetro, non come un extra. Controlla che l’ERP abbia API documentate e verifica che le integrazioni che ti promettono esistano già e funzionino presso un cliente reale. Noi abbiamo fatto questo lavoro sia su prodotto standard — per esempio integrando Odoo — sia costruendo il livello su misura quando lo standard non bastava.
10. Misurare il successo dal rispetto del calendario
Consegnare nei tempi un sistema che nessuno usa non è un successo. Eppure il calendario è l’unica cosa che molti comitati misurano, perché è la più facile da guardare.
Come evitarlo: definisci due o tre indicatori di business prima di iniziare e misurali a tre e a sei mesi. Per esempio: giorni di chiusura contabile, tempo dall’ordine al documento di trasporto, percentuale di ordini con anomalia. Se l’ERP funziona, quei numeri si muovono. Se non si muovono, hai un problema anche se il progetto è stato consegnato puntuale.
Segnali d’allarme durante il progetto
Quattro sintomi che anticipano i problemi di diverse settimane:
| Segnale | Cosa indica di solito |
|---|---|
| Le riunioni di avanzamento si svuotano | L’organizzazione ha smesso di sentire il progetto come proprio |
| Compaiono fogli di calcolo paralleli nei test | Il sistema non copre un flusso reale e nessuno l’ha detto |
| Tutte le decisioni salgono alla direzione | Manca un referente con potere reale |
| La lista delle personalizzazioni cresce ogni settimana | Il perimetro non è stato chiuso davvero |
Come lo impostiamo noi
In Soamee partiamo sempre dalla mappa dei processi e dall’audit dei dati, prima di parlare di moduli. E diciamo di no quando quello che serve al cliente è un prodotto standard configurato bene invece di uno sviluppo: se la tua operatività rientra in ciò che esiste già sul mercato, il confronto tra Odoo, SAP e Sage per PMI è un punto di partenza migliore di qualsiasi nostra proposta.
Lo sviluppo su misura ha senso quando il processo che ti differenzia non sta nel prodotto standard, e il segnale è concreto: ore di personale dedicate ogni mese a sistemare a mano quello che il sistema non sa fare. Quando quel costo supera quello di costruirlo bene, la decisione è già presa.
Hai un’implementazione in corso che non decolla, o stai per iniziarne una? Raccontaci il caso e ti diamo una lettura onesta di dove si sta storcendo.