Torna al blog
Change management in un progetto ERP
Blog

Change management in un progetto ERP

7 agosto 2026Eleonora Modaffari

Quando un progetto ERP fallisce, la prima cosa che si guarda è il software. La configurazione sbagliata, il modulo che non funziona, l'integrazione che non regge. Tuttavia nella maggior parte dei casi il problema non risiede nello strumento, ma in come viene utilizzato: utenti che non usano il sistema, processi che vengono stravolti o addirittura sabotati, dati che non vengono inseriti nel modo corretto.

È qui che entra in gioco la pianificazione strategica del change management.

Cos'è il change management in un progetto ERP?

L’“ERP change management” è l'insieme strutturato di attività per preparare le persone, i processi e l'organizzazione ad adottare il nuovo sistema prima, durante e dopo che questo vada in go-live.

Non si tratta soltanto di formazione del personale. Comprende tutta una serie di attività che misurano e prevedono l’impatto del cambiamento e delle criticità. Il change management si occupa quindi di:

  • analizzare l’impatto del cambiamento nei diversi reparti

  • utilizzare una comunicazione interna che sia esaustiva e proattiva circa agli obiettivi 

  • coinvolgere gli stakeholder fin dalle prime fasi

  • gestire la resistenza al cambiamento

  • formare in modo mirato il personale in base al ruolo e alla funzione

  • supportare il post go-live durante le prime settimane operative.

In Italia questa parte del progetto viene spesso sottostimata o integralmente delegata al partner tecnico. Questo non solo crea una certa insoddisfazione interna, ma può anche aumentare i costi operativi e di gestione.

Perché le persone resistono a un nuovo ERP?

Cambiare è sempre un salto nel vuoto e l’incertezza crea resistenza, che spesso nasce dalla paura di perdere competenze acquisite, di ricevere una valutazione su nuovi parametri, di commettere nuovi errori non preventivati.

In generale, le cause più frequenti che riguardano la resistenza sono:

  • Disinteresse e partecipazione passiva alla formazione

  • Uso parallelo del vecchio sistema, nonostante il go-live

  • Inserimento superficiale dei dati o completa delega delle operazioni richieste

  • Dipendenza dalle vecchie procedure.

Tenere a mente queste dinamiche e le loro motivazioni è un primo passo per comprenderle e trovare delle soluzioni efficaci affinché il piano di cambiamento interno abbia successo.

Vediamo allora come si struttura un piano di change management per un progetto ERP che abbia successo.

Come si struttura un piano di change management per un progetto ERP?

Un piano di change management efficace ha quattro fasi: analisi dell'impatto, coinvolgimento degli stakeholder, formazione per ruolo e supporto post go-live.

Fase 1 — Analisi dell'impatto (prima dell'implementazione)

Prima di iniziare qualsiasi configurazione, è bene prima fare una mappatura interna per avere chiaro le informazioni che rispondono alle seguenti domande:

  •  Quali reparti cambieranno i processi in modo significativo?

  •  Chi perde potere o autonomia con il nuovo sistema?

  •  Quali figure hanno la storicità e la completezza delle informazioni all'interno del team?

Questo non richiede mesi. Una serie di interviste strutturate di 30-45 minuti per reparto è sufficiente per avere un quadro realistico.

Fase 2 — Coinvolgimento degli stakeholder

A questo punto, procedi con il coinvolgimento degli stakeholder:

  • Identifica 2-3 “campioni interni" per reparto: persone motivate che usano il sistema per prime e diventano punto di riferimento per i colleghi

  • Includi i responsabili di reparto nelle sessioni di configurazione, almeno in fase di validazione dei processi

  • Comunica in anticipo cosa cambia per ciascun ruolo — non in modo generico, ovvero informando dell’arrivo di un nuovo gestionale, ma dando informazioni precise circa tempistiche e modalità.

Fase 3 — Formazione per ruolo

La formazione generica non funziona, perché il rischio è quello di informare su processi e operazioni, ruoli che niente hanno a che vedere con quelle attività. È quindi bene strutturare la formazione nel seguente modo: 

  • Per ruolo: ogni persona impara solo le funzioni che usa

  • Con dati reali: usa dati dell'azienda, non esempi fittizi del vendor

  • In piccoli gruppi: massimo 8-10 persone per sessione, se possibile

  • Con esercitazioni pratiche: non solo slideshow, ma esecuzione guidata di scenari reali

Tempistiche indicative per PMI (50-150 dipendenti): 3-5 giorni totali di formazione, distribuiti su 2-3 settimane prima del go-live.

Fase 4 — Supporto post go-live

Lo sappiamo già, ma è bene ripeterlo: la fase più critica è il post go-live. Per quanto la formazione sia stata efficace e puntuale, le prime quattro settimane sono sempre le più difficili.

Ecco quindi delle best practice da mettere in pratica:

  • Prevedi almeno un referente interno (o del partner) disponibile a dare risposte rapide

  •  Crea un canale dedicato per domande operative

  •  Monitora i KPI di adozione: quante persone usano il sistema, quanti errori di inserimento, quanti ticket aperti

I rischi sono all’ordine del giorno. Per approfondire l’argomento, ti consigliamo anche la lettura di Piano di Rollback ERP: come prepararsi prima che sia troppo tardi.

Considerazioni finali

Il change management non è una voce opzionale: incide direttamente sul ROI del progetto ERP e va pianificato prima dell'implementazione, non aggiunto all'ultimo momento.

I campioni interni sono lo strumento più efficace e meno costoso per favorire l'adozione. La formazione deve essere per ruolo, con dati reali, in piccoli gruppi.

Le prime quattro settimane post go-live sono il momento più critico: presidiarle è essenziale.

Prenota una call gratuita con un consulente Bloomup: analizziamo la tua situazione attuale e ti guidiamo passo passo in ogni fase del processo.  

Ti interessa un progetto Odoo simile?

Possiamo aiutarti con implementazione, automazioni, supporto e sviluppo su misura.