Come prepararsi a un cambio ERP: la guida per non arrivare impreparati alla selezione

Il sistema ERP non è un progetto tecnologico, ma è un'infrastruttura portante dell'organizzazione.

Il cambio ERP non è un progetto IT

Quando un’azienda decide di cambiare ERP, il primo errore che può commettere è trattarlo come un progetto tecnologico. Non lo è. È il cambio dell’infrastruttura portante dell’organizzazione: tocca i processi, le persone, i dati, i flussi di lavoro consolidati nel tempo.

Questo ha una conseguenza diretta spesso sottovalutata: tutto il lavoro preliminare – la definizione dei requisiti, la mappatura dei processi, la scelta delle risorse interne, la gestione del cambiamento – è di responsabilità dell’azienda. Nessun partner esterno, per quanto competente, può prendersi l’onere di questa fase. Un fornitore può guidarla e strutturarla, ma non può farla al posto del team interno.

Prima ancora di partire, quindi, vale la pena di porsi una domanda radicale: c’è la certezza di dover cambiare tutto? In alcuni casi, quello che sembra un problema sistemico è in realtà un problema dipartimentale, risolvibile con un’app custom o un micro-tool, senza toccare il cuore del sistema. Chiarire questo punto prima di procedere può far risparmiare mesi di lavoro e risorse significative.

Se la risposta è “Sì, il cambio ERP è necessario”, allora il percorso inizia con nove domande a cui nessun vendor può rispondere al posto dell’azienda.

A. Perimetro e obiettivi

1. Quali processi aziendali devono essere coperti dal nuovo ERP?

Non tutti i processi aziendali devono entrare nell’ERP fin dall’inizio, e non tutti devono entrarci per forza. La prima distinzione da fare è tra quello che costituisce il core del sistema – la dorsale su cui si regge l’operatività aziendale – e quello che può essere gestito come modulo aggiuntivo, strumento esterno, o rimandato a una fase successiva.

Prendiamo un esempio concreto: la gestione della qualità o il CRM possono rientrare nell’ERP, ma possono anche essere gestiti come applicazioni separate, collegate al sistema centrale. Lo schedulatore di produzione è un altro caso frequente: alcune aziende ne hanno bisogno nell’ERP, altre preferiscono mantenerlo fuori. Non esiste una risposta universale: dipende dalla struttura aziendale, dai processi critici e dagli obiettivi di medio termine.

La mappatura dei processi deve anche proiettarsi nel futuro: dove vuole essere l’azienda tra tre o cinque anni? La scelta dell’ERP è strettamente legata a quello che il sistema dovrà fare, non solo oggi ma nel tempo. Questo significa che la software selection non può prescindere da un’analisi interna approfondita, che identifichi i punti di debolezza attuali e le direzioni di sviluppo desiderate.

I criteri di selezione del fornitore derivano direttamente da questa analisi: deve aver soddisfatto tutti i requisiti mappati, deve avere la reputazione e l’esperienza per gestire progetti simili, e deve aver dimostrato – con quel prodotto specifico – la capacità di risolvere problemi analoghi a quelli che l’azienda si trova ad affrontare.

2. Perché vogliamo cambiare ERP e come misureremo il successo?

Oggi è improbabile che un’azienda strutturata non abbia già un sistema gestionale. Il cambio ERP nasce quindi sempre da un’insoddisfazione: un gap tecnologico, un prodotto diventato obsoleto, o – il caso più frequente e più insidioso – una situazione in cui è l’azienda ad essersi adattata al software, e non il contrario.

Quest’ultimo scenario è particolarmente importante da riconoscere, perché spesso non è evidente dall’interno. I processi si sono modellati sulle limitazioni del sistema nel corso degli anni, e quello che sembra “il modo in cui lavoriamo” è in realtà il risultato di compromessi accumulati nel tempo.

Definire con precisione il problema che si vuole risolvere – e stabilire in anticipo come si misurerà il successo del nuovo sistema – è il fondamento su cui si regge tutta la selezione. Senza questa chiarezza, il rischio è scegliere un ERP tecnicamente valido ma non adatto alla propria realtà.

3. Cosa resta fuori dal perimetro, almeno in questa fase?

Questa domanda è complementare alla prima, ma ha una logica propria. Definire esplicitamente cosa non entra nel progetto – almeno nella fase iniziale – non è una limitazione, ma una scelta strategica.

L’ERP è la colonna vertebrale dell’azienda: costruirla bene richiede focus, mentre aggiungere troppi dettagli e funzionalità fin dall’inizio rischia di disperdere le energie su aspetti periferici, a scapito della solidità della struttura centrale. Il principio guida è: prima si costruisce bene la dorsale, poi si integrano e si dettagliano i satelliti.

C’è un vantaggio aggiuntivo nel rimandare consapevolmente alcuni aspetti: dopo un periodo di utilizzo del sistema base, l’azienda ha maturato un’esperienza concreta che orienta meglio le scelte successive. Le personalizzazioni fatte dopo un anno di utilizzo reale sono quasi sempre più pertinenti di quelle immaginate a tavolino prima del go-live.

Un piano ben strutturato definisce la fase base e stabilisce un orizzonte temporale realistico per l’evoluzione. Questo non significa rinunciare alla visione completa, ma costruirla in modo progressivo e sostenibile.

B. Organizzazione interna

4. Quali risorse interne saranno dedicate al progetto, e per quante ore a settimana?

Un progetto ERP richiede un investimento di tempo interno che viene sistematicamente sottostimato. Le figure chiave da identificare sono quattro, con ruoli distinti e complementari.

Gli stakeholder sono i decisori: definiscono le priorità strategiche e garantiscono il supporto organizzativo al progetto. Il project manager – o i project manager, nelle realtà più complesse – ha una funzione trasversale: tiene collegato tutto il progetto, evita la formazione di silos tra le aree, garantisce che le decisioni prese in una fase siano coerenti con quelle delle fasi successive. I process owner sono i referenti di area: hanno una visione ampia dei processi di loro competenza e sono il punto di raccordo tra la strategia e l’operatività. I key user, infine, sono gli utenti più esperti: conoscono i dettagli dei processi, lavorano a stretto contatto con il sistema e contribuiscono a definire i requisiti di dettaglio.

Tutte queste figure devono dedicare al progetto un tempo di qualità, non ritagliato ai margini della giornata lavorativa, ma pianificato e protetto. Questo vale in particolare nella fase di definizione dei requisiti, che è la più critica e quella in cui gli errori costano di più.

Un aspetto spesso trascurato riguarda la metodologia e gli strumenti di lavoro: come si gestirà la documentazione? Come si terrà traccia delle decisioni prese? Quanto più questa fase è strutturata, tanto più il lavoro del partner esterno sarà efficiente.

Il passaggio dall'ecosistema software attuale
al nuovo ERP è da valutare con precisione.

C. Dati e sistemi esistenti

5. Quali sistemi attuali verranno dismessi, integrati o mantenuti in parallelo?

Ogni azienda arriva a un cambio ERP con un ecosistema software già in essere: il gestionale attuale, fogli Excel che nel tempo hanno assunto un ruolo quasi sistemico, strumenti specializzati per aree specifiche, interfacce con sistemi di clienti o fornitori.

La mappatura di questo ecosistema è un passaggio obbligatorio. Per ciascun sistema, occorre stabilire: entra nell’ERP? Rimane fuori ma deve interfacciarsi con il nuovo sistema? Viene dismesso? Viene mantenuto in parallelo per un periodo di transizione?

Le integrazioni con sistemi esterni – magazzini automatici, piattaforme e-commerce, sistemi di clienti o fornitori – hanno un impatto diretto sulla complessità del progetto e sul budget. Definirle in anticipo evita che emergano come variabili impreviste a progetto avviato.

6. I dati storici: quali portiamo nel nuovo sistema e in che stato sono?

La migrazione dei dati è uno degli aspetti più sottovalutati di un progetto ERP. La domanda non è solo “quanti dati vogliamo portare” ma “in che stato sono quei dati oggi”.

Una regola generale: più dati si vogliono migrare, più vincoli si pongono al progetto, sia in termini di tempo che di complessità tecnica. La scelta più comune è portare nel nuovo sistema i dati fondamentali per operare da subito – anagrafica clienti e fornitori, articoli, saldi contabili – e mantenere accessibile il vecchio sistema per la consultazione dello storico. Questo comporta il pagamento di una licenza del vecchio sistema per un periodo di tempo, che è un costo da preventivare.

La qualità dei dati esistenti è un fattore critico spesso scoperto tardi: dati duplicati, incompleti o in formati incompatibili richiedono un lavoro di pulizia che nessuno ha pianificato, né in termini di tempo né di risorse. Prima si affronta questa analisi, meglio è.

D. Tempi e vincoli

7. C’è una data di go-live non negoziabile?

La maggior parte dei progetti ERP si allinea alla chiusura dell’anno fiscale: si chiude l’anno sul vecchio sistema, si apre l’anno nuovo sul sistema nuovo. Ma non è l’unico tipo di vincolo temporale. Un software non più supportato dal vendor con una data di scadenza definita, un’acquisizione aziendale, una scadenza contrattuale: tutti questi fattori possono imporre un orizzonte temporale che non è negoziabile.

Mappare questi vincoli fin dall’inizio è essenziale per costruire un piano realistico. Va tenuto presente un principio noto nell’ingegneria del software: se si dispone di un orizzonte temporale ampio, si tende a occuparlo per intero. Avere una data target chiara, anche se non vincolante, aiuta a mantenere il ritmo del progetto.

8. Qual è il budget massimo, inclusi i costi che non compaiono nel preventivo?

Il budget non è il punto di partenza dell’analisi: è il punto di arrivo. Si definisce dopo aver risposto a tutte le domande precedenti, perché è la sintesi di tutto il lavoro svolto: quali processi coprire, quante risorse dedicare, quali sistemi integrare, quanti dati migrare, in quanto tempo.

Un preventivo ERP che non parte da questa analisi è inevitabilmente incompleto. Le voci che mancano quasi sempre nei preventivi affrettati sono le personalizzazioni, la pulizia dei dati, la formazione reale degli utenti, il supporto post go-live e i costi delle integrazioni. Conoscere questi elementi in anticipo consente di gestirli consapevolmente.

E. Persone e cambiamento

9. Come coinvolgerai i responsabili di funzione che useranno il sistema ogni giorno?

Il cambiamento genera disordine. È una costante che chi ha seguito progetti di trasformazione aziendale conosce bene. In ogni organizzazione, di fronte a un cambiamento significativo, si trovano sempre tre tipologie di persone: chi abbraccia il cambiamento con entusiasmo, chi vi si oppone attivamente, e chi – la componente più numerosa – resta in attesa, né favorevole né contrario.

La strategia più efficace non è quella di concentrarsi su chi si oppone, ma su chi è in attesa. I neutrali sono pragmatici: si convincono con i fatti, non con le argomentazioni. Una volta visto un beneficio concreto, tendono a spostarsi dalla parte degli entusiasti, creando la massa critica necessaria perché il cambiamento si consolidi.

Project manager, process owner e key user hanno ciascuno la responsabilità di gestire il livello organizzativo sottostante: motivare, comunicare con chiarezza, raccogliere e valutare le richieste che arrivano dal basso. Questa dimensione del progetto – il change management – deve essere pianificata prima del go-live, con strumenti e approcci definiti, non improvvisata quando i problemi si manifestano.

Conclusione

Queste nove domande non hanno risposte universali. Dipendono dalla dimensione dell’azienda, dal settore, dalla complessità dei processi, dalla maturità organizzativa. Ma sono le domande giuste da porsi, nell’ordine giusto, prima di aprire qualsiasi conversazione con un vendor.

Il lavoro che producono – la mappatura dei processi, la definizione delle risorse, l’analisi dei dati, la chiarezza sui vincoli – è il contributo più prezioso che un’azienda può portare a un progetto ERP. È anche il contributo che nessun partner esterno può sostituire.

Scarica la checklist completa in formato PDF o contatta Nealis per un confronto sulla tua situazione specifica.