Aller au contenu
BDC et Datasphere : ce qui change, ce qui reste
Strategy · ·7 min de lecture

BDC et Datasphere : ce qui change, ce qui reste

Dario Pedol

Dario Pedol

CEO & SAP CX Architect, Spadoom AG

Partager

Quand SAP a intégré Datasphere dans Business Data Cloud, la première question de chaque client avec un tenant Datasphere en production était la même : qu’advient-il de ce que nous avons construit ? La réponse courte est rassurante ; la partie intéressante est ce que vous devriez arrêter de construire.

À retenir en une phrase : votre investissement Datasphere survit, mais les flux de réplication construits à la main sont désormais de la dette technique avec une date de péremption.

Ce qui reste

Datasphere ne disparaît pas. Il continue comme couche de modélisation et d’intégration à l’intérieur de BDC :

  • Les spaces et les modèles sont repris. Vos modèles sémantiques, vues et flux de données continuent de fonctionner : BDC les consomme au lieu de les remplacer.
  • SAP Analytics Cloud reste la couche de visualisation, désormais incluse dans le bundle au lieu d’être contractualisée séparément.
  • Les compétences restent précieuses. Les personnes qui savent modéliser dans Datasphere sont exactement celles qui relieront les produits de données (« data products ») aux questions métier dans BDC.

Si vous avez investi dans Datasphere ces dernières années, rien de tout cela n’a été perdu. C’est la différence entre une évolution et les enterrements de plateformes auxquels les clients SAP ont déjà assisté (nous disions la même chose de Sales Cloud V1 vers V2 : les reconstructions sont honnêtes, les renommages ne le sont pas — BDC est plus proche d’une reconstruction de l’emballage autour d’un cœur qui survit).

Ce qui change

Trois choses sont réellement différentes :

  1. Packaging et licences. Un contrat BDC en unités de capacité couvre Datasphere, SAP Analytics Cloud et le moteur Databricks embarqué. L’ère de la négociation séparée de trois produits de données SAP se termine à votre prochain renouvellement.
  2. Les produits de données remplacent l’extraction construite à la main. Là où SAP livre un produit de données — finance S/4HANA, pipeline Sales Cloud V2, SuccessFactors — le flux de réplication que votre équipe a construit pour les mêmes données devient du legacy. SAP maintient le produit de données à travers les releases ; personne ne maintient votre flux custom à part vous.
  3. Le machine learning passe à l’intérieur de la clôture. Les charges de travail qui exigeaient de copier les données SAP vers une plateforme ML séparée tournent désormais dans Databricks embarqué, sous la même gouvernance. Pour quiconque a vécu une revue de protection des données d’une plateforme analytique fantôme, c’est le titre discret de l’histoire. Sous la nLPD suisse et le RGPD, « les données n’ont jamais quitté la gouvernance SAP » est une phrase que votre DPO prendra plaisir à prononcer.

Ce qu’il faut arrêter de construire

Concrètement, dès cette année :

  • Arrêtez de construire de nouveaux flux de réplication pour des données que SAP livre comme produit de données. Vérifiez d’abord le catalogue ; ne construisez que pour les manques.
  • Arrêtez de modéliser des entités génériques à partir de zéro. « Client », « commande client », « facture » arrivent modélisés sémantiquement. Votre effort de modélisation appartient au dernier kilomètre — votre logique métier et vos KPI — pas au premier.
  • Arrêtez de traiter l’analytique S/4HANA et CX comme des projets séparés. Sur la pile intégrée, une seule fondation sert les deux. Les séparer recrée le problème des chiffres contradictoires que BDC existe pour éliminer.

La conversation de renouvellement

Choisissez le moment commercialement. Si votre contrat Datasphere ou SAC arrive à renouvellement dans les 12 prochains mois, négociez la conversion BDC au renouvellement : c’est là que SAP est flexible. Apportez votre historique de consommation : le dimensionnement en unités de capacité récompense les clients qui connaissent leur usage réel au lieu d’accepter la taille standard par défaut.

Et gardez un périmètre honnête. La bonne première étape BDC après conversion n’est pas un projet de migration de plateforme : c’est un domaine, un ensemble de produits de données, une insight app qui répond à une question que votre direction pose déjà. Le travail de plateforme suit la demande, jamais l’inverse.

SAPBusiness Data CloudBDCDatasphereAnalyticsMigration
Etape suivante

SAP Business Data Cloud partenaire d'implémentation

Spadoom est le partenaire d'implémentation SAP Business Data Cloud en Suisse, Allemagne, Autriche et Italie. Médiane de go-live de 14 semaines. Clients en production dans tout le DACH.

Articles associes

Demandez a un expert