SAP BO : Optimiser la migration

 



Automatiser, Optimiser la migration ;

 

 

Et minimiser les régressions !

De nombreuses entreprises souhaitent décommissionner SAP BO pour partir vers des technologies plus pérennes, plus en adéquation avec les plateformes Cloud du moment.

 

Nous avons créé une solution de migration entre SAP BO et Looker, ou Power BI, qui s’appuie sur une analyse granulaire de la plateforme SAP BO, puis qui migre automatiquement l’intelligence et le layout de SAP BO vers Power BI ou Looker. 

 

Migrer de SAP BO vers Power BI ou Looker
 
 

Cependant,

 

  • Il est bien dommage de reproduire dans la plateforme cible la complexité accumulée dans SAP BO au fil du temps ;  
  • La complexité de la plateforme SAP BO en source est souvent si importante qu’il y a des risques forts de régression !

 

Nous avons travaillé sur ces différentes objections émanant de nos clients, pour enrichir {openAudit} afin que ces migrations soient de véritables succès ! 

 

3 étapes : 

 

I- Simplifier sa plateforme SAP BO en masse avant migration



Le problème

 

Pourquoi migrer des dizaines de milliers de dashboards, quand en réalité une infime minorité est réellement utilisée ? 

C’est souvent plus de 90 % de la plateforme SAP BO en source qui n’a pas, ou plus d’usage.



la solution

 

{openAudit} permet de réduire sensiblement le scope de dashboards à migrer, en permettant des archives massives préalablement à la migration. 

 

  1. Les documents obsolètes, ou comportant des erreurs, sont détectés.{openAudit} permet de les archiver via la création de BIAR unitaires.
  2. {openAudit} détecte les documents répliqués selon divers critères.  Ils peuvent être archivés en masse dans des BIAR unitaires.

II- Externaliser la complexité des dashboards SAP BO vers la DB cible

Le problème

 

Les dashboards SAP BO ont accumulé au fil du temps de plus en plus de variables et d'expressions, souvent répliquées.



Ce foisonnement peut avoir de vraies répercussions sur la plateforme cible (Power BI ou Looker), car il y a autant de refresh que d'utilisateurs. 

 

  1. Les temps d’exécution peuvent être (très) longs.
  2. Les coûts associés sont élevés : reproduction N fois des mêmes requêtes.  
  3. Les résultats des requêtes des outils de dataviz sont généralement bridés. 

 

Le service peut finir par être dégradé pour les métiers, et discréditer la migration.



La solution

 

  1. {openAudit} va identifier les expressions / variables complexes au sein des dashboards SAP BO.
  2. {openAudit} va "déplacer" ces requêtes complexes dans les tables et dans les vues Azur SQL ou GCP, en simple SQL.
  3. Ces requêtes complexes ne seront ainsi jouées qu'une seule fois (puis schedulées) pour tous les dashboards Power BI ou Looker. 

 



Pourquoi

 

  1. Pour réduire sensiblement les coûts ;
  2. Pour faciliter la maintenance en réduisant la complexité ;
  3. Pour accélérer les consultations ; 
  4. Pour permettre de sourcer les données d'un dashboard (data lineage de bout en bout) ; 
  5. .... 

Exemple d’une requête type SAP BO jouée pour de nombreux dashboards, vs la même requête « déplacée » dans le DWH sous forme de vue (en source de Power BI ou de Looker). 

  • Dans SAP BO, cette requête va « coûter » 45 GO, avec un temps d’exécution de 4 s.


  • Dans Azur SQL ou dans GCP, l'accès à la table va « coûter » 28 MB pour 1s à l’exécution (plus 1s de latence). C'est en plus un temps d'accès "sans filtre" : dans 90 % des cas, les coûts et les temps d'accès sont encore plus bas. 

 



 
 

III- Valider la non régression entre la plateforme SAP BO et Looker, ou Power BI



Le problème

 

Le métier craint légitimement les régressions. La migration devrait être opérée "sans couture" dans la mesure du possible. 



La solution 

 

  1. {openAudit} exécute les dashboards BO.
  2. {openAudit} exécute les dashboards Power BI ou Looker après la migration technique, avec des valeurs de prompts analogues.
  3. {openAudit} opère des comparaisons en masse avec des outils statistiques. 

 

Les régressions présentant des analogies sont traitées au niveau du moteur de migration, de façon à arriver à un résultat optimisé. 

Conclusion 

 

Le moteur de migration de {openAudit} permet d‘automatiser la transcription de SAP BO vers Power BI ou Looker (autres technos à l’étude).

 

La qualité de l’output restera un enjeu majeur.

 

La capacité de {openAudit} à optimiser la plateforme BO, puis à factoriser l’intelligence, pour enfin la pousser vers le DWH cible, permettra un surcroît considérable d’intelligibilité et de performance dans la plateforme cible. 

 

La massification des tests de non régression sera une méthode précieuse pour arriver très vite à un optimum, pour faire de cette migration un vrai succès pour l'IT et le métier !


 

Commentaires

Posts les plus consultés de ce blog

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

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

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