Perché completiamo i progetti SAP CX quando altri falliscono

I progetti SAP CX falliscono raramente per colpa del software. Si bloccano perché il perimetro era vago, perché chi ha venduto il progetto non era chi l’ha realizzato, e perché l’integrazione con l’ERP è stata rimandata alle ultime settimane. Veniamo chiamati regolarmente in progetti di questo tipo, e i rimedi sono meno spettacolari di quanto molti si aspettino: le stesse persone esperte dal primo workshop al go-live, un perimetro scritto come elenco di consegne, il lavoro di integrazione dalla prima settimana e la disciplina di dire no.

In sintesi: Quattro abitudini portano in produzione i nostri progetti: persone esperte che definiscono e realizzano, un perimetro fatto di consegne verificabili, integrazione ERP e dati reali nei primi sprint, e il rifiuto dei progetti che non possiamo realizzare così come richiesti. Le prove sono pubbliche: il progetto V2 bloccato di OPO Oeschger era in produzione tre mesi dopo il nostro subentro, nei tempi e nel budget.

Come sono le prove

Preferiamo mostrare progetti piuttosto che citare un tasso di successo. Questi sono pubblicati con il consenso dei clienti:

• OPO Oeschger: un progetto Sales e Service Cloud V2 bloccato presso un altro partner. Lo abbiamo ripreso da capo: dopo due mesi l’MVP era operativo, dopo tre l’intera fase 1 era in produzione, nei tempi e nel budget, collegata a S/4HANA, Datasphere e Commerce Cloud.
• Franke: un progetto Commerce fermo. Spadoom ha portato in produzione la piattaforma SAP Commerce Cloud in 90 giorni, e il progetto ha ricevuto il SAP Quality Award per «Rapid Time to Value».
• Nussbaum: Sales Cloud V2 da zero, da nessun CRM centrale alla piena visibilità della pipeline in cinque mesi.
• intelligentfood: Sales e Service Cloud V2 in produzione in tre mesi, collegati all’ERP.

Non significa che ogni progetto sia semplice. Significa che gli schemi descritti qui sotto funzionano abbastanza spesso da non gestire più i progetti in altro modo.

Persone esperte dal primo giorno

Lo schema più frequente nei progetti che rileviamo è un passaggio di consegne. Un team esperto vince la commessa e passa alla presentazione successiva, e chi arriva per la realizzazione vede i requisiti per la prima volta. Nessuno lo fa apposta. È il modo in cui molte grandi società compongono i team.

Da noi non esistono un team di vendita e un team di realizzazione separati. Chi definisce il vostro progetto lo realizza anche, e ha già portato a termine progetti V2. In OPO Oeschger questo ha significato che il team che ha analizzato il progetto bloccato lo ha anche ricostruito, senza una seconda curva di apprendimento.

Un perimetro fatto di consegne

«Configurare il CRM» non è un perimetro. «Configurare la gestione delle opportunità con quattro fasi personalizzate, pipeline ponderata e notifiche automatiche» lo è. La differenza tra queste due frasi è la differenza tra un progetto che va in produzione e uno che finisce in mesi di rinegoziazioni.

Ogni progetto riceve un documento di perimetro con consegne e criteri di accettazione. Protegge entrambe le parti. Quando emerge un nuovo requisito non lo rifiutiamo: diciamo quanto costa e cosa comporta per i tempi, e voi decidete prima che inizi il lavoro.

Integrazione e dati reali fin da subito

La maggior parte delle sorprese tardive arriva dal confine con l’ERP: un prezzo che l’offerta non riesce a determinare, un ordine che non viene registrato, dati cliente che non corrispondono. Per questo progettiamo l’integrazione prima della prima schermata e carichiamo dati reali in un sistema di test nelle prime settimane. I problemi che emergono alla quarta settimana costano poco. Quelli che emergono al sesto mese sono già incorporati in tutto il resto.

Qui si vede anche il vantaggio di un solo team per ERP e CX. Poiché realizziamo sia S/4HANA Public Cloud sia Sales Cloud V2, l’interfaccia tra i due è una decisione di progettazione all’interno di un progetto, non una trattativa tra due fornitori. Descriviamo l’architettura in S/4HANA Public Cloud e Sales Cloud V2 come un unico stack.

Realizzazione iterativa con progressi visibili

Lavoriamo per brevi iterazioni secondo SAP Activate:

• Prime settimane: conferma di requisiti e integrazioni, configurazione dei sistemi, caricamento dei dati di test.
• Primi sprint: i key user vedono un sistema funzionante con i propri dati.
• Ogni due settimane: una demo con i key user, che provano e danno riscontro, e noi adattiamo.
• Prima del go-live: test di integrazione, verifiche della migrazione, test di accettazione e preparazione del passaggio in produzione.

Non conta il nome del metodo. Conta che i problemi diventino visibili finché sono ancora piccoli.

Saper dire no

Ci costa delle commesse, ed è probabilmente l’abitudine più importante. Se un potenziale cliente vuole Sales Cloud V2, Service Cloud V2, Commerce Cloud, SAP Engagement Cloud e CDP in un unico progetto di sei mesi con un team di quattro persone, diciamo che non è realistico e proponiamo una sequenza che lo sia. Se un’azienda vuole ricostruire nel cloud, campo per campo, il suo CRM di quindici anni fa, spieghiamo perché è l’obiettivo sbagliato. Una prima fase più piccola che va in produzione vale più di una grande che non ci arriva.

Cosa vediamo nei progetti che rileviamo

Nei progetti che arrivano da noi dopo essersi bloccati altrove ricorrono sempre gli stessi cinque problemi:

• Un perimetro vago cresciuto senza adeguare il budget.
• Codice personalizzato dove sarebbe bastata la configurazione standard.
• Nessun test di integrazione fino alle ultime settimane.
• Nessun coinvolgimento degli utenti fino ai test di accettazione, quando il team vendite ha respinto il sistema.
• Un go-live big bang senza piano di ripiego.

Sono tutti e cinque evitabili, e nessuno è un problema tecnologico. Se state valutando dei partner, la nostra guida su come scegliere un partner SAP CX trasforma questi schemi in domande da porre al primo incontro. I motivi per cui i budget vengono sforati sono trattati in perché i progetti SAP CX sforano il budget.

Domande frequenti

Tutti i vostri progetti vanno in produzione alla data prevista?

Non pubblichiamo una percentuale generica, perché un singolo numero nasconde più di quanto mostri. Pubblichiamo progetti con nome e tempistiche, tra cui OPO Oeschger, Franke, Nussbaum e intelligentfood. Chiedeteci referenze sul vostro prodotto e chiamatele.

Come gestite i requisiti che cambiano?

Con un perimetro scritto e un processo di modifica trasparente. Ogni modifica viene stimata e approvata prima che inizi il lavoro. Se una modifica sposterebbe il go-live, lo diciamo presto e voi decidete se adeguare i tempi o il perimetro.

Potete subentrare in un progetto SAP bloccato?

Sì. È così che sono iniziati i progetti OPO Oeschger e Franke. Partiamo da una breve analisi di ciò che esiste, decidiamo con voi cosa tenere e cosa ricostruire, e definiamo un nuovo piano con persone nominate. Non rattoppiamo vecchie impalcature se una ripartenza pulita è più rapida.

Dove lavorate?

Da Zugo, Wädenswil, Monza, Vienna e Tallinn, con progetti soprattutto in Svizzera, Germania, Austria e Italia. Abbiamo accompagnato rollout internazionali per aziende con sede in Europa. I nostri consulenti lavorano in tedesco, francese, italiano e inglese.

Come verifico i vostri risultati?

Leggete i progetti clienti e chiedeteci referenze sul prodotto che state acquistando. Chiedete direttamente alla referenza: il progetto è andato in produzione come previsto, il budget ha tenuto, le stesse persone sono rimaste fino alla fine? Se state preparando anche un passaggio ERP, iniziate con il nostro assessment di readiness S/4HANA oppure contattateci.