Collegare SAP Sales Cloud V2 con Business Data Cloud: i pattern di integrazione che funzionano

Implementiamo SAP Sales Cloud V2 e SAP S/4HANA Public Cloud con un unico team, e per molto tempo la discussione sulle analisi del CRM finiva in uno di due modi: esportazione verso un data warehouse che qualcuno manutiene, oppure accontentarsi delle dashboard integrate. SAP Business Data Cloud (BDC) apre una terza strada. Questo articolo raccoglie i pattern di progettazione che applichiamo quando i dati di Sales Cloud V2 incontrano i dati ERP in BDC, e gli errori da cui mettiamo in guardia i clienti.

In sintesi: utilizzate i data product SAP ovunque esistano e verificate il catalogo della vostra release prima di costruire qualcosa. Dove i dati di Sales Cloud V2 non sono ancora disponibili come data product, caricateli una sola volta in Datasphere e governateli come data product proprio. Fate del pipeline-to-cash il primo modello, allineate presto tre chiavi di collegamento, lasciate le esigenze in tempo reale nell’integrazione applicativa e fate leggere a tutti i consumatori lo stesso modello semantico.

Con che cosa lavora BDC

SAP ha annunciato Business Data Cloud nel febbraio 2025. L’offerta riunisce SAP Datasphere, SAP Analytics Cloud, SAP Business Warehouse e SAP Databricks in un servizio gestito (SAP Learning: Introducing SAP Business Data Cloud). L’elemento centrale è il data product, che SAP descrive come un set di dati raffinato, con metadati che lo descrivono e una porta di accesso o un’API (SAP News, ottobre 2025). Sui data product SAP costruisce le applicazioni intelligenti (in precedenza chiamate insight app); un’applicazione di Revenue Intelligence era in anteprima ristretta a ottobre 2025.

Per chi progetta un CRM questo significa due cose. Primo, una parte dei dati necessari arriva già modellata e mantenuta da SAP. Secondo, il resto va ancora caricato e modellato, e la qualità di questo lavoro decide se la piattaforma ripaga. Come si attivano e si consumano i data product gestiti da SAP è documentato in SAP Help.

I pattern in sintesi

Pattern	Da usare per	Da evitare per
1. Prima i data product	Entità standard che SAP fornisce per la vostra release	Ricostruire dati che SAP mantiene per voi
2. Pipeline-to-cash come primo modello	Vendite e finanza con numeri diversi	Partire con cinque domini insieme
3. Il tempo reale resta nel livello applicativo	Offerte, disponibilità, prezzi al momento della vendita	Dashboard che vogliono dati live «per sicurezza»
4. Un modello semantico, molti consumatori	Storie SAC, notebook Databricks, Joule	Copie di «fatturato» per ogni team

Pattern 1: prima i data product, poi il vostro data product

Il riflesso di dieci anni di analisi CRM è costruire una pipeline di estrazione. Cominciate un passo prima: aprite il catalogo dei data product della vostra release e verificate quali entità fornisce SAP. Gli esempi citati da SAP al lancio erano dati di S/4HANA, SAP Ariba e SuccessFactors, quindi non date per scontato che ogni oggetto di Sales Cloud V2 sia già disponibile. Ogni estrattore costruito accanto a un data product esistente è un debito con il vostro nome sopra: si rompe quando cambia un’API e riporta la domanda «quale importo dell’opportunità è questo?».

Dove non esiste un data product SAP per le entità CRM che vi servono (account, opportunità, attività), caricatele una volta sola e in modo deliberato:

• Percorso di caricamento: le API di Sales Cloud V2 o un flusso di replica verso SAP Datasphere, uno space per i dati CRM, nessuna copia parallela.
• Trattarlo come un prodotto: un responsabile, una definizione documentata per ogni indicatore, una frequenza di aggiornamento concordata con il business.
• Pianificare l’uscita: quando SAP rilascia un data product equivalente, spostate i consumatori su di esso e dismettete il vostro flusso. Date ai flussi nomi tali che questo passaggio sia una checklist, non un’indagine.

I campi di estensione richiedono un passo a sé. Se la vostra Sales Cloud V2 contiene campi personalizzati, per esempio tipo di macchina, fase di progetto o dati di configurazione AVC, pianificate come ciascuno arriva nel livello semantico e chi ne è responsabile. Su un tenant pulito sono ore di modellazione per gruppo di campi, non settimane.

Pattern 2: il pipeline-to-cash come primo modello

Ogni cliente lo chiede; pochi lo hanno. Le opportunità stanno nel CRM, ordini e fatture nell’ERP, e il collegamento tra i due è un esercizio trimestrale in Excel. Con i dati CRM e S/4HANA in un unico tenant BDC, il pipeline-to-cash diventa un compito di modellazione invece di un progetto di integrazione.

Sono le chiavi di collegamento a decidere se funziona:

• Account e business partner. Nello stack integrato gli account di Sales Cloud V2 vengono replicati da o verso i business partner di S/4HANA, quindi la chiave di solito esiste. Prima di modellare, controllate i duplicati e gli account creati solo nel CRM.
• Opportunità e ordine di vendita. Il collegamento esiste solo se il processo lo crea: un’offerta o un ordine generato dall’opportunità porta con sé il riferimento. Gli ordini inseriti direttamente nell’ERP richiedono una regola di assegnazione, altrimenti restano fuori dal funnel.
• Prodotto e materiale. L’anagrafica prodotti dovrebbe provenire da S/4HANA. I prodotti a testo libero nelle opportunità non si possono collegare in seguito.

Il modello in sé resta semplice: opportunità vinte confrontate con ordini acquisiti e fatturato, per organizzazione commerciale, gruppo di prodotti e periodo. Il risultato è l’accuratezza del forecast misurata su quanto è stato effettivamente consegnato, il numero che trasforma la disciplina nel CRM da desiderio del management a indicatore. L’architettura di integrazione tra Sales Cloud V2 e S/4HANA Public Cloud descrive dove queste chiavi nascono sul lato transazionale.

Pattern 3: il tempo reale resta fuori dal livello analitico

L’errore di progettazione più frequente che incontriamo è far passare esigenze operative in tempo reale attraverso la piattaforma analitica. Un venditore che ha bisogno di disponibilità e prezzi aggiornati prima di un’offerta li ottiene dall’integrazione applicativa tra Sales Cloud V2 e S/4HANA, non da BDC. Le analisi tollerano i cicli di aggiornamento; le offerte no.

Tracciate la linea in modo esplicito nel documento di architettura: transazioni tramite API applicative, analisi tramite data product. Le architetture che confondono i due piani ereditano i difetti di entrambi, offerte lente e dashboard fragili.

Pattern 4: un modello semantico, molti consumatori

Una volta costruita la base, resistete alle varianti per team. La storia SAC per il management, il notebook Databricks dell’analista e un agente Joule che risponde a «come va la pipeline del Q4 rispetto all’anno scorso?» dovrebbero leggere lo stesso modello governato. Nel momento in cui qualcuno crea la propria versione del fatturato, state ricostruendo il problema che avete pagato per eliminare. Qui la governance è il prodotto stesso: una definizione per indicatore, un responsabile per dominio, richieste di modifica attraverso quel responsabile.

È anche il punto in cui la qualità dei dati inizia a contare più degli strumenti. Account duplicati e opportunità orfane finiscono direttamente in ogni consumatore. La sequenza di correzione è descritta in perché i dati del vostro CRM valgono quanto la vostra fondazione dati.

Dove si colloca

Questa serie è iniziata con che cos’è BDC e che cosa succede a Datasphere. I pattern qui sopra sono la parte pratica intermedia. La ragione strategica è l’AI: gli agenti valgono quanto il modello che leggono, e un modello pipeline-to-cash governato è ciò che serve a un agente Joule per rispondere a domande sul fatturato con la stessa provenienza di un report.

Analisi CRM ed ERP su un’unica base riescono più facilmente quando un solo team conosce entrambi i lati del punto di contatto. È così che lavoriamo, si veda perché ERP e CRM da un unico partner fanno la differenza. Se utilizzate Sales Cloud V2 e le vostre analisi vivono ancora di esportazioni, la nostra pratica BDC parte esattamente da questo primo modello.

Domande frequenti

Esistono data product nativi di Sales Cloud V2 in BDC?

Verificate il catalogo dei data product per la vostra release prima di progettare qualsiasi cosa. Dove SAP fornisce un data product per le entità che vi servono, utilizzatelo. Dove non esiste, portate i dati di Sales Cloud V2 una sola volta in Datasphere tramite le API o un flusso di replica, modellateli come data product proprio e governato e sostituitelo quando SAP ne rilascia uno equivalente.

Posso combinare dati di Sales Cloud V2 e S/4HANA in un unico modello BDC?

Sì, ed è proprio lo scopo dell’esercizio. Le opportunità vinte in Sales Cloud V2 vengono unite a ordini di vendita, fatture e margini di S/4HANA in un unico modello semantico, ottenendo un reporting pipeline-to-cash senza sviluppare un middleware dedicato. Le chiavi di collegamento (account e business partner, opportunità e ordine di vendita, prodotto e materiale) richiedono un workshop di allineamento; dopo reggono.

E i requisiti in tempo reale?

Teneteli fuori dal livello analitico. Le analisi su pipeline e fatturato funzionano con cicli di aggiornamento. Un venditore che ha bisogno di disponibilità o prezzi aggiornati prima di un’offerta li ottiene dall’integrazione applicativa tra Sales Cloud V2 e S/4HANA, non da BDC. Mescolare le due esigenze in un’unica architettura è l’errore di progettazione più frequente che vediamo.

Come arrivano in BDC i campi di estensione personalizzati di Sales Cloud V2?

Vanno pianificati esplicitamente. Campi di estensione come tipo di macchina o fase di progetto non fanno parte di alcun modello standard, quindi ciascuno richiede una mappatura nel livello semantico e un responsabile designato. Su un tenant pulito si tratta di ore di modellazione per gruppo di campi, non di un progetto a sé.