Associer Power BI, Microstrategy, Qliksense avec SAP BW/4HANA … Est-ce vraiment l’idée du siècle ?

Vous avez construit toute votre stratégie data SAP, autour de BW on HANA ou mieux, BW/4HANA (qui est sorti en 2016). Les données finance, controlling et logistique sont toutes centralisées au sein de votre Datawarehouse d’Entreprise. Architecture simple, approche standardisée, kpi fiablisés, performances de la nuit applicative…

Vous vous êtes mêmes permis d’extraire de la donnée tierce pour la croiser avec votre donnée SAP. Tout semble aller pour le mieux !

Cependant, les avis divergent sur le choix de la solution de reporting à adopter.

Résultat des votes

Chaque personne est sondée et au moment des dépouillements voici ce qu’il en sort :

  • Robert, l’architecte SAP souhaite continuer avec BO parce que ca fait 10 ans que la boite tourne avec du BO
  • Philippe, le développeur BW tout fraichement recruté en interne conseille SAC parce que c’est l’avenir de SAP et qu’il a fait des démos assez poussées dans son ancienne SSII
  • Emmanuel, le nouveau lead BI souhaite mettre du MicroStrategy parce que dans sa boite précédente, ca marchait bien (en plus, il connait un super développeur qui avait tout développé en quelques jours)
  • Le DSI veut PowerBI parce que c’est beau et moins cher
  • La finance a fait appel à un cabinet d’audit pour son choix de solution et ils leur proposent Toucan Toco
  • La logistique utilise Qliksense parce que Bernard, responsable de site à Villeneuve Saint Georges a développé des rapports avec quelques licences et tout le monde est devenu fan

Comment faire le tri dans toutes ces idées divergentes ? Pourquoi l’évidence n’est pas de mise ?

Nous savons déjà qui aura le dernier mot, mais il est intéressant de comprendre les critères de décision et s’attarder sur ceux qui ont été cachés sous le tapis ou pire encore… pas abordés.

Comment bien choisir sa solution de reporting pour BW/4HANA ?

On distinguera ici plusieurs familles de critères :

  • les critères liés aux usages : exploration de la donnée à un niveau opérationnel ? consommation de KPI stratégiques à un niveau agrégé ?
  • les critères fonctionnels : quels sont les fonctionnalités des suites de reporting (en visu, en interactivité, en navigation, en mobilité, en collaboration, en exports, en authentification…)
  • les critères d’intégration : comment ces solutions s’intègrent avec SAP BW/4HANA ?
  • les critères stratégiques : quelle est la roadmap de la solution ?
  • les critères financiers : combien ca coute ? (en implémentation, en maintenance et en licences)

La discussion qui est trop peu souvent abordée est celle des considérations techniques liées à l’intégration d’une solution de datawarehouse SAP avec une solution de reporting non SAP.

Comprendre l’intégration BW/4HANA avec les solutions de reporting du marché

Si vous avez fait l’acquisition de BW/4HANA, alors vous êtes sans doute prêts à capitaliser sur cet investissement.

Cependant, afin de capitaliser au maximum, il faut connaitre les mécaniques d’intégration avec les solutions de reporting et donc… les interfaces disponibles pour interroger votre BW/4HANA. Voici un schéma explicatif :

Interfaces de reporting disponibles sur BW/4HANA

Votre BW/4HANA comporte 4 interfaces d’interrogation de données en direct :

  • L’interface BICS (BI Consumer Services) : interface propriétaire uniquement réservée aux outils SAP, elle permet de bénéficier de l’ensemble des fonctionnalités du moteur OLAP de BW/4HANA aussi appelé Analytical Engine. Exemple de fonctionnalités : exceptions d’agrégation, conversions de devises, gestion native des hiérarchies, support des variables exit, support des BADI de personnalisation de listes F4…
  • L’interface MDX (Multidimensional Expressions) : interface réservée aux outils tiers via le langage de manipulation de données MDX. Cette interface contient de nombreuses limitations documentées par les éditeurs
  • L’interface InA (Info Access service) : interface utilisant le protocole http(s) et permettant d’interroger les calculation views via le serveur d’application intégré (XS Advanced Server).
  • L’interface SQL (Structured Query Language) : interface permettant l’accès via la base de données HANA liée à votre application BW/4HANA. Dans ce cas, vous pourrez vous connecter aux calculations views via le driver odbc HANA (aussi appelé HANA Client) qui interrogera l’index server HANA.

L’interface BICS étant propriétaire, on note un gros décalage en termes de fonctionnalités entre les outils SAP pouvant utiliser cette interface et les outils tiers devant passer par MDX.

Exemple de page expliquant les limitations MDX de PowerBI avec BW : https://docs.microsoft.com/fr-fr/power-bi/connect-data/desktop-directquery-sap-bw

Exemple de note SAP de troubleshooting des erreurs MDX pour Powerbi : https://launchpad.support.sap.com/#/notes/0002777473

Côté accès direct à HANA (via SQL ou via InA), il y a moins de différences en termes d’intégration entre les outils SAP et tiers. Cependant, il sera compliqué de capitaliser sur vos développements pur BW/4HANA (les queries) car pour accéder à ces objets via l’interface SQL, il faudra passer par la génération des objets équivalents dans HANA :

Ces générations présentent plusieurs limitations et conditions d’entrée afin d’être exécutées. Il sera dans ce cas compliqué de mettre en place une logique “d’industrialisation” des développements.

Une architecture système plus complexe

Autre point à prendre en considération : la complexité de votre architecture système.

Il est à noter que les solutions tierces sont souvent composées d’une version Desktop pour développeur et d’une version Server pour les déploiements aux utilisateurs finaux. Se pose également la question des fonctionnalités entre ces versions Desktop et les versions Server (Cloud ou On-Premise).

Ainsi pour intégrer PowerBI avec BW/4HANA vous aurez besoin d’un connecteur .NET pour attaquer l’interface MDX via PowerBI Desktop. Pour déployer vos rapports dans le Service PowerBI (cloud), vous aurez besoin d’un bridge nommé “PowerBI Gateway” qui permet de faire communiquer le Cloud avec votre BW/4HANA on premise. De plus, les fonctionnalités supportées par PowerBI Desktop ne le sont pas toutes dans le Service PowerBI.

Pour vous un petit schéma expliquant la différence en termes d’architecture :

Là où SAP propose un protocole permettant de sécuriser les échanges de données entre SAC et BW/4HANA ou HANA via CORS (Cross Origine Ressource Sharing), PowerBI propose un composant additionnel. Cette différence n’est pas anodine :

  • il vous faudra provisionner un ou plusieurs serveurs dédiés à la gateway dans votre landscape
  • il vous faudra administrer ce composant (monitoring, patch, montées de versions…)

Ce n’est qu’un exemple parmi tant d’autres. Il faudra également considérer d’autres points d’architecture importants tels que le SSO par exemple.

Les 10 points de douleur qui vous attendent avec des solutions tierces couplées à BW/4HANA

1- Les limitations des connecteurs : comme énoncé précédemment, les connecteurs MDX présentent certaines limitations avec BW/4HANA, et ces limitations diffèrent selon les versions Desktop et Server des outils tiers. Ainsi certaines fonctionnalités qui peuvent paraitre basiques ne seront pas supportées dans leur intégralité : exception agrégations, variables exit, multi hiérarchies, conversions de devises, conditions…

2- Une architecture complexe : des middleware tels que la gateway PowerBI devront être ajoutés à votre landscape, le rendant par la même occasion plus complexe que dans le cas d’une architecture SAP/SAP

3- Réutilisation des développements BW/4HANA complexes : si vous faites le choix de passer par l’interface HANA, vous aurez des difficultés à utiliser les requêtes complexes que vous aviez pu construire sur BW/4HANA. Vous pourrez générer des objets équivalents dans HANA via des transactions ou via les interfaces de modeling mais ces générations sont truffées de limitations ou de bugs. Autre point important, il faudra dans ce cas considérer une gestion des habilitations et donc de la sécurité via la couche HANA (et non plus NW)

4- Les fausses promesses d’un POC trompeur : ne vous laissez pas surprendre par un POC présentant des prouesses graphiques dans le cadre d’une démo réalisée à partir de fichiers plats. Essayez de réaliser vos POC de solutions tierces en “conditions réelles” c’est à dire en étant connecté directement à BW/4HANA ou HANA.

5- Le choix d’une solution non adaptée aux usages : il peut être tentant de faire porter tous vos usages BI par la mise en place d’une unique solution de reporting orientée dataviz. Cependant, comment adresser les besoins en exploration de données à un niveau opérationnel ? Attention à bien écouter les besoins de vos utilisateurs et à choisir les outils adaptés.

6- La séparation des équipes : il n’est pas simple de trouver des développeurs “couteau suisse” experts sur BW/4HANA et une solution de reporting tiers. Attention à ne pas mettre en place une organisation trop “rigide” dans laquelle des ressources d’une équipe doivent réaliser le modeling et une autre les rapports.

7- Des performances pas au rendez-vous : certaines fonctionnalités du moteur OLAP ne sont pas utilisables via l’interface MDX. Ainsi vous pourrez avoir des surprises et observer des temps de réponse différents entre RSRT et vos rapports utilisant la couche MDX

8- Une chaine de traitement de la donnée compliquée : si le niveau d’intégration ne vous satisfait pas, il se peut que vous décidiez de pousser les données de BW/4HANA dans une autre base ou directement dans votre solution tierce. Dans ce cas : vous paierez 2 fois l’extraction et le stockage de données (une fois pour BW/4HANA et une fois pour votre solution tierce)

9- Une maintenance compliquée : il se peut que pour palier aux limites de l’intégration, vous développiez une “usine à gaz” spécifique dans HANA alors que ce besoin aurait pu être couvert de façon standard dans BW/4HANA.

10- Le support de SAP : n’attendez pas une réponse très précise de SAP sur les limitations liées à l’intégration. Ils n’auront la main que sur la partie des développements embarquée dans BW/4HANA, tout ce qui est de l’autre côté étant le cadet de leur soucis.

Notre avis

Les problématiques d’intégration sont souvent évincées trop rapidement par des arguments d’un autre ordre (prix des licences, ergonomie…). Cependant, celles-ci doivent être considérées en premier lieu afin de capitaliser sur votre architecture BW/4HANA et minimiser le risque sur vos projets de reporting.

Au vu des limitations en intégration, il est difficile d’imaginer une industrialisation des développements sur de l’intégration BW/4HANA & reporting non SAP. Même si votre projet n’est pas irréalisable sur le papier, n’hésitez pas à considérer l’ensemble des points de douleur attendus et des critères pour le choix d’une solution de reporting.

Un exemple chez Colissimo

Colissimo revient sur sa démarche avec la mise en place de SAP Analtycis Cloud et présente les différents enseignements dans une démarche de choix d’outils au travers de notre webinar.

SAP Analytics Cloud - REX avec Colissimo

Laisser un commentaire