SAP S/4HANA Public Cloud + SAP Sales Cloud V2: Lo Stack CX + ERP Integrato

Non servono due sistemi CRM e due ERP. La maggior parte delle aziende DACH che usano SAP ha già entrambi — semplicemente non quelli giusti connessi tra loro.

SAP S/4HANA Public Cloud e SAP Sales Cloud V2 sono progettati per lavorare insieme. Non come soluzioni puntuali debolmente accoppiate, ma come piattaforma dati condivisa in cui un singolo record cliente, un catalogo prodotti e un flusso d’ordine attraversano entrambi i sistemi senza duplicazioni.

Questo articolo spiega come funziona concretamente questa integrazione, dove risiede la logica e come sequenziare un’implementazione per non ritrovarsi con gli stessi problemi di qualità dei dati di prima — solo su un sistema più recente.

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

La risposta breve: perché un commerciale che crea un preventivo e un contabile che registra una fattura dovrebbero guardare lo stesso cliente.

Nella maggior parte dei landscape SAP che incontriamo, non è così. Il CRM ha un record cliente con un formato di nome diverso, campi indirizzo diversi, stato del credito diverso rispetto al record ERP. Il commerciale non sa che il cliente ha una fattura scaduta. La contabilità non sa che il cliente ha appena firmato un nuovo contratto.

La soluzione tradizionale è un’integrazione che sincronizza i campi tra due modelli di dati diversi. Funziona, ma è fragile. Ogni modifica di schema su uno dei due lati rompe qualcosa. Si finisce con una persona dedicata a manutenere un’integrazione che nessuno capisce fino in fondo.

La combinazione di S/4HANA Public Cloud e Sales Cloud V2 evita questo perché entrambi condividono il modello Business Partner. Stessa entità, stesso ID, stessa struttura. Sales Cloud consuma i dati master da S/4HANA. Quando un commerciale cerca un cliente, vede lo stesso account che il team finance ha nell’ERP. Nessuna logica di sincronizzazione. Nessun mapping. Un’unica fonte di verità.

Per le aziende DACH che si spostano da SAP S/4HANA on-premise o ECC, questo è uno dei veri argomenti a favore della via public cloud: si ottiene un CRM moderno e un ERP moderno che condividono effettivamente la stessa base — non due sistemi tenuti insieme con middleware.

Un 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 consuma quel record tramite SAP Integration Suite. Il risultato: i dati dell’account in Sales Cloud riflettono ciò che S/4HANA contiene — ragione sociale, indirizzo, termini di pagamento, limite di credito, stato dei solleciti.

Per i commerciali, questo cambia la conversazione con il cliente. Quando un agente apre un account in Sales Cloud V2, vede il quadro finanziario: fatture aperte, esposizione creditizia, storico dei pagamenti. Non deve chiamare la finanza per sapere se un’offerta potrebbe essere bloccata da un blocco del credito. L’informazione è già lì.

Per i team di servizio, lo stesso modello significa che i ticket di assistenza in SAP Service Cloud V2 sono collegati alla stessa entità cliente che esiste nell’ERP. Nessuna ricerca separata. Nessun «a quale sistema mi fido?».

La sincronizzazione non è magia. I record Business Partner vengono mantenuti in S/4HANA come sistema master. Le modifiche fluiscono a valle verso Sales Cloud V2 tramite eventi di integrazione. I nuovi clienti creati in Sales Cloud V2 durante un processo di acquisizione possono fluire indietro a S/4HANA per l’inserimento nell’ERP. La direzione del flusso e il mapping dei campi sono decisioni che prendete al momento dell’implementazione — non assunzioni fatte dopo il go-live.

Il ciclo dal preventivo all’ordine alla fattura

Qui l’integrazione ripaga in modo più visibile per i team di vendita.

Un agente crea un preventivo in SAP Sales Cloud V2. Il catalogo prodotti arriva da S/4HANA — prezzi, sconti, configurazioni disponibili. Se usate CPQ, la logica di pricing gira lì e passa l’output a Sales Cloud. Il cliente vede un preventivo basato su dati di prezzo reali provenienti dall’ERP, non un foglio Excel che l’agente aggiorna separatamente.

Quando il cliente accetta, l’ordine viene attivato. Invece che l’agente invii l’ordine via e-mail a un team interno che lo inserisce manualmente in SAP, l’ordine fluisce direttamente in S/4HANA per l’evasione. Il magazzino preleva. La logistica spedisce. La finanza fattura.

Lo stato della fattura — emessa, pagata, scaduta — ritorna nella vista a 360° in Sales Cloud. Il commerciale può vedere se l’ordine del mese scorso è stato pagato senza aprire un portale finance. Il servizio vede lo stato della consegna senza chiamare il magazzino.

Quel ciclo — dal preventivo all’ordine alla fattura, tutto visibile in Sales Cloud — è quello che «CRM ed ERP integrati» significa nella pratica. Non due sistemi con una freccia tra loro su una presentazione. Un flusso reale in cui i dati si muovono senza inserimento manuale.

Clean core: dove risiede effettivamente la logica di integrazione

Il principio del clean core di SAP è rilevante qui. L’obiettivo è mantenere le personalizzazioni fuori dal core di S/4HANA e spostare la logica di integrazione ed estensione sulla SAP Business Technology Platform.

In pratica, per un’integrazione tra Sales Cloud e S/4HANA, questo significa:

• API standard su entrambi i lati (OData, SOAP, Event Mesh)
• Flussi di integrazione costruiti in SAP Integration Suite su BTP
• Pacchetti di contenuto preconfigurati da SAP per gli scenari standard
• Logica personalizzata (regole di pricing, flussi di approvazione, mapping di campi) in estensioni BTP o SAP Build — non in modifiche al core di S/4HANA

Il vantaggio non è solo filosofico. Quando SAP rilascia una nuova versione di S/4HANA Public Cloud (il che avviene trimestralmente), un’integrazione clean core supera l’upgrade intatta. Un core pesantemente modificato no. Le aziende che hanno personalizzato direttamente in S/4HANA trascorrono settimane a ogni upgrade a verificare che nulla si sia rotto. Le aziende con clean core impiegano ore.

Cosa resta in S/4HANA vs Sales Cloud V2 vs BTP

Non è una dottrina rigida — ci sono casi limite. Ma come modello di partenza, è più pulito della maggior parte dei landscape che ereditiamo.

Come appare in un progetto Spadoom reale

Abbiamo aiutato aziende manifatturiere e distributive di medie dimensioni nel DACH a connettere i loro stack CRM ed ERP. Il pattern è costante.

Prima del progetto: i commerciali gestiscono i dati cliente in un CRM debolmente sincronizzato con SAP. La finanza ha il record cliente autorevole ma il commerciale non può vederlo. L’inserimento degli ordini è manuale — l’agente manda un’e-mail, un assistente lo inserisce. Lo stato della fattura è sconosciuto al team di vendita finché un cliente non protesta per un blocco del credito.

Dopo il progetto: la vista account in Sales Cloud mostra stato del credito, fatture aperte e storico degli ordini da S/4HANA. I preventivi sono costruiti su prezzi reali dall’ERP. Gli ordini fluiscono senza reinserimento. La visibilità della pipeline in Sales Cloud riflette ciò che accade realmente nell’evasione.

Nussbaum ha ottenuto esattamente questo tipo di visibilità della pipeline — sapere dove si trovavano le trattative rispetto alla realtà finanziaria, invece di gestirlo su strumenti non connessi.

Per Miltenyi, un’implementazione combinata di vendite e servizi ha fatto sì che i team che condividevano account cliente vedessero gli stessi dati. I ticket di assistenza alimentavano il quadro commerciale. Il contesto di vendita aiutava il servizio a stabilire le priorità.

Non sono trasformazioni spettacolari. È quello che l’integrazione CRM-ERP dovrebbe fare. Funziona quando il modello dati è condiviso fin dall’inizio — ed è per questo che la combinazione di S/4HANA Public Cloud e Sales Cloud V2 vale il lavoro di progettazione iniziale.

Come sequenziare i due progetti

L’errore più comune è gestire CRM ed ERP come progetti paralleli e indipendenti che si «connetteranno in seguito». Raramente lo fanno. O si connettono superficialmente, e i debiti di integrazione si accumulano.

La sequenza migliore:

1. Definire prima il modello dati condiviso. Prima di qualsiasi configurazione di sistema, concordate come appare un Business Partner, come sono strutturati account e contatti e dove vengono gestiti i dati master. È una decisione di business, non tecnica.
2. Avviare S/4HANA prima, o in parallelo con Sales Cloud — non dopo. Se Sales Cloud va live con un’integrazione temporanea al vostro vecchio ERP, trascorrerete il go-live di S/4HANA a fare pulizia. È più semplice farlo bene una volta sola.
3. Definire gli scenari di integrazione prima del go-live, non durante. Dal preventivo all’ordine, visibilità delle fatture, sincronizzazione dei dati master cliente — vanno configurati e testati in un ambiente di integrazione dedicato. Non possono essere aggiunti all’ultimo momento.
4. Far girare l’integrazione in produzione prima del go-live. Simulate il lato S/4HANA se necessario. Ma i flussi di integrazione devono essere testati su sistemi reali prima che il primo ordine reale li attraversi.

Per maggiori dettagli sulla logica di sequenziamento e sulle fasi di implementazione, consultate il nostro articolo dedicato su come implementare S/4HANA Public Cloud e Sales Cloud V2 insieme.

L’integrazione tra S/4HANA Public Cloud e Sales Cloud V2 è uno degli argomenti più discussi nelle nostre conversazioni con i clienti in questo momento. La maggior parte delle aziende è a metà strada — gestisce uno o entrambi i sistemi, ma non completamente connessi. Se state pianificando come arrivarci, parliamo del vostro setup specifico.

Potrebbe interessarvi anche:

• Il miglior CRM per S/4HANA Public Cloud
• S/4HANA Public Cloud + Sales Cloud V2: Architettura di integrazione
• S/4HANA Public Cloud vs Salesforce
• SAP S/4HANA Public Cloud: panoramica della soluzione
• SAP Service Cloud V2