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

Implementiamo SAP Sales Cloud V2 dalla early availability, e per gran parte di quel tempo la conversazione sull’analytics finiva sempre allo stesso modo: export verso un warehouse che qualcuno mantiene, oppure accontentarsi delle dashboard integrate. SAP Business Data Cloud cambia quella conversazione, e dopo diversi setup in produzione possiamo dire quali pattern di integrazione reggono e quali fanno più bella figura sulla lavagna che al sesto mese.

Il riassunto in una frase: consumate i data product di SAP per il modello standard, spendete il vostro sforzo solo sull’ultimo miglio: i vostri KPI, i vostri campi di estensione, i vostri join.

Pattern 1: prima i data product, mai gli estrattori

Il riflesso di un decennio di CRM analytics è costruire una pipeline di estrazione. Resistete. SAP fornisce in BDC i data product di Sales Cloud V2 (account, opportunità, lead, attività) e li mantiene attraverso le release trimestrali. Ogni estrattore che costruite in parallelo a un data product è una passività con il vostro nome sopra: si rompe in silenzio quando l’API cambia, e reintroduce la deriva semantica (“quale importo dell’opportunità è quello?”) che il data product esiste per chiudere.

Dove invece costruite: i campi di estensione. Se il vostro Sales Cloud V2 porta campi custom (tipo di macchina, fase di progetto, dati di configurazione AVC), pianificate un passo di modellazione che li porti nel livello semantico. Su un tenant pulito sono ore di lavoro, non settimane.

Pattern 2: pipeline-to-cash come primo modello

Tutti i clienti lo chiedono; quasi nessuno ce l’ha. Le opportunità vivono nel CRM, ordini e fatture nell’ERP, e il join fra loro è un esercizio Excel trimestrale. Con i data product di Sales Cloud V2 e S/4HANA in un unico tenant BDC, il pipeline-to-cash diventa un compito di modellazione invece che un progetto di integrazione:

• Chiavi di join: account ↔ business partner, opportunità ↔ riferimento all’ordine di vendita, materiale ↔ prodotto. Un workshop per allinearle, soprattutto se la deduplicazione degli account ha una storia nel vostro CRM.
• Il modello: opportunità vinte contro ingresso ordini effettivo e ricavi fatturati, per organizzazione commerciale e periodo.
• Il ritorno: accuratezza del forecast misurata contro la realtà spedita: il numero che trasforma la disciplina CRM da desiderio del management a KPI misurato.

Un costruttore di macchine svizzero con cui lavoriamo ha eseguito esattamente questo modello come pilota BDC: un dominio, sei settimane, e la prima riunione di management in cui vendite e finanza hanno portato lo stesso numero.

Pattern 3: tenete il real-time fuori dal livello analytics

L’errore di design più comune: instradare bisogni operativi real-time attraverso la piattaforma analytics. Un venditore che ha bisogno di stock e prezzi live prima di un’offerta li ottiene dall’integrazione applicativa nativa Sales Cloud V2 ↔ S/4HANA, non da BDC. L’analytics tollera i cicli di refresh; l’offerta no. Tracciate la linea esplicitamente nell’architettura: transazioni attraverso le API applicative, analisi attraverso i data product. Le architetture che la sfumano ereditano le proprietà peggiori di entrambi.

Pattern 4: un modello semantico, molti consumatori

Una volta che la fondazione sta in piedi, resistete alle varianti per team. Il punto è proprio che la dashboard SAC per il management, il notebook Databricks per l’analista curioso dei dati e l’agente Joule che risponde a “come va la pipeline del Q4 rispetto all’anno scorso” leggano lo stesso modello governato. Nel momento in cui qualcuno crea la “sua” versione dei ricavi, state ricostruendo il problema che avete pagato per eliminare. La governance qui non è burocrazia; è il prodotto.

Dove si va da qui

Abbiamo iniziato questa serie con che cos’è davvero BDC e cosa succede a Datasphere. I pattern di integrazione qui sopra sono il centro pratico. Il finale strategico (perché tutto questo conta oltre il reporting) è l’AI: gli agenti valgono quanto il modello dati che leggono, e un modello pipeline-to-cash governato è esattamente ciò di cui un agente Joule ha bisogno per rispondere a domande sui ricavi senza avere allucinazioni. Ne parleremo più avanti nella serie.

Se usate Sales Cloud V2 e la vostra analytics vive ancora negli export, questa è una soluzione da settimane, non da trimestri. La nostra practice BDC parte esattamente da lì.