Perché i progetti SAP CX sforano il budget (e come evitarlo)

I progetti SAP CX raramente sforano il budget a causa del software. Lo sforano per il modo in cui vengono delimitati, composti, pianificati e integrati, e la maggior parte di queste cause è visibile prima della firma del contratto.

Non è un problema solo del CX. BCG ha intervistato oltre 1’000 aziende: per più di due terzi dei grandi programmi tecnologici non si prevede una consegna nei tempi, nel budget o nel perimetro previsto (BCG, 2024). Gli schemi dietro questo dato sono gli stessi che vedo nei progetti SAP CX.

In sintesi: i progetti SAP CX sforano il budget per cinque ragioni prevedibili: un perimetro mai davvero definito, troppi consulenti junior, una pianificazione a cascata per un software cloud, un’integrazione ERP sottovalutata e una gestione del cambiamento relegata in fondo. Un modello di prezzo che premia i ritardi peggiora tutte e cinque. Con la checklist in sette punti alla fine dell’articolo può verificare l’offerta di un partner su ciascuna, prima di firmare.

Motivo 1: il perimetro non è mai stato davvero definito

Non si tratta di scope creep, ma di nebbia. Il perimetro non è mai stato abbastanza chiaro da poter crescere di nascosto.

Molti progetti partono con un documento di requisiti di 40 pagine che sembra una lista dei desideri. «Il sistema deve supportare tutti gli attuali processi di vendita.» Che cosa significa? Nessuno è d’accordo. Il partner stima in base alla sua interpretazione, il cliente si aspetta altro e dopo tre mesi il divario diventa visibile. E costoso.

Cosa funziona invece: definisca il perimetro a livello di processo, non di funzionalità. «Configurare la conversione da lead a opportunità con assegnazione automatica del territorio per i mercati DACH, incluso un flusso di approvazione per le trattative oltre CHF 50’000.» Questo è un elemento di perimetro. «Supportare i processi di vendita» no. Arrivare a questa precisione prima che un partner quoti qualsiasi cosa è il compito della consulenza di business prima dell’implementazione SAP.

In Spadoom i progetti iniziano con un workshop di definizione del perimetro che produce un elenco fisso di consegne. Ciò che non è nell’elenco non fa parte del progetto; se il cliente vuole aggiungere qualcosa, viene quotato a parte. Il progetto Nussbaum mostra come si presenta questa disciplina nella pratica: prima la pipeline, tutto il resto dopo.

Motivo 2: troppi consulenti junior

È il segreto di Pulcinella delle grandi società di consulenza: vendono il progetto con architetti senior nella stanza e poi lo affidano a consulenti con 18 mesi di esperienza che imparano SAP Sales Cloud V2 a spese del suo budget.

Un’attività che a un senior richiede due giorni può costarne cinque a un junior, più altri due per correggere gli errori. I junior costruiscono soluzioni di ripiego invece di usare la configurazione standard e prendono decisioni architetturali che emergono come problemi solo durante i test. A quel punto si è a tre mesi dall’inizio e nessuno vuole ricominciare. La tariffa giornaliera «più bassa» finisce per costare di più.

Cosa funziona invece: chieda al partner esattamente chi lavorerà al progetto. Pretenda nomi, CV e certificazioni SAP. Chieda quanti progetti V2 hanno completato queste persone (non V1: l’architettura è diversa). Se la risposta è vaga, quella è la risposta. L’elenco completo delle domande è nella nostra guida su come scegliere il partner di implementazione SAP CX.

Nella nostra offerta indichiamo il team per nome, e le persone che incontra nel workshop sono quelle che configurano il suo sistema.

Motivo 3: pianificazione a cascata in un mondo cloud

I prodotti SAP CX sono software cloud con release regolari. Configurati, non programmati da zero. Eppure molti progetti vengono ancora pianificati in fasi rigide: tre mesi di blueprint, tre di sviluppo, uno di test, go-live in un colpo solo.

Quando il blueprint è pronto, la piattaforma ha già ricevuto nuove release e i requisiti sono cambiati. Gli utenti non vedono nulla di funzionante fino al sesto mese. Quando finalmente succede, il feedback arriva come una valanga di richieste di modifica.

Non è scope creep. È un problema di metodo.

Cosa funziona invece: SAP Activate, la metodologia di implementazione di SAP stessa, esiste per un motivo. Consegna iterativa, un sistema funzionante presto, feedback degli utenti ogni due settimane e correzioni di rotta finché costano poco.

Di solito lavoriamo in sprint di due settimane con una demo alla fine di ciascuno, così i problemi emergono presto, quando il budget può ancora assorbirli.

Motivo 4: l’integrazione con l’ERP viene sottovalutata

«Dobbiamo solo collegarlo al nostro ERP.» Poche frasi sono costate di più ai progetti SAP.

Collegare SAP Sales Cloud V2 a SAP S/4HANA significa mappare modelli di dati, sincronizzare le anagrafiche, risolvere i conflitti, gestire frequenze di aggiornamento diverse e costruire la gestione degli errori per la notte in cui il middleware si blocca. A questo si aggiunge il middleware stesso, di solito SAP Integration Suite, con la sua progettazione, il suo monitoraggio e persone che lo conoscano.

I progetti CX raramente falliscono dentro il CRM. Falliscono nel punto di contatto con l’ERP: l’ordine che non viene registrato, il prezzo che l’offerta non trova, il cliente che esiste due volte. Quando il partner CX e il partner ERP sono aziende diverse, quel punto diventa una riga in due contratti di cui nessuno è responsabile. Spadoom realizza il nucleo ERP e lo stack CX con un solo team; per questo trattiamo quel punto di contatto come parte del progetto e non come l’interfaccia di qualcun altro. Spieghiamo la differenza in il miglior partner SAP per Cloud ERP e CRM in Svizzera.

Cosa funziona invece: metta a budget l’integrazione separatamente. Non come una voce qualsiasi, ma come un filone di lavoro con tempi e fase di test propri. Ogni interfaccia riceve un disegno tecnico prima che inizi la configurazione e viene testata singolarmente prima dei test di integrazione di sistema. Cosa copre un disegno di questo tipo lo mostra il nostro articolo sull’architettura di integrazione tra Sales Cloud V2 e S/4HANA Public Cloud.

Motivo 5: la gestione del cambiamento arriva per ultima

Si può costruire la SAP Sales Cloud V2 meglio configurata del mondo. Se il team di vendita non la usa, ogni franco è sprecato. Lo schema è noto: un sistema pulito, pochi accessi e, tre mesi dopo il go-live, i venditori sono tornati ai loro fogli di calcolo perché nessuno ha investito per farli sentire a proprio agio con il nuovo strumento.

Molto di ciò che appare come sforamento del budget sono costi nascosti dopo il go-live: interventi d’emergenza perché gli utenti rifiutano il sistema, lo aggirano o sommergono l’helpdesk. Il progetto era «finito». Il lavoro no.

Cosa funziona invece: includa nel perimetro fin dal primo giorno la formazione degli utenti finali, i workshop per i key user e il monitoraggio dell’adozione, come un vero filone di lavoro con un proprio budget e non come ciò che resta alla fine.

Il problema del modello di prezzo

Sopra queste cinque cause ce n’è una strutturale: i contratti a consuntivo (time and materials).

Con la fatturazione a consuntivo, il partner guadagna di più se il progetto dura di più. Non insinuiamo che qualcuno rallenti di proposito, ma il modello toglie la pressione a essere efficienti, e il rischio di ogni errore di stima resta a lei.

I contratti a prezzo fisso con perimetro fisso invertono gli incentivi: gli sforamenti pesano sul margine del partner, non sul suo budget. Funzionano però solo se il perimetro è definito abbastanza bene da poterlo quotare, e così torniamo al motivo 1. Dove il perimetro lo consente offriamo un prezzo fisso; il nostro assessment di readiness S/4HANA di cinque giorni, per esempio, ha un prezzo fisso che viene scalato dalla trasformazione se si decide di procedere.

Una checklist pratica per il budget

Prima di firmare il prossimo contratto SAP CX, verifichi questi sette punti:

1. Il perimetro è dettagliato. Ogni consegna è descritta a livello di processo, con criteri di accettazione.
2. Il team ha un nome. Sa chi lavora al progetto e con quale esperienza.
3. Il metodo è iterativo. Vede software funzionante entro il primo mese.
4. L’integrazione è definita separatamente. Con tempi e piano di test propri.
5. La gestione del cambiamento è a budget. Formazione, documentazione e supporto all’adozione sono inclusi dall’inizio.
6. Il prezzo vale per un perimetro fisso. O almeno c’è un tetto massimo con una procedura chiara per le richieste di modifica.
7. Le referenze sono reali. Può parlare con clienti che hanno concluso progetti simili.

Se un partner fa resistenza su uno di questi punti, questo le dice qualcosa.

In conclusione

I progetti SAP CX non sforano il budget per colpa di SAP. Lo sforano per il modo in cui vengono pianificati, composti e gestiti.

Le aziende che hanno successo trattano l’implementazione come un progetto di business, non come un progetto IT. Investono in un perimetro chiaro, pretendono team esperti e consegne iterative, mettono a budget l’integrazione ERP con onestà e scelgono partner i cui incentivi coincidono con una consegna puntuale.

Se sta pianificando un’implementazione SAP CX o deve salvarne una finita fuori rotta, parliamo apertamente di ciò che serve.

La maggior parte di questi sforamenti si decide quando si sceglie il partner. Il nostro confronto delle migliori società di consulenza SAP CX in Svizzera elenca le prove da chiedere, e la nostra pagina sulla consulenza SAP CX in Svizzera mostra come definiamo e componiamo un progetto.

Domande frequenti

Qual è lo sforamento medio del budget nei progetti SAP CX?

Non esiste un dato affidabile specifico per SAP CX. Sui grandi programmi tecnologici, BCG ha rilevato che per più di due terzi non si prevede una consegna nei tempi, nel budget o nel perimetro (BCG, 2024). Uno studio di Oxford su 1’471 progetti IT ha mostrato che uno su sei ha avuto uno sforamento dei costi di circa il 200% (Flyvbjerg e Budzier, 2011). I progetti SAP CX seguono gli stessi schemi.

Il prezzo fisso è sempre meglio della fatturazione a consuntivo?

Non sempre. Il prezzo fisso funziona meglio quando il perimetro è ben definito, come nella maggior parte dei progetti di implementazione. La fatturazione a consuntivo è adatta ad attività con un perimetro davvero incerto, come la consulenza o i proof of concept. Scelga il modello di prezzo in base al tipo di progetto.

Come capisco se il partner sta sottovalutando l’integrazione?

Se collega un ERP e l’integrazione è solo una piccola parte della stima, senza tempi né piano di test propri, sia scettico. Si faccia elencare ogni interfaccia, il middleware, la gestione degli errori e l’approccio ai test. Stime di integrazione vaghe sono un campanello d’allarme.

Serve un nostro project manager o basta quello del partner?

Entrambi. Il project manager interno risponde dei risultati di business e degli stakeholder, quello del partner della consegna. Se c’è solo quello del partner, ha delegato la responsabilità del suo stesso progetto.

Quanto dovremmo mettere a budget per la gestione del cambiamento?

Abbastanza da gestirla come un vero filone di lavoro: formazione degli utenti finali, workshop per i key user, documentazione e monitoraggio dell’adozione dopo il go-live. La quota esatta dipende dal numero di utenti e da quanto cambia il loro lavoro quotidiano, ma deve essere una voce esplicita del piano fin dall’inizio, non ciò che resta alla fine.