Migrer de SAP BO vers Power BI, automatiquement

 



 

 

Migrer de SAP BO vers Power BI, automatiquement, au forfait


SAP avait annoncé par le passé la fin de vie de SAP BO.

Finalement, la roadmap a un peu changé, puisqu’il s’agira d’aller vers SAP BusinessObjects BI 2025 (qui est pour le moment un nom de code).

 

Cependant, une liste de composants ne seront pas inclus dans la version BI 2025, dont Universe Design Tool (pour la construction des .unv), les univers multi sourcés, etc. Ces composants resteront dans la version BI 4.3, mais le support de maintenance prendra fin en 2025.  
Et le reste n’est pas forcément très clair, même si SAP annonce vouloir se concentrer sur les outils les plus adoptés.

 

Par ailleurs, la "self BI" est plébiscitée par les équipes métiers, mais aussi par l’IT qui se réjouit de donner de l’autonomie aux équipes.  

 

Cela étant dit, c’est un chantier monumental qui se profile, et qui effraie les équipes à juste titre : certains de nos clients ont plus de 100 000 dashboards BO en production. Le mouvement pourrait être très long et excessivement coûteux. 

 

Dans cette logique, Ellipsys a créé une solution de migration pour la couche de dataviz qui s'appuie sur les données de la solution {openAudit}.

Cette fonctionnalité est à l'oeuvre pour un client important, en association avec notre module de nettoyage / simplification de la couche SAP BO. 

 

Dans le cas présent, il s'agira de migrer des milliers de dashboards SAP BO vers Power BI, en automatisant la totalité du processus 😊.

 

Ci-dessous, les quelques points saillants de notre méthodologie dans le cadre de ce projet :  

 

Analyse automatisée de la plateforme BO 

 

 

Pour analyser la complexité des rapports, nous nous appuyons sur les différentes tables qui sont générées directement par {openAudit} après le parsing quotidien de la plateforme SAP BO.

 

Nous récupérons globalement les informations suivantes :

 

Au niveau de l'intelligence du dashboard

  • La liste des expressions et des variables utilisées et leur niveau d'imbrication ; 
  • La liste des fonctions BO de base utilisées dans ces expressions et ces variables ;  
  • Le sourcing (lineage) de chaque élément publié (que ce soit directement dans les blocs, les filtres, les input parameters, les merged dimensions, les alerters, etc.)

 

Au niveau du layout 

  • Le nombre d'onglets, de blocs imbriqués, de sections ;
  • Le nombre et type de tables (HTable, VTable, XTable) et de graphiques dans le layout ;
  • La liste des filtres dans les éléments.

 

Au niveau des sources 

  • Le nombre de data providers et de dimensions liées ;
  • Le nombre d'objets des Data Providers non publiés (inutiles pour la publication) ;
  • Les contextes utilisés ;
  • La liste des prompts utilisés dans les rapports ;
  • Les liens entre data providers, ou entre statements, pour les data providers multi-statements ;
  • La définition des SQL personnalisés (surcharge ou freehand SQL). 

 

{openAudit} va identifier au départ des dashboards à migrer, la liste des objets qui seront nécessairement migrés.

 

L'idée est de construire une couche sémantique optimisée dans la technologie cible. 

 

Depuis cette liste, nous déterminons : 

  • La liste des champs et donc des tables utiles ;
  • La liste des jointures pour relier ces tables ;
  • La liste des contextes BO à reproduire ;

 

Cette première liste nous permettra ensuite de jauger la complexité de la couche sémantique à reproduire dans la cible :

  • Liste des tables dérivées impactées;
  • Les objets imbriqués ou liés ;
  • Les objets agrégés (aggregate_aware) ;
  • Les vues et SQL source à modifier pour répondre à la cible.

 

 

La migration vers Power BI 


Migration des dashboards et de l'intelligence

{openAudit} va convertir les objets dans les tables du data model de chaque dashboard et organiser la data prep pour reproduire l'intelligence des documents BO en DAX et/ou Code M.

Certaines optimisations sont également mises en oeuvre pour alléger la data prep.

Migration du layout

{openAudit} convertit le layout BO directement dans le PBIX qui sera exporté dans Azure. L'organisation des composants est également respectée. L'utilisateur bénéficie en plus des fonctionnalités natives de PowerBI (filtres dynamiques, slicers, drill, etc) qui enrichissent l'expérience utilisateur.

 




Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

La Data Observabilité, Buzzword ou nécessité ?

Image
    La Data Observabilité,   Buzzword ou nécessité ?   La qualité des données utilisées dans les opérations quotidiennes a un rôle prépondérant pour les entreprises.    Une étude du Gartner de 2022 suggère que les "mauvaises données" coûtent aux organisations environ 12,9 millions de dollars par an.  Le Data Quality Hub du gouvernement britannique estime que les organisations consacrent entre 10 % et 30 % de leurs revenus aux problèmes de qualité des données, ce qui peut représenter des centaines de millions de dollars pour des entreprises de premier plan.  Dès 2016, IBM estimait que la mauvaise qualité des données coûtait aux entreprises américaines 3 100 milliards de dollars par an. ... Tout le monde souhaite s’appuyer sur des données intègres pour éviter des erreurs simples liées à des problèmes d’alimentation dans des flux, ou à des données mal organisées, répliquées, etc. Mais comment ?    Les techniques d' "observabilité des données" sont une option.     
Lire la suite

BCBS 239 : L'enjeu de la fréquence et de l'exactitude du reporting de risque

Image
  BCBS 239 :    L'enjeu de la fréquence et de l'exactitude du reporting de risque.  La BCE a publié un guide en juillet 2023 pour repréciser ses attentes dans le cadre de BCBS 239. Elle prévoit de renforcer le dispositif de supervision en matière de qualité des données.   L'objectif global de la norme BCBS 239 est de renforcer les capacités d'agrégation des données de risques des banques, et les pratiques internes de reporting de risques, améliorant ainsi les processus de gestion des risques et de prise de décision dans les banques. « La bonne information doit être à disposition pour les bonnes personnes et au bon moment ».   La mise en œuvre de BCBS 239 n'est a priori pas simple.   Pourquoi ? Malgré cette surveillance prudentielle accrue,  la BCE n’a toujours pas constaté de progrès suffisants en 2023 :  "le dispositif data quality et reporting risques ne reçoit pas encore le niveau d’attention approprié de la part des banques".   Nous avons beaucoup écha
Lire la suite

Le data lineage, l’arme idéale pour la Data Loss Prevention ?

Image
  Le data lineage technique couplé à la détection des usages de l’information permet de savoir au départ de n’importe quelle donnée, qui y accède finalement, et dans quel contexte. Et si c’était un grand pas vers une véritable sécurité informationnelle, une réponse simple et efficace pour la Data Leaks/Loss Prevention ?  La DLP (Data Leaks / Loss Prevention), c’est quoi ?   _______________________________________ « Le terme Data Loss/Leaks Prevention (DLP) fait référence à un ensemble de techniques qui permettent d’identifier, de contrôler et de protéger l’information grâce à des analyses de contenu approfondies, que l’information soit stockée, en mouvement, ou traitée . L’objectif est de limiter la fuite de données sensibles.  Une solution DLP est capable d’identifier les données sensibles, de repérer l’endroit où elle est stockée, de contrôler qui doit avoir accès à ces données et enfin de les protéger, c’est-à-dire d’empêcher toute personne non autorisée à y avoir accès… » W
Lire la suite