Implementazione di un ERP: le fasi (e dove si perde più tempo)

Comprare un ERP è una decisione. Farlo funzionare in azienda è un progetto, e come ogni progetto ha fasi, tempi che si stimano meglio di quanto si rispettino, e punti in cui si accumula ritardo senza che nessuno lo veda arrivare. Ecco come è fatta un’implementazione ERP nella pratica, e dove realisticamente si perde più tempo.

Le fasi di un’implementazione ERP

Ogni progetto è diverso, ma la sequenza di fondo si ripete quasi sempre.

• Analisi e mappatura dei processi. Prima di configurare qualsiasi cosa, si mappa come lavora davvero l’azienda: cicli di vendita e acquisto, gestione del magazzino, modello di fatturazione, eventuali commesse. È la fase che decide tutte le altre: un’analisi superficiale si paga tre volte più avanti, quando la configurazione non rispecchia come si lavora sul serio.
• Migrazione e pulizia dei dati. Anagrafiche, storico clienti e fornitori, giacenze, commesse aperte: tutto quello che vive nel sistema vecchio va portato in quello nuovo, e quasi mai è pronto per il trasloco così com’è.
• Configurazione. Si impostano i processi nel nuovo sistema: piano dei conti, cicli di vendita e acquisto, magazzino, e le eventuali personalizzazioni che il modello di business richiede oltre allo standard.
• Formazione. Chi userà il sistema ogni giorno deve saperlo usare prima del go-live, non impararlo mentre il lavoro reale passa già da lì.
• Go-live. Il passaggio dal sistema vecchio al nuovo. È il momento più visibile, ma è anche quello che rischia meno se le fasi precedenti sono state fatte bene: un go-live turbolento quasi sempre è la conseguenza di un’analisi o una migrazione fatte in fretta.
• Assestamento. Le prime settimane dopo il go-live, in cui emergono i casi che l’analisi non aveva previsto e si affina la configurazione sul lavoro reale.

Ogni fase produce un output che la successiva usa come base: se l’analisi lascia zone grigie, la configurazione le eredita; se la migrazione porta dati sporchi, la formazione si fa su numeri che non tornano, e chi impara il sistema impara anche a diffidarne. Per questo il tempo investito a inizio progetto, su analisi e pulizia dati, non è mai tempo tolto alle fasi successive: è tempo che le fasi successive non dovranno spendere per rincorrere problemi nati prima.

Dove si perde più tempo davvero

Chi non ha mai fatto un’implementazione immagina che il rischio stia nel go-live: il giorno in cui si stacca la spina al vecchio sistema. Nella pratica, quel giorno è quasi sempre il sintomo, non la causa. Il tempo si perde molto prima, in due punti specifici.

La migrazione e la pulizia dei dati. È la fase che quasi tutti sottostimano, perché sembra un lavoro meccanico: prendere i dati da un sistema e portarli nell’altro. Nella pratica, i dati che arrivano dal sistema vecchio sono quasi sempre incompleti, duplicati o inseriti con criteri diversi da chi li ha registrati negli anni. Un cliente con tre anagrafiche leggermente diverse, un articolo con due codici, una commessa il cui storico costi vive per metà nel gestionale e per metà in un Excel. Pulire questi dati prima di migrarli è un lavoro che richiede tempo umano, non solo tecnico, ed è quasi sempre la fase che fa slittare le date.

Le personalizzazioni non pianificate all’inizio. Il secondo punto in cui il tempo si dilata è quando una personalizzazione emerge a metà progetto, invece che nell’analisi iniziale. “Ah, ma noi fatturiamo anche a canone” oppure “le nostre commesse hanno bisogno di un livello di dettaglio in più” sono frasi che, dette durante la configurazione, costringono a tornare indietro. Ogni personalizzazione scoperta tardi non si aggiunge al progetto: lo rimette parzialmente in discussione.

Il filo che lega questi due punti è lo stesso: tutto quello che non è stato definito bene nell’analisi iniziale si ripresenta più avanti, quando costa di più risolverlo.

Come si accorcia il percorso

Non tutte le implementazioni hanno la stessa lunghezza, e la variabile che pesa di più non è la dimensione dell’azienda: è quanto è già definito e pulito quello che si porta dentro. Due leve concrete aiutano.

La prima è ovvia ma spesso saltata: pulire i dati prima di partire, non durante la migrazione. Le anagrafiche duplicate, i codici incoerenti, gli storici parziali si sistemano meglio quando c’è ancora tempo per farlo con calma, non mentre il cronoprogramma sta già scorrendo.

Vale anche per lo scope stesso: più le decisioni su cosa entra nel progetto e cosa resta fuori si prendono nell’analisi, con chi userà il sistema ogni giorno seduto al tavolo, meno probabilità ci sono che emergano a configurazione già avviata. Uno scope deciso a metà percorso costringe a rivedere il piano, non solo ad allungarlo.

La seconda riguarda la scelta tra sostituire tutto o estendere quello che c’è già. Se l’azienda lavora già su Microsoft Business Central e il problema è un pezzo specifico, per esempio la gestione delle commesse, non serve un’implementazione ERP completa da zero: serve un’estensione nativa che aggiunge quel pezzo sugli stessi dati, senza una nuova migrazione. È una scelta che abbiamo confrontato per esteso in cambiare gestionale o estendere Business Central. In questo scenario il go-live si misura in settimane, non in mesi, proprio perché manca la fase più lenta: non si migrano dati verso un sistema nuovo, si aggiunge funzionalità a quello che l’azienda già usa.

Il punto

Un’implementazione ERP non fallisce quasi mai al go-live: si allunga prima, nella migrazione di dati che arrivano più sporchi del previsto e in personalizzazioni scoperte a metà percorso invece che pianificate all’inizio. Chi arriva preparato su questi due punti taglia la parte più imprevedibile del progetto.

Se lavori già su Business Central e ti serve solo il pezzo commesse, puoi saltare la parte più lenta di un’implementazione da zero: guarda cosa aggiunge Talete o prova la demo. Se sei un system integrator che valuta il progetto per un cliente, la guida a da Navision a Business Central è un buon punto di partenza per capire tempi e passaggi reali di una migrazione.