Ruoli e responsabilità essenziali nel team di implementazione SAP

Un'implementazione SAP richiede otto ruoli con responsabili nominati e dedicati: sponsor esecutivo, project manager, responsabili funzionali, IT lead, responsabile della migrazione dei dati, responsabile del change management, partner di implementazione e un advisor di programma indipendente. RISE with SAP aggiunge i referenti di delivery di SAP e rende esplicita la responsabilità sul clean core. Questa guida è per sponsor e direttori di programma che stanno costruendo un team o riparandone uno. Spiega di che cosa risponde ciascun ruolo, che cosa si rompe se manca, le dimensioni del team per taglia aziendale e come costruire il Centro di eccellenza (CoE) prima del go-live. Cominci verificando quale degli otto ruoli è ricoperto da una persona che ha anche il proprio lavoro quotidiano. È il suo rischio maggiore.

Negli anni ho lavorato con decine di team SAP. Ho visto progetti ben finanziati e con fornitori esperti fallire perché ruoli chiave mancavano o erano divisi tra persone con altri incarichi. Ho visto anche progetti sottofinanziati riuscire perché le persone giuste erano nella stanza, pienamente impegnate, con responsabilità chiare.

Un retailer globale con cui ho lavorato aveva budget, sostegno della leadership e SAP come ERP scelto. Ma il suo team di implementazione era un disastro. Mancavano ruoli chiave. Nessuno era responsabile delle decisioni critiche. La comunicazione correva in tutte le direzioni senza arrivare da nessuna parte. Le scadenze slittavano, i costi salivano e la fiducia è crollata.

Ogni implementazione SAP richiede che questi ruoli siano coperti. Il titolo conta meno della responsabilità.

1. Sponsor esecutivoDecisioni, finanziamento, escalation
   Advisor di programma ERPSupervisione indipendente, rischio, allineamento dei vertici
2. Project managerTempi, budget, coordinamento

• Responsabili funzionali ed esperti di materiaDisegno dei processi, configurazione dei moduli
• IT lead e teamIntegrazione, sviluppo, sicurezza
• Responsabile migrazione datiQualità dei dati, sequenza dei caricamenti, cutover
• Responsabile change managementFormazione, adozione, comunicazione
• Partner di implementazioneArchitettura, disegno delle integrazioni, delivery

Ruolo	Responsabilità principale	Che cosa si rompe senza di esso
Sponsor esecutivo	Decisioni strategiche, finanziamento, autorità di escalation	Deriva, scontri sul perimetro, nessuno che sciolga i nodi
Project manager	Tempi, budget, coordinamento tra i team	Ritardi, blocchi irrisolti, sforamenti di costo
Responsabili funzionali ed esperti di materia	Disegno dei processi di business, configurazione dei moduli	Configurazione sbagliata, workaround dopo il go-live
IT lead e team	Integrazione, sviluppo, sicurezza, prestazioni	Debito tecnico, interfacce che si rompono, instabilità
Responsabile migrazione dati	Qualità dei dati, sequenza dei caricamenti, accuratezza del cutover	Dati inutilizzabili, go-live fallito, mesi di pulizia
Responsabile change management	Formazione, adozione, comunicazione	Resistenza degli utenti, fogli di calcolo paralleli
Partner di implementazione	Architettura, disegno delle integrazioni, delivery	Sovracostruzione, fallimenti di integrazione
Advisor di programma ERP	Supervisione indipendente, rischio, allineamento dei vertici	Decisioni prese in isolamento, errori evitabili

Sponsor esecutivo

Lo sponsor non è un nome su una slide del comitato direttivo. Prende le decisioni che nessun altro può prendere: budget, modifiche di perimetro, impegni di risorse tra i reparti. Quando il ruolo è cerimoniale, i progetti vanno alla deriva.

Ho lavorato con un'azienda che ha saltato questo ruolo. Il progetto è andato alla deriva. Nessuna decisione, nessun progresso, soldi buttati.

Gli sponsor efficaci restano fino all'hypercare. Partecipano alle sessioni mensili del comitato direttivo dopo il go-live e prendono le piccole decisioni che sbloccano questioni ferme da settimane. La mia guida su come costituire un comitato direttivo SAP spiega come strutturare quel forum.

Project manager

Il PM gestisce il quotidiano: tempi, registro dei rischi, coordinamento, aggiornamenti. In un grande programma SAP è un ruolo a tempo pieno per qualcuno che l'ha già fatto.

Ho visto un cliente perdere il suo lead developer a metà implementazione. L'intero progetto si è fermato per settimane mentre cercava un sostituto.

Il problema opposto è altrettanto dannoso. Ho lavorato con un'azienda che aveva più di 30 persone nel team. Nessuno sapeva chi fosse responsabile delle decisioni. Per le modifiche semplici servivano cinque riunioni. I tempi sono passati da 12 a 18 mesi solo per il sovraccarico di comunicazione.

Responsabili funzionali ed esperti di materia

Queste persone traducono le operazioni di business in configurazione SAP. Devono conoscere il business abbastanza da mettere in discussione i processi sbagliati, e SAP abbastanza da sapere che cosa è possibile.

Ho lavorato con un cliente manifatturiero il cui team ha eccelso perché i responsabili funzionali passavano del tempo in fabbrica prima di disegnare i processi.

Gli esperti di materia che si impegnano a metà lasciano sempre dei vuoti. O il progetto ha la loro attenzione, o ha il loro nome su un foglio di approvazione. Non sono la stessa cosa.

IT lead e team

Il team IT possiede le fondamenta tecniche: sviluppo, Basis, sicurezza, integrazione e prestazioni. Su S/4HANA possiede anche la disciplina del clean core, tenendo il codice custom fuori dal core.

L'integrazione è ciò che la maggior parte dei team sottovaluta. Ogni collegamento con un sistema esterno deve essere progettato, costruito, testato e avere un responsabile. Le interfacce si rompono in UAT quando nessuno ha mappato i flussi di dati. Porti l'IT nelle sessioni di blueprinting, non dopo che le decisioni sono state prese.

Responsabile migrazione dati

Questo ruolo viene assegnato tardi e con risorse insufficienti. Quando i problemi sui dati emergono, il programma è già sotto pressione sui tempi.

Un cliente pensava di poter saltare la pulizia dei dati. Grosso errore. Il suo sistema è stato inutile per mesi. Pulire i dati su un sistema in produzione costa più di una pulizia fatta bene all'inizio.

Un responsabile di migrazione dedicato esegue le riconciliazioni su ogni caricamento, ed è così che i problemi strutturali emergono prima del go-live. Non succede quando il ruolo è affidato a qualcuno con altri tre filoni di lavoro. Il mio articolo sul perché la migrazione dei dati SAP fallisce spiega il metodo.

Responsabile change management

È il ruolo più costantemente sottodimensionato. Ho visto sistemi da milioni di dollari restare inutilizzati perché nessuno voleva cambiare il proprio modo di lavorare.

Ho visto fallire un'implementazione tecnicamente perfetta perché gli utenti la odiavano. La configurazione era corretta e il disegno dei processi solido. Ma le persone che la usavano ogni giorno non erano state coinvolte nel disegno. Non capivano perché le cose fossero cambiate e continuavano a usare i loro vecchi file Excel.

Un cliente retail ha avuto successo perché ha ascoltato le preoccupazioni dei suoi cassieri sul nuovo sistema e ha adattato il suo approccio.

Il minimo per un programma enterprise sono due persone dedicate al change management. Una sola persona non riesce a coprire insieme disegno della formazione, comunicazione, gestione delle resistenze e monitoraggio dell'adozione.

Advisor di programma ERP

Un advisor indipendente non è il partner di implementazione. Il compito è la supervisione e la correzione di rotta: verificare che la direzione abbia ancora senso, individuare i rischi che il team di delivery è troppo vicino per vedere e colmare il divario tra ciò che i dirigenti pensano stia accadendo e ciò che accade davvero.

Ho svolto questo ruolo per clienti con team di delivery solidi ma senza una voce indipendente. Ho lavorato con un cliente manifatturiero che stava per implementare i moduli sbagliati perché nessuno aveva collegato la sua strategia di crescita alla sua roadmap SAP.

Individuare i problemi in anticipo è l'altra metà del lavoro. Una volta ho identificato una lacuna critica di competenze nel team dati di un cliente tre mesi prima che ritardasse il go-live. L'abbiamo risolta prima che diventasse una crisi.

Il modello a otto ruoli resta valido. Nel 2026 tre elementi vanno integrati.

I referenti di delivery di SAP su RISE

Su RISE with SAP private cloud, SAP gestisce l'infrastruttura e le operazioni tecniche. Il suo documento su ruoli e responsabilità prevede che i clienti concordino i servizi con un SAP Cloud Architect Advisor, un Client Delivery Manager o il team del customer centre del private cloud di SAP. Inserisca nel team chi viene assegnato da SAP, accanto al team del partner, e nomini la persona, dal suo lato, che ha la responsabilità di quel rapporto. On-premise, SAP è un fornitore di software e questo non vale.

Clean core e responsabilità delle estensioni

Su S/4HANA Cloud Public Edition il clean core è imposto dal design: le estensioni passano da API rilasciate, strumenti per key user o SAP BTP. Su private cloud e on-premise le modifiche sono ancora possibili, ma ognuna rende più difficili gli upgrade. Qualcuno deve presidiare quel confine.

Nei programmi più grandi c'è un architetto del clean core o un responsabile delle estensioni BTP dedicato, che risponde al solution architect. Nei programmi del mid-market il solution architect di solito se ne fa carico, ma la responsabilità va messa per iscritto. Quando valuta i partner, chieda quante estensioni BTP hanno realizzato e si faccia mostrare degli esempi.

L'AI cambia la produttività, non la responsabilità

SAP Joule for Consultants (disponibile in generale dal 2025) risponde alle domande di configurazione attingendo alla knowledge base di SAP e spiega il codice ABAP. SAP Build Code genera codice di estensione Java e JavaScript su SAP BTP. Microsoft Copilot redige i brief per il comitato direttivo e i report di stato.

I vantaggi si vedono nei ruoli ricchi di flussi di lavoro, come l'analisi dei requisiti, i report di stato e lo sviluppo custom, e solo quando le persone usano gli strumenti con costanza. Consideri qualsiasi cifra di produttività le venga citata come un'affermazione da verificare sul suo programma.

Il team è un po' più piccolo di quanto lo stesso perimetro richiedesse prima di questi strumenti, ma non in modo drastico. Scriva gli strumenti nelle definizioni dei ruoli invece di trattarli come un'attività a margine. L'AI scrive le bozze più in fretta. Le persone restano responsabili di ciò che la bozza dice.

La tabella mostra il dimensionamento tipico di ciascun ruolo per scala aziendale. La consideri un punto di partenza e la adatti a perimetro e geografia. Per la stessa questione fuori da SAP, veda la mia guida al team di implementazione ERP.

Ruolo	Piccola impresa	Mid-market	Grande impresa
Sponsor esecutivo	Direttore senior	CIO o CFO	C-suite con comitato direttivo
Project manager	1 a tempo pieno	1-2 a tempo pieno	Programme manager più PM dei filoni di lavoro
Responsabili funzionali	1-2 per modulo	Dedicati per modulo	Diversi per modulo
Team IT	2-3 (condivisi)	4-6 (dedicati)	8+ specialisti
Migrazione dati	1 responsabile	1 responsabile più analisti	Filone di lavoro dedicato
Change management	1 minimo	2 minimo	3-5 dedicati
Responsabile clean core o estensioni BTP	Solution architect	Solution architect	Ruolo dedicato
Referenti SAP (RISE)	Un referente nominato	Un referente nominato	Referenti nominati con revisioni trimestrali
Partner di implementazione	5-10 consulenti	15-25 consulenti	30+ con un direttore di programma

Le competenze tecniche fanno costruire il sistema. L'intelligenza emotiva decide se le persone lo usano.

Ho lavorato con un'azienda manifatturiera in cui il responsabile di magazzino sorrideva nelle riunioni ma sabotava il progetto dietro le quinte. Un change manager attento ha colto i segnali presto e ne ha fatto un sostenitore. Scoprirlo al go-live sarebbe stato molto più difficile da risolvere.

Il project manager di un cliente era tecnicamente brillante ma non sapeva adattare il suo messaggio. Un CFO ha bisogno di una comunicazione diversa dal personale di magazzino. Il risultato è stato uno scarso consenso in tutta l'organizzazione e un go-live doloroso.

La risposta alla domanda «dipendenti o consulenti?» è quasi sempre: entrambi.

I dipendenti conoscono il business: i processi, la politica interna e i workaround che nessuno documenta. Ho lavorato con un'azienda manifatturiera i cui dipendenti hanno individuato problemi di implementazione che i consulenti esterni avevano mancato del tutto. Quelle intuizioni l'hanno salvata da una configurazione disastrosa del magazzino.

I dipendenti spesso non hanno esperienza di implementazione. Un cliente retail ha insistito per un team tutto interno. Dopo sei mesi erano irrimediabilmente indietro perché stavano imparando SAP mentre lo implementavano.

I consulenti portano la capacità di riconoscere gli schemi. Ho coinvolto un consulente per un cliente che ha subito individuato un approccio alla migrazione dei dati che avrebbe mandato in crisi il suo go-live.

Il rischio con i consulenti è il trasferimento di conoscenza. Se nessuno all'interno impara il sistema, le parcelle di consulenza continuano ben dopo il lancio.

Il modello che funziona: le coppie in shadowing. Un cliente farmaceutico ha affiancato a ogni consulente una controparte interna che sarà responsabile di quell'area dopo il go-live. Il consulente realizza, la controparte impara e la conoscenza resta. Attorno a questo modello, sei pratiche fanno la differenza:

1. Costruire il team prima di scegliere il software. Un cliente ha comprato moduli che il suo team non era in grado di mantenere, e ne sono seguiti sei mesi di caos.
2. Dedicare le persone a tempo pieno. A tempo parziale significa che, quando arriva la pressione, vince il lavoro quotidiano. Ho visto configurazioni critiche aspettare settimane perché qualcuno era troppo occupato.
3. Far lavorare il team nello stesso luogo, dove possibile. Un cliente manifatturiero ha risparmiato settimane di andirivieni mettendo il suo team nella stessa stanza tre giorni a settimana.
4. Definire presto i percorsi di escalation. Un cliente retail aveva un documento di una pagina che mostrava esattamente come le decisioni salivano lungo la catena. Ha evitato innumerevoli ritardi.
5. Mettere per iscritto le decisioni con la loro motivazione. Ho lavorato con un'azienda che registrava che cosa decideva e perché. Questo ha evitato interminabili ripetizioni quando nuovi dirigenti sono entrati a progetto in corso.
6. Segnare le tappe lungo il percorso. Un cliente manifatturiero teneva eventi mensili di riconoscimento. Una piccola cosa, ma ha mantenuto alto il morale durante un'implementazione estenuante di 18 mesi.

L'errore che le aziende fanno dopo il go-live è sciogliere il team di implementazione. Proprio allora il CoE deve farsi carico di evoluzioni, upgrade, governance, formazione dei nuovi utenti e allineamento della configurazione al modo in cui il business funziona davvero.

Lo pianifichi durante l'implementazione. Avevo un cliente manifatturiero che ha ignorato questo consiglio. Tre mesi dopo il go-live i suoi principali esperti di configurazione se ne sono andati. Nessuno sapeva come mantenere ciò che era stato costruito, e il sistema ha cominciato subito a degradarsi.

Questi sono i ruoli del CoE da pianificare fin dai primi mesi dell'implementazione.

Ruolo nel CoE	Responsabilità principale
Direttore del CoE	Strategia SAP, allineamento con gli obiettivi di business, operatività del CoE
Solution architect	Architettura, disegno delle integrazioni, governance del clean core
Responsabile clean core o estensioni BTP	Catalogo delle estensioni, analisi dell'impatto degli upgrade
Consulenti funzionali	Ottimizzazione dei moduli, miglioramento dei processi
Consulenti tecnici	Sviluppo, Basis, prestazioni, sicurezza
Responsabile change e formazione	Adozione, formazione, crescita delle competenze
Responsabile data governance	Qualità e standard dei dati anagrafici
Responsabile integrazione	Middleware, API, flussi di dati tra sistemi
Responsabile supporto	Risoluzione dei problemi, miglioramento continuo
Responsabile della relazione con SAP (RISE)	Escalation verso SAP, revisioni dei servizi, allineamento della roadmap

Un'azienda farmaceutica ha assegnato dei responsabili di modulo che dovevano approvare qualsiasi modifica che potesse toccare la loro area. Quella governance ha evitato le modifiche scoordinate che di solito rendono i sistemi difficili da usare dopo due o tre anni.

Un cliente ha investito il 10% del budget del suo CoE nella formazione continua. Tre anni dopo implementava nuove funzionalità che i suoi concorrenti non riuscivano a toccare. Ecco com'è fatto un CoE che funziona.

Perché i team di implementazione SAP falliscono anche quando il piano sembra solido?

Di solito perché il piano copre la tecnologia e ignora le persone. Gli schemi più comuni sono ruoli chiave ricoperti da persone con altri incarichi, esperti di materia richiamati alle attività operative a progetto in corso e change management trattato come una funzione di formazione. Quando nessuno è responsabile di una decisione e non esiste un percorso di escalation, i blocchi restano fermi per settimane e il progetto fallisce per mancanza di coordinamento, non per la tecnologia.

Quali ruoli sono irrinunciabili in qualsiasi implementazione SAP?

Sei ruoli richiedono persone dedicate e responsabili: sponsor esecutivo, project manager, almeno un responsabile funzionale per ogni modulo principale, un IT lead, un responsabile della migrazione dei dati e un responsabile del change management. Se ne manca uno, il vuoto emerge nelle ultime settimane prima del go-live. Il change management è il più sottodimensionato. Su RISE, aggiunga un responsabile chiaro per le estensioni e per il rapporto con i referenti di delivery di SAP.

Che cosa cambia nella struttura del team con RISE with SAP?

SAP gestisce l'infrastruttura e le operazioni tecniche, quindi si lavora con referenti assegnati da SAP, come un Client Delivery Manager o un Cloud Architect Advisor. Li inserisca nel team e nomini un responsabile della relazione dal suo lato. Anche la responsabilità sul clean core deve essere esplicita: un architetto dedicato nei programmi grandi, oppure il solution architect in quelli del mid-market.

Un team di progetto SAP dovrebbe usare dipendenti o consulenti?

Entrambi. I dipendenti portano un contesto di business che i consulenti non riescono a replicare in fretta. I consulenti portano la capacità di riconoscere gli schemi di implementazione, che i dipendenti di solito non hanno. Affianchi a ogni consulente una controparte interna che sarà responsabile di quell'area dopo il go-live, così la conoscenza resta quando i consulenti se ne vanno. Le aziende che saltano questo passaggio spesso pagano per anni un supporto che avrebbero dovuto gestire internamente.

Quando conviene iniziare a costruire il CoE SAP?

Durante l'implementazione, idealmente fin dai primi mesi. I migliori membri del CoE sono di solito i contributori più forti dell'implementazione, e se si aspetta il go-live se ne vanno prima di essere stati individuati. Un cliente manifatturiero che ha aspettato ha perso i suoi principali esperti di configurazione tre mesi dopo il go-live, e nessuno sapeva come mantenere ciò che era stato costruito.

Come cambia l'AI la struttura dei team SAP nel 2026?

Strumenti come SAP Joule for Consultants, SAP Build Code e Microsoft Copilot aumentano la produttività nei ruoli ricchi di flussi di lavoro, se le persone li usano con costanza. Il team è un po' più piccolo di quanto lo stesso perimetro richiedesse prima di questi strumenti, ma non in modo drastico. Inserisca gli strumenti nelle definizioni dei ruoli e lasci la responsabilità alle persone: l'AI scrive le bozze più in fretta, le persone restano responsabili di ciò che la bozza dice.