Perché i progetti SAP sforano il budget e come evitarlo

I progetti SAP sforano il budget soprattutto perché le aziende cercano di tenere basso il costo all'inizio e poi vengono colpite nella fase Explore, quando i workshop di fit-to-standard mostrano il perimetro reale. Nei programmi che ho analizzato, sforamenti del 40-60 percento sono frequenti.

In breve: un budget SAP sfora quando è stato fissato prima che qualcuno conoscesse il perimetro, e quando a controllare quel perimetro è il fornitore anziché il cliente. Tenga d'occhio il numero di oggetti WRICEF durante la fase Explore, si assuma Lei la responsabilità del perimetro e mantenga una riserva del 10-20 percento dalla Sua parte.

Le medie delle indagini sembrano più rassicuranti. L'ERP Report 2026 di Panorama Consulting ha rilevato che più di un quarto delle organizzazioni ha superato il budget ERP, con esigenze tecnologiche aggiuntive come causa principale. Le medie delle indagini e i programmi che finiscono sul tavolo di un advisor sono popolazioni diverse, quindi pianifichi per la seconda.

40-60%

di sforamento del budget che vedo spesso nei programmi SAP che analizzo

Fonte: Noel D'Costa, osservazione pubblicata

Questo articolo riguarda lo sforamento, non la cifra di partenza. Per le fasce di costo in base alla dimensione dell'azienda, dove va il denaro, le tariffe giornaliere e una formula di budget, legga la mia guida su quanto costa un'implementazione SAP.

Nei 21 programmi SAP che ho guidato o risanato, tornano sempre le stesse cause. La maggior parte è visibile prima della firma del contratto.

1. Il budget viene fissato basso, poi Explore mostra il perimetro reale

È il motivo più comune che vedo. Le aziende cercano di tenere basso il costo all'inizio, spesso perché il business case ha bisogno di una cifra che il consiglio di amministrazione approvi. Poi arriva la fase Explore.

In SAP Activate, Explore è la fase in cui i workshop di fit-to-standard confrontano i processi standard di SAP con il modo in cui l'azienda lavora davvero (SAP Learning). Ogni gap individuato lì diventa una voce del backlog: un report, un'interfaccia, una conversione, un enhancement, un modulo o un workflow. Nessuno di questi era nel prezzo originale.

Il budget non era sbagliato per un errore di calcolo. Era sbagliato perché era stato fissato prima che il perimetro esistesse. Se può, faccia una breve valutazione di fit-to-standard prima di approvare la cifra finale.

2. Il fornitore controlla il perimetro

L'errore di costo più grande che vedo prima della firma è permettere al fornitore di controllare il perimetro. Quando è il system integrator a scrivere il perimetro, questo descrive ciò che l'integratore intende consegnare, non ciò di cui l'azienda ha bisogno.

I gap emergono più tardi come richieste di modifica, e ogni richiesta di modifica viene quotata dallo stesso fornitore. Scriva il perimetro Lei stesso, oppure lo faccia scrivere insieme a qualcuno indipendente dall'implementazione.

3. Modifiche al perimetro senza controllo dei costi

Una catena retail aveva un budget di 5M $ e ha chiuso a 12,3M $. Una raccolta dei requisiti carente ha portato a continue modifiche del perimetro. A metà progetto ha scoperto che i suoi processi di magazzino non corrispondevano alla funzionalità standard di SAP, e ne è seguita una personalizzazione estesa.

Aveva anche sottovalutato la migrazione dei dati dai sistemi legacy. Allineare i processi allo standard già in fase di design sarebbe costato molto meno.

4. Tempistiche dettate dalla pressione del management

Un programma manifatturiero globale ha sforato il budget del 143% (14M $ contro i 5,8M $ previsti) ed è andato live con 11 mesi di ritardo. Le cause: una pressione irrealistica del management sui tempi, un team interno sottodimensionato, troppi moduli insieme e un partner scelto perché il più economico, senza competenze di settore.

Più economico non significa automaticamente migliore. Un cliente che aveva scelto l'opzione di implementazione meno costosa ha finito per spendere il 30% in più per correggere problemi che un team più esperto avrebbe evitato.

5. Personale interno part-time

I programmi che assegnano referenti part-time invece di process owner dedicati perdono giorni a ogni decisione. Il team interno sottodimensionato di quel programma manifatturiero globale è stato uno dei motivi degli 11 mesi di ritardo.

Le Sue persone migliori saranno impegnate sul programma per metà del tempo o più per mesi. Né il loro tempo né il rallentamento attorno al go-live compaiono nel preventivo di un fornitore.

6. Dati scoperti tardi

I problemi di dati scoperti in pre-produzione sono i più costosi. La profilazione dovrebbe procedere in parallelo ai requisiti, non dopo la configurazione. Tre mesi di pulizia sotto la pressione di un sistema in produzione sono costantemente tra le voci di costo da ritardo più pesanti nei programmi in sforamento.

Tratto questo tema anche in un video sul mio canale YouTube (in inglese).

Il segnale di allarme più chiaro è la fase Explore stessa. Tenga d'occhio il numero di oggetti WRICEF: report, interfacce, conversioni, enhancement, moduli e workflow. Se quell'elenco continua a crescere un workshop dopo l'altro, il budget è già indietro rispetto al perimetro.

Ciascuno dei segnali seguenti rimanda a una delle cause viste sopra. La maggior parte si può verificare in una revisione settimanale del programma.

Segnale di allarme	Cosa significa di solito	Cosa fare
Il numero di WRICEF cresce durante Explore	Il perimetro reale è più ampio di quello quotato	Ridefinire la baseline del budget alla fine di Explore, prima che inizi Realize
I gap si chiudono per default con «lo sviluppiamo»	I processi standard non vengono messi in discussione	Chiedere al responsabile di business di giustificare ogni gap rispetto allo standard
Documenti di perimetro redatti dal system integrator	Il fornitore controlla ciò che viene quotato	Assumersi la responsabilità del perimetro e rivederlo con una figura indipendente
Richieste di modifica esaminate mensilmente o non quotate	Le piccole modifiche si sommano senza che nessuno se ne accorga	Quotare ogni richiesta di modifica ed esaminarle ogni settimana
Profilazione dei dati non avviata entro la fine di Explore	I problemi di dati emergeranno nei test o al cutover	Avviare subito la profilazione, in parallelo ai requisiti
Key user ancora part-time	Le decisioni rallentano e le rilavorazioni aumentano	Coprire il loro lavoro quotidiano o spostare la pianificazione

Ciascuno di questi controlli interviene su una delle cause viste sopra. I casi provengono da programmi su cui ho lavorato o che ho analizzato.

1. Si assuma la responsabilità del perimetro. Lo scriva lato cliente, lo congeli alla fine di Explore e tratti ogni modifica successiva come una decisione con un prezzo, non come una nota di workshop.
2. Adotti i processi standard. Ogni personalizzazione costa due volte: quando la si realizza e poi a ogni upgrade. Un cliente manifatturiero ha risparmiato oltre 800K $ adattando i propri processi agli standard SAP invece di personalizzare. È stato doloroso per alcuni reparti, ma la differenza economica è stata enorme.
3. Proceda con un roll-out a fasi. Un cliente retail ha risparmiato 1,2M $ suddividendo il roll-out in tre fasi nell'arco di 18 mesi invece di fare tutto insieme. L'investimento iniziale è sceso del 40%, e le lezioni della fase 1 hanno reso più rapide le fasi successive.
4. Paghi la competenza, non una tariffa giornaliera bassa. Un cliente del settore chimico è passato da un partner SAP generalista a uno specialista di settore e ha speso complessivamente il 20% in meno nonostante tariffe orarie più alte. Gli specialisti hanno lavorato più velocemente e commesso meno errori.
5. Tenga la riserva dalla Sua parte. Mantenga un 10-20 percento oltre al budget, da sbloccare solo a fronte di rischi identificati. Una riserva inclusa nel prezzo del partner viene spesa secondo le priorità del partner.
6. Esamini le richieste di modifica ogni settimana. Quoti ciascuna per impatto su budget e tempi prima di approvarla, non a fine mese.
7. Automatizzi i test di regressione. Strumenti come Tricentis Tosca o la stessa automazione dei test di SAP si ripagano in qualsiasi programma con più di due cicli di test, e ogni upgrade dopo il go-live è un ciclo in più.

Per il lato commerciale, la mia checklist per la negoziazione delle licenze SAP e la mia revisione dei costi contrattuali per i CFO spiegano su cosa insistere prima di firmare.

Il modello in abbonamento sposta la spesa da investimento a costo operativo. Non elimina il rischio di sforamento, ma ne sposta la collocazione.

GROW with SAP gira su S/4HANA Cloud Public Edition, che consente estensioni solo tramite interfacce rilasciate. Questo limita quanto può crescere l'elenco WRICEF, e i programmi GROW durano spesso circa 6-9 mesi. Il compromesso è una minore libertà di adattare SAP a processi insoliti.

RISE with SAP gira su S/4HANA Cloud Private Edition, dove è ancora possibile modificare il core. Lì il Clean Core è una decisione di governance, non un limite tecnico, quindi il rischio della fase Explore è lo stesso dell'on-premise. I programmi RISE durano tipicamente 9-18 mesi, e la durata pluriennale dell'abbonamento deve essere visibile nel business case.

L'AI è una nuova voce di budget, non un risparmio da mettere in conto. Alcune funzionalità di Joule sono incluse negli abbonamenti cloud SAP, mentre le funzionalità di AI premium hanno un prezzo a parte. Chieda quale ipotesi di produttività c'è dietro qualsiasi listino di un partner che promette risparmi grazie all'AI.

Questo incide su come un grande programma pesa sul conto economico. Secondo gli IFRS e gli US GAAP, i costi per costruire un'attività che Lei controlla possono essere capitalizzati; i costi di gestione, formazione e preparazione no. Il cloud cambia la risposta per una parte consistente del budget.

Voce di costo	Licenza on-premise	Abbonamento cloud (RISE / GROW)
Canoni di licenza o abbonamento	Capitalizzare come attività immateriale	Spesare lungo la durata (contratto di servizi)
Servizi di configurazione e sviluppo	Capitalizzare se direttamente attribuibili	IFRS: spesso spesati, a meno che creino un'attività separata che Lei controlla. US GAAP: capitalizzare i costi di implementazione e ammortizzarli lungo la durata dell'hosting
Lavoro interno sullo sviluppo	Capitalizzare se direttamente attribuibile	Stessa ripartizione di sopra
Formazione e change management	Spesare	Spesare
Pulizia dei dati	Spesare	Spesare
Strumenti di conversione dei dati che conserva	Capitalizzare se riutilizzabili	Valutare caso per caso
Hypercare e supporto	Spesare	Spesare

La posizione IFRS deriva dalla agenda decision del 2021 dell'IFRS Interpretations Committee sui costi di configurazione e personalizzazione negli accordi di cloud computing. La posizione US GAAP deriva dall'ASU 2018-15. Soprattutto con gli IFRS, un business case RISE che presuppone la capitalizzazione tipica dell'on-premise può sovrastimare in modo rilevante l'utile del primo anno.

La documentazione decide quanto riesce a capitalizzare. Un cliente manifatturiero ha risparmiato 2,3M $ di costi nell'esercizio capitalizzando correttamente, perché aveva tracciato le attività dei consulenti con una precisione sufficiente a difendere l'approccio. Un altro cliente ha dovuto affrontare una dolorosa riesposizione dei bilanci perché non riusciva a documentare le proprie decisioni di capitalizzazione.

I revisori esaminano con attenzione i grandi progetti capitalizzati. Concordi la policy con loro prima che il programma inizi, non a fine esercizio.

La maggior parte dei programmi in sforamento non ha avuto un fallimento di pianificazione. Ha avuto un problema di onestà in fase di pianificazione. Un CFO che approva un piano realistico con una riserva adeguata spende meno di uno che approva un piano ottimistico senza riserva.

Questa guida fa parte della mia guida all'implementazione di SAP, che collega tutti i temi, dal business case al go-live.

Perché le implementazioni SAP sforano il budget?

Il più delle volte perché il budget viene tenuto basso all'inizio e poi la fase Explore mostra il perimetro reale. I workshop di fit-to-standard trasformano i gap in report, interfacce, conversioni, enhancement, moduli e workflow mai quotati. Un perimetro controllato dal fornitore, team interni part-time e un lavoro sui dati avviato tardi peggiorano la situazione.

Di quanto sforano di solito il budget i progetti SAP?

Nei programmi che ho analizzato, sforamenti del 40-60 percento sono frequenti. L'indagine 2026 di Panorama Consulting ha rilevato che più di un quarto delle organizzazioni ha superato il budget ERP. I programmi che arrivano a un advisor tendono a essere la coda problematica di quella popolazione.

Quali sono i segnali di allarme precoci di uno sforamento del budget SAP?

Il segnale più chiaro è un numero di WRICEF che continua a crescere durante la fase Explore. Altri sono documenti di perimetro redatti dal fornitore, richieste di modifica non quotate ogni settimana, profilazione dei dati non ancora avviata e key user ancora part-time. Ridefinisca la baseline del budget alla fine di Explore se l'elenco è cresciuto.

Come si ferma lo scope creep in un progetto SAP?

Si assuma il perimetro lato cliente invece di lasciarlo scrivere al system integrator. Lo congeli alla fine di Explore, metta in discussione ogni gap rispetto allo standard SAP e quoti ogni richiesta di modifica prima di approvarla. Esamini le richieste di modifica ogni settimana, non a fine mese.

RISE with SAP riduce il rischio di sforare il budget?

Non da solo. RISE gira sulla Private Edition, dove il core può ancora essere modificato, quindi il rischio della fase Explore è lo stesso dell'on-premise. GROW with SAP sulla Public Edition limita le estensioni alle interfacce rilasciate, il che restringe quanto può crescere il perimetro.

Si possono capitalizzare i costi di implementazione di RISE with SAP?

In parte, e dipende dal Suo quadro contabile. L'abbonamento in sé viene normalmente spesato. Secondo gli IFRS, anche i servizi di configurazione e personalizzazione in un accordo SaaS sono spesso spesati, a meno che creino un'attività separata che Lei controlla; secondo gli US GAAP (ASU 2018-15), i costi di implementazione vengono capitalizzati e ammortizzati lungo la durata dell'hosting.