Migration DataViz - migrer de SAP BO vers Power BI
Les patrimoines SAP BusinessObjects regroupent généralement plusieurs années de modélisation : univers, rapports Web Intelligence, objets métier, calculs, filtres, invites et couches sémantiques.
{openAudit} analyse les univers, les rapports et les logs d’usage afin de reconstruire les dépendances entre les sources de données, les objets métier et les visualisations.
Point clé : la migration porte sur les univers, les objets métier, les règles de gestion, autant que sur les rapports.
Prérequis d’analyse SAP BusinessObjects
L’analyse nécessite l’accès aux services SAP BusinessObjects, aux référentiels techniques et à la base d’audit.
Les extracteurs sont exécutés dans l’environnement du Client. Les métadonnées collectées peuvent être anonymisées avant traitement.
Bon à savoir : seules les métadonnées techniques sont exploitées.
Analyse du patrimoine
L’analyse couvre les rapports Web Intelligence, les univers UNV et UNX, les Data Providers, les objets métier, les variables, les filtres, les invites et les composants graphiques.
Les dépendances techniques et les usages observés sont consolidés dans un référentiel.
Rationalisation
Les logs d’audit sont croisés avec les métadonnées de la plateforme.
Les rapports inutilisés, les doublons, les objets non consommés et les univers obsolètes sont identifiés avant migration.
Résultat : réduction du volume à migrer.
Conversion vers Power BI
Les Data Providers sont convertis en datasets Power BI.
Les requêtes, calculs et variables sont convertis en SQL ou DAX. Les objets métier sont reconstruits sous forme de dimensions et de mesures.
Les dépendances entre univers, rapports et sources de données sont conservées dans le modèle cible.
Les tableaux, graphiques, filtres, sections et éléments de mise en page sont analysés puis reconstruits dans Power BI.
La conversion s’appuie sur {oa-lake} : les requêtes, calculs et variables sont encapsulés sous forme de pipelines SQL, et les objets métier des univers alimentent la couche sémantique interopérable d’{oa-lake}. Power BI se connecte à ce modèle prêt à l’emploi (voir ci-dessous).
Point clé : la migration couvre à la fois la couche métier et la couche de restitution.
Validation
Les migrations peuvent être réalisées en double exécution SAP BusinessObjects / Power BI.
Les indicateurs produits par les deux plateformes sont comparés pendant les phases de recette.
Tables, filtres et slicers
Conversion des tables, filtres et sections SAP BusinessObjects vers les composants Power BI.
Pie Charts
Conversion des pie charts SAP BusinessObjects vers les visuels Power BI.
Graphiques
Conversion des graphiques SAP BusinessObjects vers les visuels Power BI.
Dashboards
Conversion des dashboards SAP BusinessObjects vers Power BI.
{oa-lake} : le socle de toute migration DataViz
Migrer d’un outil de reporting à un autre répond au besoin immédiat, mais déplace la logique métier dans un nouveau modèle propriétaire : au prochain changement d’outil, tout est à reconstruire.
C’est pourquoi chaque migration DataViz s’appuie désormais sur le middleware {oa-lake}, qui joue deux rôles :
- Encapsuler l’intelligence. Les requêtes, calculs, variables et règles métier extraits par {openAudit} sont transcrits en SQL et exécutés dans {oa-lake} sous forme de mini pipelines SQL (un mini ETL), au lieu d’être réécrits dans l’outil cible.
- Préserver la couche sémantique. La couche sémantique construite au fil des années dans la plateforme source (univers, Frameworks, modèles) est reconstituée dans la couche sémantique interopérable d’{oa-lake}, qui alimente ensuite l’outil cible.
Power BI se connecte à {oa-lake} et consomme un modèle déjà prêt : objets métier, KPI et sécurité ne sont plus enfermés dans un nouveau modèle propriétaire.
- Définir une fois, utiliser partout : client, contrat, produit… une seule définition, valable pour tous les outils consommateurs.
- KPI et sécurité centralisés : des indicateurs calculés une seule fois et une sécurité appliquée uniformément, quel que soit l’outil de restitution.
- Data prep rationalisée : des mini pipelines SQL mutualisés remplacent la préparation dispersée dans chaque outil.
- Outils BI interchangeables : Power BI, Looker, DigDash ou tout autre outil se connecte à un modèle déjà prêt, sans redéfinir la logique métier.
- Piloté comme du code : pipelines SQL et modèle sémantique en YAML/JSON, versionnés dans Git et déployés par Terraform.
- Prêt pour l’IA : les mêmes données et la même sémantique alimentent la BI, les LLM et les agents IA.
Point clé : migrer vers {oa-lake}, c’est migrer une dernière fois. La logique métier devient un actif de l’entreprise, indépendant des éditeurs.
Découvrir {oa-lake} → · Interopérabilité SQL et couche sémantique →
