BDC e Datasphere: cosa cambia, cosa resta

Quando SAP ha incorporato Datasphere in Business Data Cloud, la prima domanda di ogni cliente con un tenant Datasphere attivo è stata la stessa: cosa succede a quello che abbiamo costruito? La risposta breve è rassicurante; la parte interessante è cosa dovreste smettere di costruire.

Il riassunto in una frase: il vostro investimento in Datasphere sopravvive — ma i flussi di replica costruiti a mano sono ora debito tecnico con data di scadenza.

Cosa resta

Datasphere non sparisce. Continua come livello di modellazione e integrazione dentro BDC:

• Spazi e modelli si conservano. I vostri modelli semantici, viste e flussi dati continuano a funzionare — BDC li consuma invece di sostituirli.
• SAP Analytics Cloud resta come livello di visualizzazione, ora incluso nel bundle invece che contrattato separatamente.
• Le competenze restano preziose. Chi sa modellare in Datasphere è esattamente chi collegherà i data product alle domande di business in BDC.

Se negli ultimi anni avete investito in Datasphere, nulla di tutto ciò è andato sprecato. È la differenza fra un’evoluzione e i funerali di piattaforma a cui i clienti SAP hanno già assistito (abbiamo detto lo stesso di Sales Cloud da V1 a V2: le ricostruzioni sono oneste, i rebranding no — BDC è più vicino a una ricostruzione del packaging attorno a un nucleo che sopravvive).

Cosa cambia

Tre cose sono genuinamente diverse:

1. Packaging e licensing. Un unico contratto BDC in capacity unit copre Datasphere, SAP Analytics Cloud e il motore Databricks integrato. L’era in cui si negoziavano tre prodotti dati SAP separatamente finisce al vostro prossimo rinnovo.
2. I data product sostituiscono l’estrazione costruita a mano. Dove SAP fornisce un data product — finanza S/4HANA, pipeline di Sales Cloud V2, SuccessFactors — il flusso di replica che il vostro team ha costruito per gli stessi dati diventa legacy. SAP mantiene il data product attraverso le release; il vostro flusso custom, invece, lo mantenete solo voi.
3. Il machine learning entra dentro il recinto. I carichi che prima richiedevano di copiare i dati SAP verso una piattaforma ML separata ora girano nel Databricks integrato, sotto la stessa governance. Per chiunque abbia vissuto una revisione di protezione dati su una piattaforma analytics ombra, questa è la notizia silenziosa. Sotto nLPD svizzera e GDPR, “i dati non hanno mai lasciato la governance SAP” è una frase che il vostro DPO pronuncerà volentieri.

Cosa smettere di costruire

Concretamente, da quest’anno:

• Smettete di costruire nuovi flussi di replica per dati che SAP fornisce come data product. Controllate prima il catalogo; costruite solo per le lacune.
• Smettete di modellare da zero le entità generiche. “Cliente”, “ordine di vendita”, “fattura” arrivano già modellati semanticamente. Il vostro sforzo di modellazione appartiene all’ultimo miglio — la vostra logica di settore e i vostri KPI — non al primo.
• Smettete di trattare l’analytics di S/4HANA e CX come progetti separati. Sullo stack integrato, una sola fondazione serve entrambi. Dividerli ricrea il problema dei numeri discordanti che BDC esiste per chiudere.

La conversazione sul rinnovo

Sincronizzate la mossa dal punto di vista commerciale. Se il vostro contratto Datasphere o SAC si rinnova nei prossimi 12 mesi, negoziate la conversione a BDC al rinnovo — è lì che SAP è flessibile. Portate la vostra storia di consumo: il dimensionamento in capacity unit premia i clienti che conoscono il proprio utilizzo reale invece di accettare la taglia standard proposta.

E tenete lo scope onesto. Il primo passo BDC giusto dopo la conversione non è un progetto di migrazione di piattaforma — è un dominio, un set di data product, una insight app che risponde a una domanda che il vostro management già pone. Il lavoro di piattaforma segue la domanda, mai il contrario.