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

Ecco un numero che dovrebbe preoccupare ogni CIO: secondo i benchmark di settore, circa il 60% dei progetti di implementazione SAP supera il budget originale. Alcuni del 20%. Alcuni del 200%.

Le ragioni sono raramente tecniche. Sono strutturali. E la maggior parte è evitabile, se sapete dove guardare prima di firmare il contratto.

Abbiamo realizzato progetti SAP Sales Cloud V2, Service Cloud V2 e Commerce Cloud nel manifatturiero, nel retail e nella distribuzione. Alcuni li abbiamo ereditati in piena crisi da altri partner. I fallimenti di budget seguono sempre gli stessi schemi.

Motivo 1: Lo scope non era mai stato davvero definito

Questa è la causa numero uno degli sforamenti di budget. Non scope creep — nebbia di scope.

Molti progetti iniziano con un documento di requisiti di 40 pagine che sembra una lista dei desideri. “Il sistema deve supportare tutti i processi di vendita attuali.” Cosa significa? Nessuno è d’accordo. Il partner stima in base alla sua interpretazione. Il cliente si aspetta qualcos’altro. Dopo tre mesi, il divario diventa visibile — e costoso.

Cosa funziona invece: Definite lo scope a livello di processo, non di funzionalità. “Configurazione della conversione lead-to-opportunity con assegnazione automatica del territorio per i mercati DACH, incluso workflow di approvazione per deal superiori a CHF 50.000.” Questo è un elemento di scope. “Supportare i processi di vendita” non lo è.

In Spadoom, ogni progetto inizia con un workshop di scoping che produce una lista fissa di deliverable. Se non è nella lista, non è nel progetto. Se il cliente vuole aggiungere qualcosa, lo prezzamo separatamente. Nessuna ambiguità.

Motivo 2: Troppi consulenti junior

Questo è il segreto di Pulcinella delle grandi società di consulenza. Vendono il progetto con architetti senior nella stanza. Poi lo staffano con consulenti che hanno 18 mesi di esperienza e stanno imparando SAP Sales Cloud V2 sul vostro budget.

I consulenti junior impiegano più tempo. Commettono errori architetturali che vengono scoperti durante i test. Costruiscono workaround invece di usare la configurazione standard. Un’attività che un consulente senior completa in 2 giorni richiede 5 giorni per un junior — più altri 2 per correggere gli errori.

La matematica è brutale. Pagate CHF 1.500/giorno per qualcuno che lavora al 40% della velocità di qualcuno che costa CHF 2.200/giorno. La risorsa “più economica” vi costa di più.

Cosa funziona invece: Chiedete al vostro partner esattamente chi lavorerà al vostro progetto. Richiedete nomi, CV e certificazioni SAP. Chiedete quanti progetti V2 hanno completato (non V1 — l’architettura è completamente diversa). Se la risposta è vaga, quella è la vostra risposta.

Ogni progetto Spadoom è staffato con consulenti senior che hanno realizzato molteplici implementazioni V2. Nessun junior che impara a vostre spese.

Motivo 3: Pianificazione a cascata in un mondo cloud

I prodotti SAP CX sono cloud-based. Ricevono aggiornamenti trimestrali. Si configurano, non si programmano da zero. Eppure molti partner pianificano ancora i progetti in fasi waterfall rigide: 3 mesi di blueprinting, 3 mesi di build, 1 mese di testing, go-live big-bang.

Il problema: quando finite il blueprint, la piattaforma ha avuto due aggiornamenti. I requisiti sono cambiati. Gli utenti non hanno visto nulla di funzionante fino al mese 6. E quando finalmente lo vedono, il ciclo di feedback crea una valanga di richieste di modifica.

Cosa funziona invece: La metodologia SAP Activate esiste per un motivo. Delivery iterativo. Sistema funzionante dallo sprint 2. Feedback degli utenti ogni due settimane. Correzione di rotta quando costa poco, non dopo che tutto è stato costruito.

Tipicamente lavoriamo in sprint di 2 settimane con sessioni demo alla fine di ciascuno. I clienti vedono funzionalità operative dalla settimana 3. I problemi emergono presto. Il budget resta intatto.

Motivo 4: La complessità delle integrazioni viene sottovalutata

“Dobbiamo solo collegarlo al nostro ERP.” Questa frase ha distrutto più budget di progetto di qualsiasi altra.

Collegare SAP Sales Cloud V2 a SAP S/4HANA sembra semplice. Non lo è. Dovete mappare i modelli dati, gestire la sincronizzazione dei dati master, gestire la risoluzione dei conflitti, gestire frequenze di aggiornamento diverse e costruire la gestione degli errori per quando il middleware si blocca alle 2 di notte di venerdì.

Poi c’è il middleware stesso. SAP BTP Integration Suite, iPaaS di terze parti o API custom — ognuno ha la sua complessità. Ognuno necessita di monitoraggio. Ognuno richiede qualcuno che sappia davvero come configurarlo.

Cosa funziona invece: Budgetizzate l’integrazione separatamente. Non come voce singola — come un workstream dedicato con la propria timeline e la propria fase di test. Abbiamo visto progetti dove l’integrazione ha consumato il 40% dello sforzo totale. Se il vostro partner la stima al 10%, fate domande difficili.

Noi definiamo l’integrazione come una fase dedicata. Ogni interfaccia riceve un documento di design tecnico prima che venga scritta una singola riga di configurazione. Le interfacce vengono testate indipendentemente prima che inizino i test di integrazione di sistema.

Motivo 5: Il change management è un ripensamento

Potete configurare l’istanza SAP Sales Cloud V2 più perfetta del mondo. Se il vostro team di vendita non la usa, avete sprecato ogni franco.

La maggior parte degli sforamenti di budget include un costo nascosto: spegnere incendi dopo il go-live perché gli utenti rifiutano il sistema, lo aggirano o inondano l’helpdesk di ticket. Il progetto è “finito” ma il lavoro no.

Cosa funziona invece: Includete formazione per gli utenti finali, workshop per i key user e monitoraggio dell’adozione nello scope del progetto dal primo giorno. Budgetizzate il 10-15% del costo totale del progetto per il change management. Non è opzionale.

Il problema del modello di prezzo

Oltre a queste cinque cause, c’è un problema strutturale: i contratti time-and-materials.

T&M significa che il partner guadagna di più quando il progetto dura di più. Questo è un incentivo disallineato. Non suggeriamo che i partner rallentino deliberatamente — ma il T&M rimuove la pressione ad essere efficienti.

I contratti a scope fisso e prezzo fisso invertono l’incentivo. Il partner è motivato a consegnare in modo efficiente perché gli sforamenti gravano sul suo margine, non sul vostro budget.

In Spadoom lavoriamo con contratti a prezzo fisso. Il prezzo che vedete nell’offerta è il prezzo che pagate. Se sottostimiamo, è un problema nostro. Questo ci costringe a fare scoping onesto — esattamente la disciplina che previene gli sforamenti.

Una checklist pratica per il budget

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

1. Lo scope è granulare. Ogni deliverable è descritto a livello di processo con criteri di accettazione.
2. Il team è definito. Sapete esattamente chi lavora al vostro progetto e quale esperienza hanno.
3. La metodologia è iterativa. Vedete software funzionante entro il primo mese.
4. L’integrazione è definita separatamente. Con la propria timeline e il proprio piano di test.
5. Il change management è budgetizzato. Formazione, documentazione, supporto all’adozione — inclusi dall’inizio.
6. Il prezzo è fisso. O almeno c’è un tetto massimo con procedure chiare per le richieste di modifica.
7. Le referenze sono reali. Potete parlare con clienti che hanno completato progetti simili nei tempi e nel budget.

Il punto fondamentale

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

Le aziende che hanno successo trattano l’implementazione come un progetto di business, non un progetto IT. Investono in scope chiaro. Pretendono team esperti. Insistono su delivery iterativo. E scelgono partner i cui incentivi finanziari sono allineati con la consegna puntuale.

Manteniamo un record del 100% di go-live su tutti i progetti SAP CX che abbiamo realizzato. Non perché siamo fortunati — perché ci rifiutiamo di iniziare un progetto senza le discipline descritte sopra.

Se state pianificando un’implementazione SAP CX — o ne state salvando una che è andata fuori controllo — parliamone apertamente.