Implementare S/4HANA Public Cloud e Sales Cloud V2 insieme: Sequenza, tempi, rischi

Conviene implementare S/4HANA Public Cloud e SAP Sales Cloud V2 contemporaneamente?

È una delle domande più frequenti che riceviamo dalle aziende DACH che modernizzano il loro panorama SAP. La risposta onesta: dipende da quale problema è più urgente — e se l’organizzazione ha la capacità di gestione del programma per affrontare entrambi.

Fatto bene, un rollout congiunto garantisce fin dal primo giorno un modello dati condiviso e pulito: un record Business Partner, un catalogo prodotti, un flusso degli ordini. Fatto male, due progetti paralleli competono per la stessa banda IT, gli stessi key user e la stessa attenzione al change management. Qualcosa si rompe, oppure entrambi arrivano in ritardo.

Questo articolo illustra le tre opzioni di sequenza, come appare una tempistica combinata realistica, dove i due team di progetto devono rimanere sincronizzati — e i rischi che abbiamo visto più di una volta.

Conviene implementare S/4HANA Public Cloud e Sales Cloud V2 contemporaneamente?

Il punto di partenza è un’analisi onesta dei propri vincoli.

Gestire due grandi implementazioni SAP in parallelo è ambizioso. Entrambi i sistemi toccano i processi core del business. Entrambi richiedono tempo dei key user per workshop, test e formazione. Entrambi necessitano di lavoro di integrazione su BTP. Se il team IT o il budget di consulenza è limitato, la sequenzializzazione è più sicura.

Ma c’è un argomento reale a favore del delivery parallelo. Il modello Business Partner è condiviso tra S/4HANA Public Cloud e SAP Sales Cloud V2. Se si implementa prima il CRM senza l’ERP, si costruisce un’integrazione temporanea con l’ERP esistente — e poi si devono rifare parti di essa quando arriva S/4HANA. È rilavorazione evitabile con una sequenza migliore.

La risposta giusta dipende da tre fattori: quale sistema serve più urgentemente al business, qual è la capacità di change management disponibile, e se esiste un partner in grado di mantenere la responsabilità del livello di integrazione su entrambi i work stream.

Tre opzioni di sequenza

Prima ERP, poi CRM

È il default più sicuro. S/4HANA Public Cloud va live per primo, stabilendo il modello dati master Business Partner, il catalogo prodotti e i processi finanziari. Una volta che l’ERP è stabile — tipicamente 3-6 mesi dopo il go-live — il progetto Sales Cloud V2 parte con dati sorgente puliti da integrare.

Il compromesso: il team commerciale aspetta. Se la situazione CRM è critica — processi manuali, dati in fogli di calcolo, nessuna visibilità sulla pipeline — attendere 9-12 mesi per un migliore strumento di vendita è doloroso.

Cosa offre questa opzione: Sales Cloud V2 va live con dati ERP reali dal giorno uno. Nessun connettore temporaneo da ritirare. Nessuna migrazione dati da uno stato CRM intermedio. Il lavoro di integrazione viene fatto una volta, correttamente.

Prima CX, poi ERP

Meno comune, ma ha senso quando il processo commerciale è il punto critico principale e l’ERP è abbastanza stabile da lasciare temporaneamente com’è.

SAP Sales Cloud V2 va live contro l’ERP esistente — che sia ECC, S/4HANA on-premise o altro. L’integrazione viene costruita per quell’ERP. Quando S/4HANA Public Cloud arriva, l’integrazione viene ricostruita contro i nuovi endpoint ERP.

Il compromesso: si accetta un doppio lavoro di integrazione. La prima integrazione viene abbandonata quando l’ERP cambia. È costo e rilavorazione reali — ma se la priorità è portare un CRM moderno al team commerciale nel prossimo trimestre, può essere la scelta giusta.

Un rischio da segnalare: se il vostro ERP esistente ha dati master disordinati — record Business Partner inconsistenti, account duplicati, prezzi obsoleti — importerete quel caos in Sales Cloud. E poi lo pulirete di nuovo prima della migrazione a S/4HANA. Meglio pulire una volta sola, nella migrazione ERP, e partire con Sales Cloud pulito.

Delivery parallelo

Entrambi i progetti scorrono simultaneamente con un work stream di integrazione condiviso. Questo comprime la tempistica complessiva, ma aggiunge un significativo overhead di coordinamento.

Perché funzioni servono: un responsabile di programma dedicato che gestisca le dipendenze cross-stream, un chiaro proprietario dell’integrazione su BTP, e uno steering condiviso capace di risolvere i conflitti di priorità quando entrambi i progetti richiedono gli stessi key user contemporaneamente.

Abbiamo visto il delivery parallelo funzionare bene quando i due work stream sono genuinamente separati per team e perimetro — il team ERP gestisce finanza e logistica, il team CX gestisce il processo commerciale — e devono convergere solo sul livello di integrazione e sulla governance dei dati master. Dove fallisce: quando le stesse tre persone sono previste come key user in entrambi i progetti contemporaneamente.

Una tempistica combinata realistica

Queste sono stime separate, non una singola cifra combinata.

Le implementazioni greenfield di S/4HANA Public Cloud per PMI con un perimetro di processo standard — nessuna personalizzazione pesante, processi standard — durano tipicamente da 6 a 9 mesi dal kickoff al go-live. Questo è il range documentato per i rollout greenfield standard. Un perimetro complesso, multi-paese o una migrazione dati significativa estendono questa stima.

Le implementazioni SAP Sales Cloud V2 per il mercato mid-market — tipicamente 50-200 utenti, un paese, processi CRM standard — richiedono da 10 a 16 settimane. La nostra mediana sui progetti Sales Cloud V2 completati è 14 settimane dal kickoff al go-live. Team più piccoli con perimetro più stretto arrivano prima. Le implementazioni enterprise con integrazioni ERP complesse richiedono più tempo.

Per un programma combinato ERP-prima: l’ERP va live tra il mese 6 e il mese 9, il CX parte 1-2 mesi prima del go-live ERP (iniziando la progettazione dell’integrazione in anticipo), e Sales Cloud V2 va live circa al mese 10-15. Questo è il range realistico end-to-end per un rollout sequenziale.

Il delivery parallelo accorcia il programma complessivo — entrambi i sistemi possono puntare allo stesso trimestre — ma non quanto ci si aspetta. Il livello di integrazione deve comunque essere costruito, testato e stabilizzato, indipendentemente dal fatto che i due progetti corrano in sequenza o in parallelo.

Per una guida dettagliata sul lato CX, la nostra guida all’implementazione di SAP Sales Cloud V2 copre le fasi complete del progetto, la struttura del team e la ripartizione dei costi.

Dove i due team di progetto devono sincronizzarsi

Anche in un rollout sequenziale, i due team non possono operare in completo isolamento. Ci sono quattro aree in cui devono coordinarsi.

Modello Business Partner e governance dei dati master. Il progetto S/4HANA definisce la struttura del record Business Partner — campi, segmenti, ruoli. Sales Cloud V2 consuma quella struttura. Se il team CX non è presente nei workshop sui dati master ERP, scoprirà in fase di integrazione che i campi necessari non esistono o hanno nomi diversi. Soluzione: includere un rappresentante CX in ogni workshop sui dati master ERP.

Catalogo prodotti e prezzi. Sales Cloud V2 preleva i prezzi da S/4HANA. Il team del progetto ERP deve finalizzare i tipi di condizione e la struttura del catalogo prima che l’integrazione CX possa essere costruita. Un errore frequente: il team ERP congela il modello di prezzi due mesi dopo che l’integrazione CX è già stata progettata per una struttura diversa.

Gestione utenti e autorizzazioni. Entrambi i sistemi utilizzeranno lo stesso identity provider, tipicamente SAP Identity Authentication Service. Il provisioning degli utenti, l’assegnazione dei ruoli e l’SSO devono essere progettati una volta e funzionare per entrambi i sistemi. Non lasciate che ogni progetto risolva questo in modo indipendente.

Tempistica del change management. I key user non possono seguire la formazione su S/4HANA al mese 7 e la formazione su Sales Cloud V2 al mese 8 senza andare in burnout. Sequenziate deliberatamente i programmi di formazione, con sufficiente respiro tra i go-live, in modo che gli utenti si stabilizzino sul primo sistema prima di imparare il secondo.

I rischi che abbiamo visto — e come evitarli

Due comitati direttivi senza un percorso di escalation condiviso. Il progetto ERP ha il suo steering. Il progetto CX ha il suo. Quando una decisione cross-stream deve essere presa — chi è responsabile del tenant BTP di integrazione? chi finanzia il middleware condiviso? — non esiste un forum per farlo. La decisione rimane in sospeso per settimane. Soluzione: stabilire uno steering di programma condiviso dal giorno uno, anche se si riunisce solo mensilmente.

Perimetro di integrazione definito troppo tardi. Entrambi i progetti assumono che l’altro team gestirà l’integrazione. Sei settimane prima del go-live, nessuno ha iniziato a costruire il flusso ordini da Sales Cloud a S/4HANA. Soluzione: il perimetro dell’integrazione, la responsabilità e il budget devono essere concordati prima che uno dei due progetti entri in fase Realize.

Dati ERP sporchi importati in Sales Cloud. La migrazione dei dati ERP pulisce i record cliente. Ma l’integrazione CRM è costruita sui vecchi dati ERP, non su quelli puliti, perché le tempistiche non sono allineate. Sales Cloud va live con 14.000 account duplicati. Soluzione: la migrazione dei dati CRM deve attingere dallo stato ERP post-pulizia, il che significa sequenzializzare la pulizia dei dati prima del go-live CRM, non in parallelo.

Change fatigue. Gli utenti della finanza assorbono un nuovo ERP. Due mesi dopo, alla stessa organizzazione viene chiesto di adottare un nuovo CRM. L’adozione soffre su entrambi i fronti. Soluzione: sviluppare un piano realistico di capacità di change management prima di approvare la tempistica del programma. Lo stack integrato S/4HANA Public Cloud e Sales Cloud V2 non vale nulla se gli utenti tornano ai fogli di calcolo.

Footprint BTP sottostimato. Entrambi i progetti utilizzeranno BTP — Integration Suite, Identity Authentication, possibilmente Build. Se ogni progetto acquista le proprie istanze BTP, si ottengono tenant duplicati, costi doppi e un’architettura di integrazione che non può condividere componenti. Soluzione: definire la strategia BTP come decisione di programma, non di progetto.

L’integrazione tecnica tra SAP S/4HANA Public Cloud e Sales Cloud V2 è ben documentata e realizzabile. La parte difficile non è la tecnologia. È gestire due grandi programmi di cambiamento nella stessa organizzazione, con le stesse persone, senza che uno comprometta l’altro.

Sequenza corretta, responsabilità chiara sul livello di integrazione e tempo sufficiente perché l’organizzazione assorba ogni sistema prima che arrivi il successivo: è questo che distingue un rollout combinato pulito da un lungo e costoso progetto di recupero.

Volete discutere la sequenza per la vostra situazione specifica? Contattateci — nessun pitch, solo una conversazione.