| Migrer de SAP BO vers Looker, Automatiquement, Au forfait |
|
|
|
| |
|
| Ellipsys a accompagné le Groupe ADEO / Leroy Merlin dans la simplification massive de sa plateforme SAP BO puis dans la migration du patrimoine utile vers Looker (et Power BI) en automatisant le processus, au forfait. Nous vous en partageons les principaux aspects. |
|
|
|
| |
|
| SAP BO : une feuille de route incertaine |
|
| |
|
| |
|
| SAP Business Objet détiendrait plus de 5 % de part de marché sur le marché de la BI avec presque 30,000 clients dans le monde (6Sense). Or la plateforme navigue dans un flou certain : - La version 4.2 atteindra la fin du support « priorité 1 » fin 2024.
- La version 4.3 devrait être prise en charge jusqu'à fin 2027, avec une maintenance standard se terminant fin 2025.
- SAP prévoit de publier la première version de SAP Business Objects BI 2025 au quatrième trimestre 2024. On n’en connaît pas très bien les contours. Mais ce qui est précisé, c’est que certains 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.
De façon générale, on peut considérer que la volonté assumée de SAP est de voir ses clients partir vers SAP Analytics Cloud (SAC). Or cette ambition n’a pas l’air d’être totalement partagée. Pourquoi ? : La « self BI » est plébiscitée par les équipes métiers, mais aussi par l’IT, qui de gré ou de force, lâche du lest au métier. Et SAP BO n’est précisément pas une solution orientée « self BI ». C'est une très bonne solution, mais perçue comme "datée". |
|
|
|
| |
|
|
Looker, une croissance fort
|
|
|
|
| |
|
| Looker de son côté tire son épingle du jeu, en profitant de la puissance de frappe de Google, des prix très abordables de Looker et de l'engouement pour BigQuery, la base de données Cloud de Google. Looker est "Cloud native", simple d'utilisation, raccordé à GitHub pour le versioning et pour le travail collaboratif, etc. La part de marché de Looker est encore réduite, mais les taux de croissance sont importants.
|
|
|
|
| |
|
| Migrer de SAP BO vers Looker ? |
|
| |
|
| |
|
| Nous percevons de notre côté un mouvement sensible de SAP BO vers Looker, en particulier compte tenu de la possibilité offerte de conserver une couche sémantique. Mais pour celles et ceux qui veulent se départir de SAP BO, c’est un chantier monumental qui se profile : certaines entreprises que nous côtoyons ont plus de dizaines de milliers de dashboards BO en production. Si le projet doit être conduit « papier crayon », la facture peut être salée. Avec un résultat plus qu’incertain. |
|
|
|
| |
|
| Dans cette logique, Ellipsys a créé une solution de migration automatisée entre SAP BO et Looker qui s’appuie sur son logiciel {openAudit}. C'est la fonctionnalité {oA.Reverse}. Cette fonctionnalité a été mise en œuvre pour le compte du Groupe ADEO Leroy Merlin pour ramener la plateforme SAP qui comptait plus de 100,000 dashboards à 8,000, puis pour la migrer vers Looker (et Power BI). Ci-après, les 6 points saillants de notre méthodologie dans le cadre de ce type de projet. Nous les conduisons au forfait. |
|
|
|
| |
|
| |
Migrer ce qui doit vraiment être migré |
|
|
|
| |
|
| Pourquoi migrer des dizaines de milliers de dashboards SAP BO, 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. {openAudit}, notre logiciel, permet de réduire sensiblement le scope de dashboards SAP BO à migrer, en permettant des archives massives préalablement à la migration. Les dashboards SAP BO obsolètes, ou comportant des erreurs, sont détectés. {openAudit} permet de les archiver via la création de BIAR unitaires (format d’archive BO). Ils peuvent être éventuellement supprimés définitivement par la suite. Cependant, nous historisons l'intelligence de BO (sur ses différentes versions). Donc rien n'est perdu. |
|
|
|
| |
|
| |
Un "reverse engineering" complet de la plateforme BO à migrer |
|
|
|
| |
|
| Les dashboards SAP BO sont souvent d’une extrême complexité compte tenu de la très forte antériorité de la plateforme. Cette complexité doit être appréhendée, au niveau de l’intelligence du dashboard mais aussi au niveau des sources. L'idée sera de collecter tout ce qui pourra l'être avec nos sondes et parsers pour capturer toute l'intelligence sous-jacente à la plateforme SAP BO. |
|
|
|
| |
|
| |
Une migration de la "couche sémantique". |
|
|
|
| |
|
| La couche sémantique est une couche d'abstraction qui permet de raccrocher à des considérations techniques d'une base de données des termes "métier", pour permettre aux équipes de construire des tableaux de bords en toute autonomie. BO est une technologie éprouvée et robuste qui - avec sa (très) longue expérience de sa couche sémantique - a su organiser l'information dans les entreprises.
L'idée est donc de permettre aux équipes de repartir rapidement d'une couche sémantique optimisée dans la technologie cible, pour pouvoir y bâtir en autonomie la couche de data visualisation de demain : pouvoir aller vers de la "self BI".
- 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.
- 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.
|
|
|
|
| |
|
| |
Ajuster la migration de la couche sémantique pour la rendre plus exploitable par les métiers
|
|
|
|
| |
|
| Pour faciliter la vie du métier, il nous est paru nécessaire d'ajouter un dispositif à notre moteur de migration. Nous avons enrichi notre moteur de migration {oA-Reverse}en mettant dynamiquement à disposition une "table de pilotage". Elle permet de paramétrer simplement l'output, pour tendre vers une couche sémantique idéale, potentiellement très proche de celle de SAP BO. - Le premier run de notre moteur de migration alimente la table de pilotage et produit le LookML (langage de modélisation de Looker).
- Le traitement est ainsi "pilotable", ce qui permet au métier de "jouer" pour modifier les Explore à sa convenance.
- Le LookML est versionné.
|
|
|
|
| |
|
| |
Alléger la plateforme cible |
|
|
|
| |
|
| Les dashboards SAP BO ont accumulé au fil du temps de plus en plus de complexité. Ce foisonnement peut avoir de vraies répercussions sur la plateforme cible, car il y a autant de refreshs que d’utilisateurs. {openAudit} peut potentiellement "déplacer" les requêtes complexes dans les tables et dans les vues de la base de données en source ou dans les dashboards Looker. Ces requêtes complexes ne seront ainsi potentiellement jouées qu'une seule fois pour baisser les coûts, faciliter la maintenance et accélérer les consultations |
|
|
|
| |
|
| |
Valider la non régression |
|
|
|
| |
|
| {openAudit} va exécuter les dashboards BO et les dashboards Looker (après la migration technique) avec des valeurs de prompt analogue, ce qui permettra d’opérer des comparaisons en masse avec des outils statistiques. |
|
|
|
| |
|
| Conclusion Le décommissionnement de SAP devient ces temps un enjeu de taille pour beaucoup d’entreprises : l’outil est perçu comme étant en fin de vie, mal adapté à un usage Cloud et à la volonté croissance d’aller vers de la « self BI ». Sauf que ces migrations ne sont pas simples à mettre en œuvre tant ces plateformes ont duré : elles ont de ce fait emmagasiné de la complexité. Le moteur de migration de {openAudit} permet d‘automatiser la transcription de SAP BO vers Looker en s’attachant à analyser toutes les subtilités de la source pour pouvoir la reproduire fidèlement dans la cible. Une option intéressante est de ne repartir de la couche sémantique pour créer les condition d'une "self BI" clef en main. La capacité d’{openAudit} à optimiser la plateforme BO, puis à factoriser l’intelligence dans la plateforme cible permet un surcroît considérable d’intelligibilité et de performance. La massification des tests de non régression est 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. Cette ambitieux chantier a été conduit de façon forfaitaire pour le compte du Groupe ADEO/Leroy Merlin avec des résultats extrêmement probants. www.ellipsys-lab.com contact@ellipsys-lab.com |
|
|
|
|
|
|
|
|
|
|
Commentaires
Enregistrer un commentaire