Perché noi completiamo i progetti SAP CX quando altri falliscono

Un numero sorprendente di progetti SAP CX non va mai in produzione. Le stime di settore suggeriscono che il 20-30% delle implementazioni CRM enterprise viene cancellato, “messo in pausa indefinitamente”, oppure arriva in produzione così in ritardo e così oltre budget che nessuno lo chiama un successo.

Abbiamo realizzato progetti SAP Sales Cloud V2, Service Cloud V2 e Commerce Cloud per produttori, retailer e distributori in tutta Europa. Ognuno è andato live. Non alla fine. Alla data concordata.

Non è un argomento di vendita. È un track record che proteggiamo con rigore — perché nel momento in cui non consegniamo, la nostra reputazione è finita. Non siamo un’azienda da 5.000 persone che può assorbire un progetto fallito. Siamo un team focalizzato dove ogni progetto conta.

Ecco cosa facciamo diversamente.

Consulenti senior dal primo giorno

Quando una grande società di consulenza vince un deal SAP CX, il team che ha venduto raramente è il team che consegna. Il team vendita aveva 20 anni di esperienza. Il team di delivery ne ha 20 mesi.

Noi non abbiamo un team vendita e un team delivery separati. Le persone che fanno lo scoping del vostro progetto sono le persone che lo costruiscono. Ogni consulente in un engagement Spadoom ha realizzato molteplici implementazioni SAP V2. Sanno dove finisce la configurazione della piattaforma e dove inizia lo sviluppo custom. Sanno quali integrazioni sono semplici e quali divoreranno tre settimane della vostra timeline.

Quando abbiamo realizzato SAP Sales Cloud V2 per Franke in 90 giorni, lo stesso architetto che ha condotto il workshop di scoping configurava il sistema dal giorno uno. Nessun passaggio di consegne. Nessuna perdita di conoscenza. Nessun periodo di avviamento.

Diciamo di no

Questa potrebbe essere la cosa più importante che facciamo. Diciamo di no ai progetti che non possiamo consegnare.

Se un prospect vuole implementare SAP Sales Cloud V2, Service Cloud V2, Commerce Cloud, Emarsys e CDP in un singolo progetto di 6 mesi con un team di quattro persone, diciamo che non è realistico. Se un’azienda vuole replicare il proprio CRM on-prem di 15 anni feature-per-feature in un sistema cloud, spieghiamo perché è l’approccio sbagliato.

Alcuni partner dicono sì a tutto perché il valore del contratto è troppo attraente. Poi la realtà colpisce al mese 3.

Preferiamo perdere un deal piuttosto che danneggiare il nostro record di go-live. Ogni volta che diciamo no, proteggiamo i prossimi 10 clienti che hanno bisogno di trovarci disponibili e focalizzati.

Scope fisso, non speranze fisse

Ogni progetto Spadoom ha un documento di scope fisso. Non una panoramica ad alto livello — una lista dettagliata di deliverable con criteri di accettazione.

“Configurazione dell’opportunity management con 4 stadi personalizzati, pipeline ponderata e notifiche automatizzate” è un deliverable. “Configurare il CRM” non lo è.

Questo protegge entrambe le parti. Il cliente sa esattamente per cosa paga. Noi sappiamo esattamente cosa dobbiamo consegnare. Quando qualcuno chiede qualcosa fuori dallo scope, non diciamo no — diciamo “sì, ecco quanto costa e come impatta la timeline.” Change management trasparente invece di nebbia di scope.

L’implementazione di SAP Sales Cloud V2 per Nussbaum è durata 5 mesi. Non perché abbiamo accelerato — perché lo scope era chiaro dalla settimana uno. Nessuna sorpresa. Nessuna scoperta dell’ultimo minuto. Nessun “pensavamo fosse incluso.”

Delivery iterativo con SAP Activate

Seguiamo la metodologia SAP Activate. Non perché SAP lo richiede, ma perché funziona.

Ecco come si presenta nella pratica:

• Settimana 1-2: Fase Discover — validazione dei requisiti, conferma delle integrazioni, setup dell’ambiente di sviluppo.
• Settimana 3-4: Primo sprint — gli utenti vedono un sistema funzionante con le funzionalità core.
• Ogni 2 settimane successive: Sessione demo con i key user. Testano. Danno feedback. Adattiamo.
• Ultime 2-3 settimane: Test di integrazione, validazione della migrazione dati, user acceptance testing, preparazione al go-live.

La differenza critica: i problemi emergono alla settimana 4, non al mese 6. Una configurazione che non corrisponde al processo di business viene corretta nello sprint successivo, non in una riunione di crisi tre giorni prima del go-live.

Accesso diretto ai decision-maker

In molte società di consulenza, c’è un account manager tra voi e le persone che fanno il lavoro. Volete cambiare una priorità? Parlate con l’account manager. Avete una domanda tecnica? L’account manager “si informerà e vi farà sapere.” Serve una decisione architetturale? Aspettate il prossimo steering committee.

In Spadoom, parlate direttamente con gli architetti e i consulenti che costruiscono il vostro sistema. Dovete escalare? Il nostro CEO risponde al telefono. Non c’è uno strato burocratico tra una domanda e una risposta.

Questa velocità conta. Una decisione che richiede 2 giorni in una grande azienda richiede 2 ore con noi. Su un progetto di 5 mesi, questa differenza si accumula in settimane di tempo risparmiato.

Scoping onesto

Prima di scrivere un’offerta, conduciamo un workshop di scoping. Tipicamente 2-3 giorni, a seconda della complessità. Mappiamo i processi di business, identifichiamo i punti di integrazione, valutiamo la qualità dei dati e la prontezza organizzativa.

A volte il risultato di questo workshop è: “Non siete ancora pronti per questo progetto.” Forse i dati master vanno prima puliti. Forse i processi di business devono essere concordati internamente prima che qualcuno configuri un sistema. Forse un approccio a fasi su 12 mesi ha più senso che cercare di fare tutto in una volta.

Dire a un prospect di aspettare ci costa fatturato nel breve termine. Ma previene un progetto fallito — che costerebbe molto di più a entrambi.

Cosa abbiamo imparato dai progetti ereditati

Alcune delle nostre migliori lezioni vengono da progetti che non abbiamo iniziato. Siamo stati chiamati a salvare implementazioni SAP CX bloccate con altri partner. Gli schemi sono consistenti:

• Scope vago cresciuto del 50% durante il progetto senza corrispondente adeguamento del budget.
• Team junior che hanno scritto codice custom dove la configurazione standard avrebbe funzionato, creando un peso di manutenzione.
• Nessun test di integrazione fino alle ultime settimane, quando sono emersi problemi critici di mapping dati.
• Nessun coinvolgimento degli utenti fino allo UAT, quando il team vendite ha rifiutato il sistema perché nessuno aveva chiesto cosa serviva.
• Go-live big-bang senza piano di fallback, senza rollout graduale, senza gruppo pilota.

Ognuno di questi è prevenibile. Non con tecnologia migliore — con migliore disciplina di progetto.

L’approccio ANWR

Quando abbiamo lavorato con ANWR Group, il requisito era collegare SAP Sales Cloud V2 al loro panorama SAP esistente. Integrazione complessa, molteplici fonti dati, requisiti specifici del settore.

Siamo partiti con un pilota focalizzato: una business unit, un processo core. Abbiamo dimostrato che l’architettura funzionava. Validato i pattern di integrazione. Poi espanso. L’approccio pilota ha ridotto il rischio. ANWR ha visto valore presto. Il rollout più ampio si è costruito su fondamenta provate, non su assunzioni.

Il nostro track record

100% di go-live. Ogni progetto. Ogni volta.

Quel numero resta al 100% solo perché siamo selettivi in ciò che accettiamo, onesti in ciò che è realistico e disciplinati nel modo in cui consegniamo.

Non siamo l’opzione più economica. Non siamo l’azienda più grande. Ma quando il vostro progetto SAP CX deve assolutamente andare live nei tempi e nel budget, il track record conta più delle presentazioni.

Parlateci del vostro progetto — vi diremo onestamente se siamo il partner giusto.