BDC e Datasphere: cosa cambia, cosa resta

Quando SAP ha integrato Datasphere in Business Data Cloud, i clienti con un tenant Datasphere attivo ponevano sempre la stessa prima domanda: che fine fa ciò che abbiamo costruito? La risposta breve è rassicurante. Più utile è la seconda parte: che cosa smettere di costruire.

In sintesi: l’investimento in Datasphere resta: spazi, modelli, flussi e competenze si conservano, e SAP Analytics Cloud e SAP BW diventano componenti della stessa piattaforma. Cambiano la confezione (un solo contratto BDC in capacity unit), i data product gestiti da SAP che sostituiscono la replica costruita in proprio per i dati SAP standard, SAP Databricks per il machine learning all’interno della governance SAP e la gestione dei dati anagrafici, che entra in BDC. Smettete di costruire flussi per dati che SAP già fornisce e fate coincidere la conversione delle licenze con il prossimo rinnovo.

Cosa resta

Datasphere non scompare. Resta il livello di integrazione e di modellazione semantica dentro BDC; l’introduzione di SAP a Business Data Cloud lo elenca tra i componenti centrali:

• Spazi e modelli si conservano. Modelli semantici, viste e flussi di dati continuano a funzionare. BDC li utilizza invece di sostituirli. La documentazione di SAP Datasphere resta il riferimento per il livello di modellazione.
• SAP Analytics Cloud resta come livello di visualizzazione e pianificazione, ora parte del bundle invece di un contratto separato.
• SAP BW resta raggiungibile. BW e la BW private cloud edition sono componenti di BDC, quindi i modelli di data warehouse esistenti non vanno ricostruiti dal primo giorno.
• Le competenze restano preziose. Chi sa modellare in Datasphere è chi collegherà in BDC i data product alle domande di business.

Chi negli ultimi anni ha investito in Datasphere non ha sprecato nulla. Si tratta di un’evoluzione della confezione attorno a un nucleo che resta, non di una sostituzione di piattaforma come quelle che i clienti SAP hanno già vissuto (il passaggio da Sales Cloud V1 a V2 è stato una vera ricostruzione; questo non lo è).

Cosa cambia

Quattro cose sono davvero diverse.

1. Confezione e licenze. Un solo contratto BDC copre Datasphere, SAP Analytics Cloud, SAP BW e SAP Databricks. SAP concede BDC in licenza sulla base di capacity unit; la conversione di un contratto standalone di Datasphere o SAC dipende dal vostro contratto.
2. I data product sostituiscono l’estrazione costruita in proprio. Un data product è «un set di dati raffinato, i metadati che lo descrivono e una porta di accesso o un’API» (SAP News). Dove SAP ne fornisce uno (la prima ondata si è concentrata su S/4HANA, SAP Ariba e SAP SuccessFactors), il flusso di replica che il vostro team ha costruito per gli stessi dati diventa un’eredità del passato. SAP mantiene il data product a ogni release; il vostro flusso lo mantenete solo voi. Per i dati CX come Sales Cloud V2 verificate il catalogo della vostra release e mantenete la replica in Datasphere dove un data product non esiste ancora.
3. Il machine learning entra nel recinto. I carichi di lavoro che prima richiedevano di copiare i dati SAP su una piattaforma di ML separata possono girare in SAP Databricks sotto la stessa governance, e BDC Connect condivide i data product senza copia con una piattaforma Databricks, Snowflake o di altri partner già esistente. Con la nLPD svizzera e il GDPR, «i dati non hanno mai lasciato la governance SAP» è una frase che il vostro responsabile della protezione dei dati apprezzerà.
4. La gestione dei dati anagrafici entra in BDC. Nel maggio 2026 SAP ha reso SAP Master Data Governance e SAP HANA Cloud componenti centrali di BDC e ha completato l’acquisizione di Reltio, la cui gestione dei dati anagrafici multi-dominio sta portando in BDC (SAP News). La qualità dei dati anagrafici di clienti e prodotti, a lungo un progetto a sé, diventa parte della stessa piattaforma.

Cosa smettere di costruire

In concreto, da oggi:

• Niente nuovi flussi di replica per dati che SAP fornisce come data product. Verificate prima il catalogo e costruite solo per le lacune.
• Niente più modellazione da zero delle entità generiche. Cliente, ordine di vendita e fattura arrivano modellati semanticamente dove esiste un data product. Il vostro sforzo di modellazione va nell’ultimo miglio: logica di settore, KPI, campi di estensione.
• Niente più copie dei dati SAP per il machine learning quando SAP Databricks o una condivisione senza copia possono svolgere il compito dentro il perimetro di governance.
• Niente più analisi S/4HANA e CX come progetti separati. Nello stack integrato un’unica base serve entrambi. Separarli ricrea il problema dei numeri discordanti che BDC deve eliminare. Come si aggiunge il lato CRM lo mostrano i modelli di integrazione tra Sales Cloud V2 e BDC.

Una breve checklist di migrazione

Passo	Cosa verificare	Risultato
1. Inventario	Spazi, modelli, flussi di replica e query BW in uso	Elenco degli oggetti con responsabile e utilizzo
2. Confronto con il catalogo	Quali flussi duplicano un data product SAP della vostra release	Flussi da dismettere, flussi da mantenere
3. Contratto	Date di rinnovo di Datasphere e SAC, consumo effettivo	Tempistica della conversione e base di dimensionamento
4. Percorso BW	Quali modelli BW restano, quali passano ai data product	Piano graduale invece di una migrazione big bang
5. Dati anagrafici	Responsabilità degli attributi di clienti e prodotti	Un responsabile nominato per dominio
6. Primo caso d’uso	Una domanda che il management già pone	Perimetro del primo rilascio BDC

La trattativa di rinnovo

Pianificate il passaggio anche sul piano commerciale. Se il contratto Datasphere o SAC si rinnova nei prossimi dodici mesi, negoziate la conversione a BDC al rinnovo. Portate lo storico dei consumi: il dimensionamento della capacità favorisce i clienti che conoscono il proprio utilizzo reale rispetto a chi accetta una taglia standard.

Mantenete il perimetro contenuto. Il primo passo giusto dopo la conversione non è un progetto di migrazione della piattaforma, ma un dominio, i data product che lo servono e un’analisi che risponde a una domanda che il management già pone. La responsabilità dei dati anagrafici viene prima; perché i dati CRM dipendono dalle fondamenta dei dati spiega l’ordine. Il lavoro sulla piattaforma segue la domanda, non il contrario.

Se per l’inventario desiderate un secondo parere, parlatene con noi. Spadoom realizza il nucleo ERP e lo stack CX con un unico team, ed è per questo che guardiamo contemporaneamente entrambi i lati del modello dei dati.

Domande frequenti

SAP Datasphere sparisce con Business Data Cloud?

No. Datasphere resta il componente di integrazione e modellazione dentro BDC; spazi, modelli e flussi di dati si conservano. Cambia la confezione: nuove funzionalità, data product e licenze arrivano ora sotto l’ombrello BDC.

Le licenze Datasphere esistenti si convertono in BDC?

SAP concede BDC in licenza sulla base di capacity unit; la conversione dei contratti standalone di Datasphere o SAP Analytics Cloud dipende dal vostro contratto. Il consiglio pratico è far coincidere la conversione con il prossimo rinnovo, presentarsi con i dati di consumo reali e negoziare il bundle, non i singoli componenti.

Ha ancora senso avviare un nuovo progetto Datasphere nel 2026?

Avviatelo come progetto BDC. Il lavoro è in gran parte lo stesso (spazi, modelli, flussi), ma contratto e architettura dovrebbero presupporre il packaging BDC, i data product ovunque SAP li fornisca e una replica costruita in proprio solo dove un data product non esiste ancora.

Cosa succede a SAP BW in BDC?

SAP BW, inclusa la BW private cloud edition, è uno dei componenti di BDC. I modelli BW esistenti possono continuare a girare mentre le nuove analisi nascono su data product e Datasphere; il passaggio può quindi essere graduale invece di un unico progetto di migrazione.