Cartographie sur SAP BusinessObjects BI4 :
Statut, critiques, perspectives


Rédigé par Lamine FAYE, Viseo le 7 Septembre 2015

La majorité des besoins en capacités cartographiques émanant de clients concernent, au-delà de la complétude et de la précision de l'outil, l'intuitivité, la richesse graphique, mais aussi le plus de proximité possible avec les cartes grand public, de type Google. Tout en s'intégrant de manière harmonieuse avec les rapports classiques, l'outil cartographique est censé les illustrer, les compléter, les préciser, mais ne jamais constituer un rapport autonome à part entière.



WAD, ancêtre malgré lui

Lamine FAYE, Consultant SAP BI chez VISEO
Cependant, malgré la multiplication des demandes-clients et des applications SAP qui intégraient de la cartographie, il faut reconnaître que cette dernière restait d'une certaine manière, malgré les annonces répétées de partenariat entre SAP et des éditeurs tiers, l'arlésienne de la BI, de la data-viz en particulier. Ceci s'expliquait d'une part par le flou dont l'offre était couverte, mais aussi par la complexité de mise en œuvre des solutions (le premier expliquant sans doute le second). Solutions qui, in fine, ne correspondaient pas forcément à la maniabilité à laquelle les clients pouvaient s'attendre. En effet, les cartes développées avec le WAD restaient assez statiques, sans beaucoup de possibilités d'interactions utilisateur intuitives. La difficulté de déployer une application BI cartographique, complète et utilisable, avec Web Application Designer croissait avec la spécificité de la demande, et les capacités de personnalisation étendues du WAD se heurtaient très vite à la limite de l’utilisabilité. Le côté esthétique n'en était finalement pas le moindre mal.

Par conséquent, SAP a fait récemment le choix de remplacer cet outil, devenant vieillissant, en déportant l'essentiel de son offre géographique BI4 sur trois principaux outils. L'intégration cartographique, commencée avec le bientôt historique WAD, se poursuit en une palette d'outils intégrés/intégrables dans la plateforme SAP BI4, ainsi que nous l'allons voir.

Commencée avec le partenariat avec ESRI ArcView, l'intégration cartographique se développe aussi bien de manière native (dans HANA et Lumira) qu'au travers d'extensions (Google Maps, Centigon CMAPS, ESRI...). L'arrivée de BI 4.1 et de Lumira signe un grand pas dans ce sens, car les capacités d'extension par SDK et les services de cartographie sur la plateforme BI se stabilisent. Il devient ainsi possible de prototyper rapidement sur Lumira, avec un fichier plat ou un BEx, sans avoir besoin de la tonne de paramétrage nécessaire au WAD.

L'intégration native est poussée par l'offre HANA+ESRI sur Lumira, mais aussi par les MapApp intégrables dans Fiori Launchpad. Cette intégration native accuse cependant quelques limites :
- Le niveau de détail dans Lumira n'est pas personnalisable
- La reconnaissance automatique des zones est limitée au dictionnaire cartographique Lumira
- Pour Fiori, une modélisation cartographique de bout en bout est nécessaire dans HANA Studio

Ce dernier point reste un frein conséquent à l'agilité, et s'adresse plus largement aux clients dont le modèle de données est déjà établi au terme d'une phase plus ou moins longue de conception.

Rapport Design Studio au niveau de la rue

Trois outils, plusieurs cibles

Adressage des besoins par outil
Il apparait ainsi dans sa politique commerciale que SAP veut pousser l’adoption de Lumira pour le maquettage, mais aussi les rapports cartographiques. Ayant préjugé de la facilité de déploiement de telles solutions, SAP intègre désormais de manière native les cartes ESRI dans Lumira, mais intègre même le serveur Lumira dans la plateforme BI4 — ce qui en faciliterait l’adoption.

Cependant, si Lumira s’adresse à des end-users et à des data managers, l’outil devient limité dès que le besoin devient plus spécifique et plus précis. Il faut se résoudre dès lors à payer une licence ESRI supplémentaire pour l’acquisition de cartes plus précises ou à développer en spécifique l’extension adéquate. Sinon, se tourner vers un autre outil, soit en déportant dans HANA le modèle cartographique, soit en adoptant WebI ou Design Studio.

Ainsi, la segmentation des cibles que SAP promeut à dessein, que d’aucuns qualifient de flou artistique, est faite dans une relative cohérence. Si SAP positionne Lumira comme un outil de préparation, préalable à tout projet de modélisation précise, il s’escrime aussi à le positionner comme vraie réponse à des besoins cartographiques relativement simples. De plus, en se proposant de l’intégrer dans la plateforme BI4, la transition vers Design Studio — ou Webi par défaut — devient naturelle dès lors que le besoin se complexifie.

Classification par atout

Interchangeabilité ou complémentarité ?

Notation selon une échelle de couleur
Tout se passe donc comme si l’offre était ciblée, sans pour autant être fermée, avec des passerelles entre outils. Cette transition naturelle est aussi accentuée par le fait chacun des trois outils a ses défauts, relativement comblés par les deux autres, et HANA Fiori dans une plus large mesure.
Ainsi, si Lumira se limite au prototypage assez avancé, Design Studio le complète en rajoutant, avec l’intégration d’une extension Google Maps,
- un niveau de détail très avancé
- une recherche par adresse et non plus par coordonnées
- une personnalisation avancée des marqueurs et des couches des cartes.
Même s’il faut préciser que les trois outils sont extensibles via SDK, l’extension de Design Studio bénéficie d’un plus large support de la communauté, car plus ouverte. De plus, l’existence d’éditeurs tiers proposant des plugins sans cesse améliorés rassure sur l’intégration continue des outils.

Impacts sur la modélisation à prévoir

Avec l’étendue de l’offre, il n’est désormais plus besoin de modéliser en fonction de l’outil à adopter. La seule contrainte réside dans l’utilisation des coordonnées géographiques, dont Design Studio peut aisément se passer en se basant sur le moteur de reconnaissance Google Maps. Quelques points de précisions doivent cependant être soulevés :
- L’utilisation des chronopleth WebI impose une agréagtion des indicateurs par niveau de zoom. Ainsi, lors de la modélisation, il faut prévoir que des ratios dont le cumul a du sens.
- Les latitudes/longitudes nécessaires au positionnement géographique doivent être déclarés en caractère pour Lumira, ou même concaténés dans un seul champ afin de pouvoir être utilisées dans WebI.
- Lumira possédant sa propre intelligence pour la hiérarchisation des zones géographiques, il n’est plus nécessaire de définir une hiérarchie de pays à maintenir dans SAP BW.
- Il est nécessaire de privilégier des vues analytiques, des infosets et des fichiers plats en lieu et place des classiques infocubes. En effet, la préconisation est de rester agile pour ajuster rapidement le modèle, plutôt que d’avoir un modèle figé.

Limites et perspectives

Malgré l’étendue de l’offre, les outils n'ont pas encore su intégrer la capacité de personnalisation propre et inhérente au WAD, même s'ils le surpassent en termes d'utilisabilité. De même, la trop forte dépendance envers des éditeurs tiers de plugins, obligeant à un surcoût en licence et en compétence technique, peut être un frein non négligeable. Il serait logique de s’interroger sur la prochaine unification du SDK entre Lumira et Design Studio, mais même, de manière plus optimiste, entre Fiori et BI4. La cartographie étant déjà disponible sur HANA, l’intégrer aux vignettes Fiori serait une piste à envisager.



Dans la même rubrique :