SAP S/4HANA Public Cloud + SAP Sales Cloud V2: lo stack CX + ERP integrato

S/4HANA Public Cloud e Sales Cloud V2 sono progettati per condividere lo stesso cliente: lo stesso Business Partner, gli stessi prodotti e prezzi, un unico flusso degli ordini. La maggior parte delle aziende DACH che usano SAP ha già un CRM e un ERP; il problema è che i due non concordano su chi sia il cliente.

In sintesi: entrambi i prodotti si basano sul modello Business Partner di SAP, e SAP pubblica contenuti di integrazione standard per Sales Cloud V2 e S/4HANA Cloud Public Edition che girano su SAP Integration Suite. Dati anagrafici, prezzi ed evasione restano nell’ERP; pipeline, attività e casi di servizio vivono in Sales e Service Cloud V2; integrazione ed estensioni stanno su Business AI Platform (BAIP, ex BTP). Ciò che resta da decidere nel vostro progetto è il perimetro: quali campi replicare, in che direzione va ogni flusso, come si monitorano gli errori e chi è responsabile dell’integrazione dopo il go-live.

Questo articolo spiega come funziona l’integrazione, dove vive la logica e come impostare un’implementazione senza trascinare nel nuovo sistema i vecchi problemi di qualità dei dati.

Perché abbinare S/4HANA Public Cloud a Sales Cloud V2?

Perché un venditore che prepara un’offerta e un contabile che registra una fattura dovrebbero guardare lo stesso cliente.

In molti panorami SAP che incontriamo non è così. Il CRM contiene un record cliente con un formato del nome diverso, campi indirizzo diversi e uno stato del credito diverso da quello dell’ERP. Le vendite non sanno della fattura scaduta, l’amministrazione non sa del nuovo contratto appena firmato.

La soluzione classica è un’interfaccia che allinea i campi fra due modelli dati diversi. Funziona, ma è fragile: ogni modifica di schema su uno dei due lati rompe qualcosa, e prima o poi una sola persona mantiene un’interfaccia che nessun altro capisce.

La combinazione di S/4HANA Public Cloud e Sales Cloud V2 riduce questo problema perché entrambi usano il concetto di Business Partner. S/4HANA è il sistema master, Sales Cloud V2 riceve il record replicato, e la mappatura è in gran parte predefinita nel pacchetto di contenuti SAP invece di essere inventata a ogni progetto. Quando un venditore cerca un cliente, vede l’account che l’amministrazione gestisce nell’ERP. Un’integrazione da gestire e monitorare c’è comunque, ma collega due modelli compatibili invece di tradurre fra modelli incompatibili.

Per le aziende DACH che lasciano SAP S/4HANA on-premise o ECC, questo è uno degli argomenti concreti a favore della public cloud: un CRM e un ERP sulle stesse fondamenta.

Qual è il CRM migliore per SAP S/4HANA Public Cloud?

Il CRM migliore per SAP S/4HANA Public Cloud è SAP Sales Cloud V2, perché condivide il modello dati dell’ERP: i record cliente seguono il concetto di Business Partner su entrambi i lati, prodotti e prezzi arrivano da S/4HANA nell’offerta e SAP fornisce contenuti di integrazione standard per il passaggio degli ordini. Ogni CRM ha bisogno di uno strato di integrazione verso l’ERP; con Sales Cloud V2 gran parte è predefinita e segue il ciclo di rilascio di un solo fornitore, con Salesforce o Dynamics lo progettate, mappate e mantenete voi, in modo permanente.

Quando un CRM di terzi ha ancora senso

Un buon consiglio include anche i casi in cui la risposta è diversa. Se Salesforce gira già in più divisioni, con configurazioni mature, integrazioni AppExchange attive e un proprio team di amministratori, cambiare per un progetto S/4HANA è probabilmente la scelta sbagliata. Lo stesso vale quando un lavoro di analisi importante poggia sul modello dati del CRM (oggetti personalizzati, modelli Einstein, flussi verso un data warehouse) o quando i vostri requisiti vanno ben oltre la vendita B2B, verso la gestione dei partner o funzioni di settore dove quell’ecosistema ha un vantaggio. Il confronto non è mai solo tecnico: dipende da dove venite e da quanto i vostri team vogliono cambiare.

Un solo modello dati cliente, non due

Il modello Business Partner è la spina dorsale di entrambi i sistemi. In S/4HANA Public Cloud ogni cliente viene creato come Business Partner. Sales Cloud V2 riceve quel record tramite SAP Integration Suite, quindi i dati dell’account in Sales Cloud riflettono ciò che S/4HANA contiene: ragione sociale, indirizzi, condizioni di pagamento e, se li includete nel perimetro, informazioni su credito e solleciti.

Per le vendite cambia la conversazione con il cliente. Chi apre un account in SAP Sales Cloud V2 vede il quadro finanziario: partite aperte, esposizione creditizia, storico ordini. Non serve chiamare l’amministrazione per sapere se un’opportunità è a rischio.

Per il servizio, lo stesso modello significa che i casi in SAP Service Cloud V2 sono legati alla stessa entità cliente che vive nell’ERP. Nessuna ricerca separata, nessun «di quale sistema mi fido?».

La sincronizzazione è una decisione di progettazione, non un automatismo. I record Business Partner sono gestiti in S/4HANA come sistema master e le modifiche arrivano in Sales Cloud V2 tramite eventi di integrazione. I nuovi clienti creati in Sales Cloud V2 durante l’acquisizione possono tornare in S/4HANA per l’apertura in ERP. La direzione di ogni flusso e la mappatura dei campi si decidono durante l’implementazione, non si scoprono dopo il go-live.

Il ciclo offerta, ordine, fattura

È qui che l’integrazione ripaga in modo più visibile per le vendite.

Un venditore prepara un’offerta in Sales Cloud V2. Prodotti e prezzi arrivano da S/4HANA; se usate SAP CPQ, configurazione e logica di prezzo girano lì. Il cliente riceve un’offerta basata su prezzi reali, non su un foglio di calcolo tenuto a parte. Il nostro articolo sul quote-to-cash fra Sales Cloud V2 e S/4HANA Public Cloud ripercorre il flusso passo per passo.

Quando il cliente accetta, l’ordine passa a S/4HANA per l’evasione invece di essere inviato per e-mail a un team interno che lo inserisce a mano. Il magazzino prepara, la logistica spedisce, l’amministrazione fattura.

Lo stato di consegna e di fattura (registrata, pagata, scaduta) torna nella vista dell’account in Sales Cloud. Il venditore vede se l’ordine del mese scorso è stato pagato senza aprire un portale finanziario, e il servizio vede lo stato di consegna senza chiamare il magazzino.

Quel ciclo, dall’offerta all’ordine alla fattura, visibile in Sales Cloud, è ciò che «CRM ed ERP integrati» significa in pratica: un flusso in cui i dati si muovono senza reinserimenti manuali.

Clean core: dove vive la logica di integrazione

Qui conta il principio clean core di SAP. L’obiettivo è tenere le personalizzazioni fuori dal core di S/4HANA e portare la logica di integrazione ed estensione sulla SAP Business AI Platform.

Per un’integrazione fra Sales Cloud e S/4HANA significa:

• API standard rilasciate su entrambi i lati (OData, SOAP, eventi), documentate nel SAP Business Accelerator Hub
• Flussi di integrazione in SAP Integration Suite su BAIP
• I pacchetti di contenuti predefiniti di SAP come punto di partenza per gli scenari standard
• Logica propria (regole di prezzo, workflow di approvazione, mappature speciali) in estensioni BAIP o SAP Build, non in modifiche di S/4HANA

Il vantaggio è concreto. SAP aggiorna S/4HANA Public Cloud per tutti i clienti secondo un calendario di rilasci fisso, e un’integrazione basata su API rilasciate ed estensioni side-by-side è pensata per superare questi aggiornamenti. È la logica che dipende da oggetti non rilasciati a trasformare ogni aggiornamento in una campagna di test di regressione.

Cosa resta in S/4HANA, in Sales Cloud V2 e su BAIP

Responsabilità	Dove vive
Dati anagrafici cliente (Business Partner)	S/4HANA Public Cloud
Catalogo prodotti, condizioni di prezzo	S/4HANA Public Cloud
Gestione ordini, evasione, fatturazione	S/4HANA Public Cloud
Gestione opportunità, pipeline, previsioni	Sales Cloud V2
Interazioni cliente, attività, rapporti di visita	Sales Cloud V2
Casi di servizio, SLA, escalation	Service Cloud V2
Flussi di integrazione, eventi, gestione errori	BAIP Integration Suite
Estensioni, app personalizzate, funzioni AI	BAIP (side-by-side)

Ci sono casi limite, ma come modello di partenza è più pulito della maggior parte dei panorami che ereditiamo. La guida all’architettura di integrazione approfondisce i pattern dal punto di vista tecnico.

Come si presenta nei progetti Spadoom

La situazione prima di un progetto si ripete: le vendite gestiscono i dati cliente in un CRM allineato solo in parte con SAP, l’amministrazione ha il record cliente di riferimento ma le vendite non lo vedono, l’inserimento ordini è manuale, e le vendite scoprono un blocco del credito quando il cliente si lamenta.

Dopo il progetto, la vista account in Sales Cloud mostra partite aperte e storico ordini dall’ERP, le offerte si basano su prezzi reali e gli ordini arrivano senza reinserimento.

Tre progetti pubblicati mostrano parti diverse di questo quadro:

• Presso intelligentfood, Spadoom ha realizzato Sales Cloud V2, l’integrazione con il Cloud ERP e lavori in parti di MM e SD. La piattaforma Sales & Service è andata in produzione in tre mesi (il dato si riferisce a quella piattaforma, non all’intera implementazione ERP).
• Presso Nussbaum Matzingen, produttore di imballaggi, Sales Cloud V2 ha sostituito fogli Excel e cartelle Outlook con un’unica piattaforma di vendita in cinque mesi e ha dato alla direzione piena trasparenza sulla pipeline, con SAP ECC come backend.
• Presso Miltenyi Biotec, abbiamo collegato Commerce Cloud, marketing, Customer Data Cloud, S/4HANA e Service Cloud V2 tramite SAP Integration Suite, così il servizio lavora sugli stessi dati cliente del resto del panorama.

Niente di spettacolare. È ciò che l’integrazione fra CRM ed ERP deve fare, e funziona quando il modello dati è condiviso fin dall’inizio.

In che ordine affrontare i due progetti

L’errore più comune è gestire CRM ed ERP come progetti paralleli e indipendenti che dovrebbero «collegarsi dopo». Lo fanno di rado, oppure solo in superficie, e il debito di integrazione cresce.

La sequenza migliore:

1. Progettare prima il modello dati condiviso. Prima di qualsiasi configurazione, concordare com’è fatto un Business Partner, come sono strutturati account e contatti e dove si gestiscono i dati anagrafici. È una decisione di business, non tecnica.
2. Avviare S/4HANA per primo o in parallelo a Sales Cloud, non dopo. Se Sales Cloud va in produzione con un’integrazione provvisoria verso il vecchio ERP, quell’integrazione andrà rifatta al go-live di S/4HANA.
3. Definire gli scenari di integrazione prima del go-live. Offerta-ordine, visibilità delle fatture e allineamento dell’anagrafica clienti si configurano e testano in un ambiente di integrazione dedicato; non si aggiungono alla fine.
4. Testare l’integrazione in sistemi reali prima del go-live. All’inizio il lato S/4HANA si può simulare, ma i flussi vanno testati end-to-end prima che passi il primo ordine reale.

Le varianti di sequenza e i relativi compromessi sono descritti nella nostra guida per introdurre insieme S/4HANA Public Cloud e Sales Cloud V2. Se state ancora scegliendo chi realizzarlo, la nostra guida al miglior partner SAP per Cloud ERP e CRM in Svizzera spiega perché conta avere un solo team per le due metà.

---

La maggior parte delle aziende è a metà strada: uno o entrambi i sistemi in uso, ma non del tutto collegati. L’assessment di readiness S/4HANA di cinque giorni fornisce perimetro, sequenza e forchetta di costo per entrambe le metà prima di impegnarvi, come primo passo di una trasformazione ERP e CX. Oppure parliamo della vostra configurazione.

Potrebbero interessarvi anche:

• Cosa copre S/4HANA Public Cloud nativamente e cosa richiede Sales/Service Cloud V2
• S/4HANA Public Cloud + Sales Cloud V2 vs Salesforce
• SAP S/4HANA Public Cloud: panoramica della soluzione