« BW/4HANA is coming, BW is dead … again ? »

Article | SAP Rédigé par

SAP vient d’annoncer la nouvelle solution BW/4HANA. Avec cette annonce ressort le schéma de simplification des objets BW, déjà présenté pour « BW Powered by HANA ».

Au delà des aspects techniques, propres ou non à SAP, plusieurs questions reviennent, presque comme un rituel du DSI face à sa BI :

Est-ce que le « Big Data » va tuer le Datawarehouse ? Pourquoi BW/4HANA ?
J’y vais ou j’y vais pas ? Si j’y allais, j’irais comment ?

Un peu d’historique SAP…

Si le futur peut sembler incertain, regarder vers le passé permet de prendre du recul sur les tendances de la « Roadmap BI » SAP.

On note plusieurs grandes étapes de simplification :

  • 2012 : version BW 7.3 Powered By SAP HANA :
    • Version applicative BW sur la plateforme HANA : « on ne change rien » à BW, mais les performances s’améliorent grâce à la nouvelle base de données.
  • 2013 : Version BW 7.4 Powered By SAP HANA :
    • De nouveaux modèles de données virtuels sont introduits (ex: Composite Provider, openODS), on peut commencer à simplifier la construction des flux de données.
  • 2015 : Version BW 7.5 powered by SAP HANA + add-on :
    • Début de l’intégration de BW dans HANA : les objets de simplifications BW sont disponibles dans le HANA Studio. Les scénarios de passage vers HANA se multiplient !
  • 2016 : SAP BW/4HANA
    • Les 2 offres sont là : le « BW classique » et le « BW big data ». La BI se confirme comme le terrain d’expérimentation de la nouvelle base de donnée HANA : en prévision de migrations de ECC vers S/4 ?

 

Si le calendrier reste difficile à prédire, on comprend la démarche « petit pas » de SAP, pour permettre à ses clients d’apprivoiser les possibilités de la nouvelle base de données.
Ce calendrier correspond à la fois à la maturité des sujets chez les clients SAP, mais aussi à l’évolution du marché du Big Data, notamment en parallèle du monde « Hadoop« , vis-à-vis duquel SAP cherche son positionnement (SAP présent au salon Big Data Paris de 2015 mais pas de 2016 ! Apparition de SAP HANA Vora qui ouvre en 2015 l’intégration à des flux Spark).

Est-ce que le « Big Data » va tuer le Datawarehouse ?

La « BI d’avant » = une photocopieuse

Dans la BI classique, la donnée est extraite (copiée) du système source vers un stockage intermédiaire (ETL / DSO) puis une fois validée, intégrée dans un Datawarehouse (nouvelle copie) puis préparée dans des Datamarts pour maximiser les performances du reporting (encore une !).
A chaque étage, on peut en profiter pour ajouter des règles de gestion, combiner avec des données d’autres sources, renforcer la gouvernance (workflow de validation ou de modification, habilitations et accès aux données).

La photocopieuse fait diverger les sources de données.

De plus, faire évoluer des modèles fonctionnels nécessite la modification de tous les étages de traitement et de photocopie pour ajouter de nouveaux éléments. L’IT est systématiquement dans la boucle, avec des délais parfois de plusieurs semaines ou de plusieurs mois, très loin d’une BI « self service » !

La « BI de demain » ?

Transformation digitale, big data, data lake, donnée non structurée… Une nouvelle vague d’innovation s’enclenche. Mais au final, pour faire quelque chose d’une donnée non structurée, il faut bien structurer quelque chose quelque part.

En tout cas, les performances de ces nouveaux systèmes rendent en grande partie obsolète la nécessité de « photocopier ». Les reporting peuvent aller attaquer et traiter les données en directe dans les systèmes source, voire carrément dans les bases de données sources (indépendamment des « applications »).

Par analogie, quand on installe une nouvelle application sur un Smartphone, l’application demande la permission d’accéder à l’annuaire, aux photos… Elle utilise et enrichit mais ne copie pas ces infos !

Dans la « BI de demain », on peut imaginer qu’on pourra non seulement consulter toutes les données de prod, mais aussi y ajouter des commentaires ou des règles de gestion ! Donc, finie la photocopie.

Dans ce scénario, comment la gouvernance va-t-elle être gérée ? Qui a le droit de consulter quoi ? Comment on administre la mise à jour des données ?

Avant, si la BI « tombait », la « prod » n’était pas touchée : casser le compte-tour ne cassait pas le moteur. Donc finalement, ce n’était pas si mal d’avoir un Datawarehouse pour faire tampon et gérer tout ça ?

A quoi sert BW/4HANA ?

D’un côté, rois de la « BI d’avant », BW et BO bénéficient d’un grand parc installé et d’un grand nombre de ressources disponibles pour intervenir en évolution et en maintenance.

De l’autre, HANA permet aux « bricoleurs » et au « magiciens » d’expérimenter des choses. Mais c’est encore un monde restreint, un peu « aride », réservé aux experts (pas beaucoup de retours d’expérience, pas beaucoup d’outils ergonomiques pour travailler, même si la couche « BO » n’est pas impactée).

Logiquement, il faudrait que les « outils pratiques » du monde classique BW migrent vers HANA. En revanche, pas besoin de tous les trucs qui servent à faire des photocopies. On va plutôt se concentrer sur la gestion (modèle de données, gestion droits, règles de gestion) mais de manière « virtuelle », « recalculée à la volée ».

Vers la simplification des anciens modèles BW :

Dans ce nouveau monde « équilibré », lors de la consultation d’un tableau de bord, la donnée va pouvoir être plus « fraîche » (c’est à dire prise directement à la source) mais aussi administrée et contrôlée (via les nouveaux outils et la puissance des nouvelles bases de données et du moteur de calcul).

Le but de BW/4HANA serait donc de récupérer les outils pertinents de BW (on parle par exemple de reengineering du code, de suppression de lignes d’ABAP …) et de les mettre à disposition d’une utilisation « virtuelle » sur base HANA. On ferait la synthèse du meilleur des deux solutions :

  • « côté HANA » : performance, gestion virtuelle des données et des calculs, fonction native de gestion d’intégration de données (Smart Data Integration), interface Big Data via SAP HANA Vora, intégration des données non SAP.
  • « côté BW » : administration et gouvernance claires des données et des flux (gestion des droits, catalogue fonctionnel, ergonomie de construction)

Est ce que cela signifie que c’est la fin des ETL et de la modélisation au profit de la lecture immédiate des données ? « oui », mais dans un monde idéal…

Le principe de SAP BW/4HANA est de créer des modèles de données source très larges, soit en extraction soit en lecture directe sur les sources opérationnelles. Mais ce principe restera limité aux problématiques de gouvernance, d’enrichissement et d’homogénéisation des données. L’objectif global est clairement de fournir de plus en plus d’agilité via cette nouvelle plateforme de Datawarehouse.

J’y vais ou j’y vais pas ? Si j’y allais, j’irais comment ?

Quelles sont les marches pour descendre dans la piscine ?

Il n’est pas possible de migrer directement sur BW/4HANA. Il n’existe pas encore d’outil. SAP est en cours de rédaction d’une documentation complète. Il existe des outils de conversion de flux vers une nouvelle plateforme vierge. Il faut donc appréhender cette nouvelle « version » comme une nouvelle solution de Datawarehouse chez SAP et privilégier des scénarios progressifs.

Si chaque situation demande une étude spécifique, nous avons essayé de représenter ci-dessous les scénarios auxquels nous avons pu être confrontés.

 

Dans la plupart des cas, les stratégies BW sur HANA vont cohabiter avec des projets plus avancés sur BW/4HANA. C’est un luxe qu’on peut envisager pour la BI. Cela risque d’être plus sportif pour la partie ERP !

Bref… si votre stratégie passe par HANA, mieux vaut se préparer à tester l’univers via la BI, et donc prévoir de passer vers du BW/4HANA.

Conclusion : coexistence BW/4HANA + BW

Avec cette nouvelle solution, SAP renforce nos convictions sur la nécessité du Datawarehouse. Par ces nouveaux modèles, SAP affiche clairement son évolution vers plus d’agilité et d’intégration du monde du Big Data et des objets connectés (IoT). Les délimitations entre le reporting opérationnel et décisionnel disparaissent progressivement. Les approches et expériences de modélisation vont être révolutionnées.

En attendant, à la vue du parc installé, BW est loin d’être mort, même s’il est clair que le but de BW/4HANA est de cannibalisé progressivement son ancêtre.

Par ailleurs, le débat sur les couches « en amont » (ETL) et « en aval » (reporting) reste ouvert.

Sur les ETL, entre SLT, SDI, BODS et autres, là aussi il faut faire son marché. D’ailleurs, la coexistence avec des solutions tierces (SSIS, Talend…) est tout à fait possible ! Est-ce le futur terrain d’attaque commerciale de SAP ?

Côté reporting, la fin du Bex Analyzer est un élément important à prendre en compte ! L’outil historique de reporting sur BW est définitivement abandonné (remplacé par Analysis for Office !). Ce n’est pas une grande nouvelle mais BW/4HANA acte la mort de son outil historique. SAP confirme l’utilisation des outils Business Objects de la roadmap (Lumira, Design Studio, Analysis, Business Objects Cloud).

La roadmap BW/4HANA est neuve. Mais SAP affiche clairement son intention d’une plateforme unique et continue d’inciter fortement ses clients à migrer vers HANA.

Cyril Leredde et Alexandre Candlot – Senior Consultants Manessens, Experts BI

Evénements Manessens

Découvrez nos prochains événements !

Portes Ouvertes - Nantes

04/07/2019 5:00
13 rue de la Rabotière - 44800 Saint Herblain

Expertise SAP

Depuis 2006, nous capitalisons notre expertise sur SAP : étude préalable, intégration, déploiement de Core Model, accompagnement MOA/MOE SAP, formation, migration & conversion S/4 Hana.

Nos prestations SAP
Manews Tous les mois recevez un zoom sur un cas client pour inspirer vos métiers, votre organisation
Inscription newsletter