Migrer SAP BO vers Looker avec une vraie couche sémantique

 

 

Migrer SAP BO vers Looker (Google) 

-

Reconstruire

une vraie couche sémantique !

« Mal nommer les choses, c'est ajouter au malheur du monde », disait Albert Camus. Bien les nommer peut aussi aider à assurer le succès d’une entreprise !

 

Ça a été la grande réussite de SAP BO, qui, avec ses "Objets", traduisait des concepts informatiques très abstraits, en informations business manipulables par le plus grand nombre.

 

Cela remonte à loin maintenant, et beaucoup d’entreprises quittent SAP BO, qui commence à être frappé d’obsolescence et qui est mal adapté au Cloud.

 

Quitter BO, c’est aussi se séparer de ses "Objets", organisés dans sa très populaire couche sémantique, les "Univers". 

 

Mais pas forcément. En particulier si la migration a lieu vers Looker de Google, qui prévoit nativement une couche sémantique.

 

Nous vous expliquons comment. 

 
 
 

Etape #1:

 

Une migration des Univers vers des Explores Looker 

 
  1. Notre moteur de migration {openAudit} va diviser les Univers BO (Business Objects) en fonction de chaque contexte et table de faits réellement exploités dans les rapports BO utilisés. Notre moteur de migration s'appuie sur l'usage réel de la plateforme BO en source. 
  2. Chaque Univers BO sera transformé en plusieurs Explores Looker basés sur un modèle en étoile centré sur la table de faits. {openAudit} ne va reprendre que ce qui est utilisé dans SAP BO.

 

Chaque Explore Looker permettra aux utilisateurs de créer des requêtes ad hoc, d'explorer et de visualiser des données.

C'est une reprise fidèle de la couche sémantique, mais elle restera assez éloignée des Univers d'origine du fait des spécificités techniques de Looker vs SAP BO. 

 

Pour faciliter la vie du métier, il nous est paru nécessaire d'ajouter un dispositif à notre moteur de migration. 

 
 
 
 

Etape #2 : 

 

Ajuster cette migration pour la rendre plus exploitable par les métiers 

 

Nous avons enrichi notre moteur de migration en mettant dynamiquement à disposition une "table de pilotage". Elle permettra de paramétrer simplement l'output, pour tendre vers une couche sémantique idéale, potentiellement très proche de celle de SAP BO. 

 

  1. Le premier run de notre moteur de migration va alimenter la table de pilotage et produire le LookML (langage de modélisation de Looker). 
  2. Le traitement sera ainsi "pilotable", ce qui va permettre au métier de "jouer" pour modifier les Explore à sa convenance. 
  3. Le LookML sera versionné. 
 
 

 

Conclusion

 

La sortie de SAP BO est périlleuse. En particulier parce que la couche sémantique suscite une forte adhésion.

Looker de Google est une solution qui permettra de reconstruire une couche sémantique très fonctionnelle. 

 

Pour rendre cette couche sémantique aussi "expérientielle" qu’elle l’était dans SAP BO, notre moteur de migration va construire une table de pilotage permettant de produire une output très exploitable par les métiers, presque instantanément. 

 

Notre solution de migration vient d'être validée Google Cloud Marketplace !

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