Team di implementazione ERP nel 2026: chi serve e cosa fa

Un team di implementazione ERP ha bisogno di uno sponsor con autorità, di un project manager che conosca l'ERP, di process owner di business per ogni funzione coinvolta, di consulenti funzionali e tecnici e di responsabili dedicati a integrazione, migrazione dei dati, test, change management e cutover. I programmi SAP in cloud aggiungono un architetto Clean Core e un referente SAP indicato per nome. Dimensioni il team in base alla complessità, non al numero di dipendenti dell'azienda, e affianchi a ogni consulente una persona interna che sarà responsabile di quell'area dopo il go-live.

Questo articolo è rivolto a sponsor, CIO e programme director che devono mettere in piedi il team di un programma ERP. Tratta i ruoli, ciò che fa riuscire o fallire ciascuno di essi, le dimensioni del team, che cosa cambiano il cloud ERP e l'AI e come ripartire il lavoro con un partner di implementazione.

Un'azienda con cui ho lavorato aveva due implementazioni ERP in corso nello stesso periodo: una su SAP, una su Oracle. Sul progetto Oracle lavoravano 4.500 persone. Su quello SAP, 38. Uno è andato in produzione senza intoppi. L'altro è stato un disastro senza fine. La differenza l'ha fatta il team.

Dopo 25 anni di implementazioni SAP, lo schema si conferma. Se il team è sbagliato, o se le persone giuste sono inserite nella struttura sbagliata, il progetto si trascina, i costi salgono e al go-live gli utenti hanno già deciso di detestare il sistema.

1. Sponsor del progettoRimuove gli ostacoli, assicura il budget, decide tra i reparti
   Referente SAP per i serviziNei programmi RISE, escalation sulla piattaforma e revisioni del servizio
2. Project managerTempi, perimetro, rischi e coordinamento con il partner

• Process owner di businessConvalidano il disegno e testano i flussi di lavoro reali
• Consulenti funzionali e tecniciConfigurano, estendono e si oppongono
• Responsabile della migrazione dei datiBonifica, caricamenti e dati di cutover
• Responsabile dell'integrazioneDisegno del middleware e flussi di dati
• Responsabile di change management e formazioneComunicazione, champion, adozione
• Architetto Clean CoreDove risiede ogni estensione, sulle edizioni cloud

Ruolo	Cosa fanno davvero	Quando intervengono
Sponsor del progetto	Rimuove gli ostacoli, assicura il budget, prende le decisioni tra i reparti	Tutte le fasi
Project manager	Gestisce tempi, perimetro, rischi e coordinamento con il partner	Tutte le fasi
Process owner di business	Convalidano il disegno, testano gli scenari, rappresentano i flussi di lavoro reali	Da Explore a Deploy
Consulenti funzionali	Raccolgono i requisiti, configurano i moduli, supportano i test	Da Explore a Deploy
Consulenti tecnici	Estensioni, interfacce, configurazione del sistema	Da Realize a Deploy
Responsabile dell'integrazione	Disegno del middleware e flussi di dati tra i sistemi	Da Explore a Deploy
Responsabile della migrazione dei dati	Strategia dei dati, bonifica, caricamenti, dati di cutover	Da Prepare a Deploy
Responsabile di change management e formazione	Formazione, comunicazione, misure di adozione	Da Explore a Run
Responsabile dei test	Script di test, SIT, UAT, tracciamento dei difetti	Da Realize a Deploy
Cutover manager	Passaggio in produzione, downtime, piano di rollback	Deploy
Architetto Clean Core (edizioni cloud)	Decide dove risiede ogni estensione e a quale livello Clean Core	Da Explore a Run
Referente SAP per i servizi (RISE)	Escalation sulla piattaforma, revisioni del servizio, allineamento alla roadmap SAP	Da Prepare a Run

Il mio articolo sui ruoli del team di implementazione SAP entra più nel dettaglio, ruolo per ruolo.

Sponsor del progetto

Il compito dello sponsor non è firmare il charter e sparire. I progetti si bloccano per mesi quando sopra il project manager nessuno ha l'autorità di decidere nei casi in cui i reparti non sono d'accordo. Lo sponsor deve essere raggiungibile, disposto a prendere decisioni difficili e presente fino alla stabilizzazione, non solo al kickoff.

Che cosa va storto: gli sponsor che delegano tutto all'IT. L'ERP cambia il modo in cui l'azienda lavora. Se la leadership non lo guida, fallisce. La guida allo steering committee spiega come strutturare la sede in cui lo sponsor decide.

Project manager

Un project manager ERP deve sapere come funzionano davvero i programmi SAP o Oracle, non solo la gestione generica dei progetti IT. I rischi, le dipendenze e la pressione al cutover sono diversi.

Che cosa va storto: un project manager che sul perimetro si rimette ai consulenti, o che non riesce a far rispettare al business le scadenze dei test.

Process owner di business

L'IT non gestisce la sua azienda. Lo fanno operations, finanza, acquisti e risorse umane. I process owner garantiscono che il sistema funzioni sui processi reali, non solo sulla carta. Se li lascia fuori, ottiene una configurazione che aveva senso in un workshop e che fallisce alla prima settimana.

Li coinvolga fin dall'inizio, non all'UAT per approvare decisioni a cui non hanno partecipato.

Consulenti ERP

I buoni consulenti si oppongono. Se i suoi sono d'accordo su tutto e non mettono mai in discussione un requisito, fatturano ore, non aggiungono competenza. I migliori fermano gli errori prima che costino mesi.

Un segnale di un consulente debole: personalizza troppo perché è più facile che spiegare perché l'azienda dovrebbe cambiare un processo. Ogni programma custom va mantenuto, testato a ogni upgrade e spiegato al team successivo. Con i livelli Clean Core di SAP quel debito ora è visibile: un'estensione costruita alla vecchia maniera finisce al livello C o D ed emerge al primo upgrade importante.

Responsabile della migrazione dei dati

I dati sbagliati nel vecchio sistema diventano dati sbagliati nel nuovo. Se prima della migrazione nessuno si fa carico della discussione sulla qualità dei dati, i report finanziari non corrisponderanno alla realtà fin dal primo giorno.

La migrazione dei dati è un processo di business e ha bisogno di un responsabile di business. L'IT può spostare i dati. Spetta al business confermare che siano corretti.

Responsabile di change management e formazione

Il change management non è formazione. È comunicazione, coinvolgimento precoce e individuazione dei champion all'interno dell'azienda prima del go-live. Quando l'azienda dà per scontato che basti la formazione, gli utenti che non si fidano del nuovo sistema tornano ai loro fogli di calcolo, e rimediare dopo il go-live costa caro.

Questo responsabile deve costruire contenuti, avviare pilot e misurare la prontezza, non distribuire un PDF due settimane prima del go-live. Nei programmi SAP gestisce ormai anche gli strumenti di digital adoption: SAP sta integrando SAP Enable Now in WalkMe, acquisita nel 2024, quindi i nuovi contenuti vanno pianificati in WalkMe.

Architetto Clean Core (edizioni cloud)

SAP classifica ormai ogni estensione secondo quattro livelli Clean Core, da A a D. Qualcuno deve decidere, per ogni gap, se si risolve con la configurazione standard, con un'estensione di livello A su SAP BTP o in-system con ABAP Cloud, oppure non si risolve affatto. Nei programmi grandi è un ruolo dedicato. In quelli del mid-market se ne fa carico di solito il solution architect.

I partner senza esperienza su SAP BTP e ABAP Cloud non possono ricoprire questo ruolo. Chieda quante estensioni hanno realizzato con queste regole e chieda di vederle.

Referente SAP per i servizi (programmi RISE)

Con RISE with SAP è SAP a gestire l'infrastruttura e le operations del sistema, quindi SAP fa parte della delivery. Il CIO ha bisogno di un referente SAP indicato per nome, per le escalation sulla piattaforma, le revisioni del servizio e l'allineamento alla roadmap. Metta questa persona nell'elenco del team fin dalla fase Prepare, non solo nell'elenco degli inviti allo steering committee.

Le dimensioni del team devono corrispondere alla complessità, non al numero di dipendenti.

Tipo di azienda	Dimensione tipica del team	Che cosa determina la complessità
Piccola (una sola società, meno di 500 dipendenti)	10-25	Funzionalità per lo più standard, poche integrazioni
Mid-market (più sedi, da 500 a 5.000 dipendenti)	30-75	Più integrazioni, varianti regionali dei processi, change su larga scala
Enterprise (globale, oltre 5.000 dipendenti)	100-500+	Più società e integrazioni, compliance su più giurisdizioni

Uno stabilimento da 50 persone con produzione complessa make-to-order può richiedere un team più grande e più specializzato di un'azienda da 500 persone che gestisce processi retail standard. Si dimensioni in base a ciò che va fatto. La mia guida alla pianificazione dell'allocazione delle risorse nei progetti SAP mostra come costruire il piano.

Joule è ormai presente negli strumenti di implementazione di SAP (SAP Cloud ALM e SAP Activate Roadmap Viewer). SAP Build Code usa Joule per aiutare gli sviluppatori a costruire estensioni su SAP BTP. Microsoft Copilot redige report di avanzamento, note per lo steering committee e comunicazioni di change.

Usati con costanza, questi strumenti accelerano i ruoli ricchi di flussi di lavoro. Rendono un programma un po' più snello di quanto lo stesso perimetro avrebbe richiesto qualche anno fa, ma non drasticamente più piccolo.

Inserisca gli strumenti nelle definizioni dei ruoli. I consulenti funzionali usano l'AI per le prime bozze di requisiti e documenti di fit-gap. I project manager la usano per i report di avanzamento. Gli sviluppatori la usano dove aiuta. Ciò che l'AI non cambia è la responsabilità: scrive le bozze più in fretta, ma sono le persone a rispondere di ciò che la bozza afferma.

La maggior parte delle aziende combina un team interno di base, che conosce il business, con un partner che porta profondità tecnica e metodologica.

Il team interno deve essere coinvolto davvero, non limitarsi a partecipare alle riunioni di avanzamento. Altrimenti il progetto consegna un sistema che il partner capisce e che nessuno in azienda sa far funzionare.

Che cosa aspettarsi da un partner: struttura, decisioni più rapide ed esperienza degli errori tipici di un'azienda come la sua. Che cosa non delegare: le decisioni sul perimetro, l'approvazione del disegno dei processi e la prontezza degli utenti. Servono responsabili interni.

Il modello che funziona con costanza è lo shadow pairing. Ogni consulente ha un omologo interno che sarà responsabile di quell'area dopo il go-live. Il consulente realizza, la persona interna impara e la conoscenza resta quando i consulenti se ne vanno.

Nella selezione di un partner, chieda referenze di aziende della sua dimensione e del suo settore, non dei clienti vetrina del fornitore. Chieda dell'esperienza Clean Core con esempi concreti e di come lavorano con SAP nei programmi RISE. Le risposte vaghe dicono chi è aggiornato e chi vende la versione di SAP che conosceva tre anni fa.

Quante persone fanno parte di un team di implementazione ERP?

Dipende più dalla complessità che dalle dimensioni dell'azienda. Le piccole imprese con processi lineari di solito ne richiedono da 10 a 25, le aziende mid-market con più sedi da 30 a 75, le grandi realtà globali da 100 a 500 o più. Un'azienda manifatturiera con processi complessi engineer-to-order ha bisogno di più capacità di un'azienda più grande che gestisce funzioni retail standard.

Quali nuovi ruoli servono nei programmi SAP in cloud?

Due. Un architetto Clean Core o responsabile delle estensioni, che decide dove risiede ogni estensione e a quale livello Clean Core; nei programmi più piccoli se ne fa carico il solution architect. E, con RISE with SAP, un referente SAP indicato per nome per le escalation e le revisioni del servizio, perché è SAP a gestire l'infrastruttura e le operations del sistema.

Qual è il ruolo dello sponsor in un'implementazione ERP?

Lo sponsor assicura il budget, rimuove gli ostacoli e decide quando i reparti non sono d'accordo. Il suo compito è rendere il progetto governabile, non governarlo. La cosa più importante che fa è restare coinvolto fino alla stabilizzazione. I progetti che perdono l'attenzione dei vertici dopo il cutover sviluppano workaround che durano anni.

Perché le implementazioni ERP hanno bisogno dei process owner di business?

Perché le persone di finanza, operations, risorse umane e acquisti sanno come il lavoro viene fatto davvero. Senza di loro il team progetta un sistema che sulla carta ha senso e nella pratica fallisce. Li coinvolga nei workshop e nelle decisioni di disegno fin dall'inizio: all'UAT è troppo costoso cambiare ciò che è sbagliato.

Che cosa devo cercare in un consulente ERP?

La disponibilità a dire di no. Un consulente che è d'accordo su tutto si rende la vita più facile, non la sua. I buoni consulenti contestano i requisiti sbagliati, segnalano lo scope creep e spiegano perché lo standard di solito conviene più del custom. Poi verifichi l'esperienza Clean Core con esempi, le referenze di aziende simili che può chiamare e se stanno risolvendo il suo problema o vendendo l'incarico che sanno già eseguire.

Come si gestisce la migrazione dei dati in un'implementazione ERP?

Assegni alla migrazione un responsabile dedicato, che si fa carico di strategia, regole di bonifica, caricamenti e validazione al go-live. La qualità dei dati è del business: l'IT può spostare un record fornitore, ma solo il business sa se è corretto.

Che cos'è il change management in un progetto ERP e perché conta?

Preparare le persone a un cambiamento importante nel modo di lavorare, prima, durante e dopo il go-live. Comprende la comunicazione (che cosa cambia e perché, presto), il coinvolgimento (key user nel disegno e nei test) e il supporto (champion che aiutano i colleghi ad adattarsi). I progetti che lo trattano come un calendario di formazione ottengono sempre lo stesso risultato: workaround, fogli di calcolo e un sistema di cui nessuno si fida.