Nous, Censio, intervenons souvent sur S/4HANA pour remettre à niveau la Business Intelligence.
Le climat de ces missions n’est pas serein parce qu’elles n’étaient pas anticipées par les clients et par les intégrateurs, y compris dans une migration à partir de SAP ECC.
Alors, quelles sont les bonnes pratiques pour éviter ces désagréments ?

1) Les migrations ECC vers S/4HANA éludent la question du reporting

Une migration sans reporting avec S/4HANA est vouée au rejet.

Le reporting opérationnel standard est performant, mais insuffisant,
si on le compare à ce qui existait avant la migration.
D’où l’impression de régression.

Si vous utilisez du reporting spécifique Abap, c’est que vous n’avez surement pas eu vent des capacités offertes par S/4HANA.
D’où l’impression de stagnation.

On espère que votre reporting S/4HANA n’a pas cette tête ?

2) Les nouveaux projets S/4HANA passent (presque) par les mêmes étapes que les projets ERP d’il y a 20 ans.

Nous entendons parfois les constats :

  • « il n’y a pas assez de reporting livré avec l’application »,
  • « nous n’avons pas de tableaux de bord »,
  • « comment nous procédons avec S/4HANA ?
    par extraction des infos vers des bases de données tierces
    et une utilisation massive d’outils de visualisation
    avec des concessions faites à l’intégrité, la cohérence et la fluidité ».
Souvenirs, souvenirs …

Pris par le temps, vous n’êtes pas au courant que de nouveaux outillages existent,
vous foncez tête baissée et faites du vieux avec du neuf

ex : Ecran de reporting Fiori écrit en UI5,
ce qui peut poser des problèmes d’évolutivité, de pérennité et de maintenance,
comme avec de l’Abap !

Comment a-t-on pu en arriver là ?

Ce n’est pas le lieu de chercher des responsabilités,
mais la promesse de SAP de réunir en un environnement le transactionnel et le décisionnel
a été mal comprise ou mal interprétée.

Il faut se poser les questions, avant de formuler les réponses :

Que livre S/4HANA en standard en matière de reporting ?

S/4HANA est livré avec plusieurs milliers de rapports,
c’est-à-dire sur les données brutes en liste ou agrégées sur un seul domaine.
Dans son usage quotidien, il est probable que l’utilisateur trouvera ce qu’il recherche et que cela facilitera son expérience.

Il est probable que ces rapports ne satisferont pas le niveau d’exigence « analytique »,
c’est-à-dire une présentation formalisée destinée à être partagée.

Que faire pour atteindre le niveau d’exigence en matière de reporting « analytique » ?

Avant, on conservait et on organisait les données de l’ERP transactionnel et d’autres sources de données dans un entrepôt de données (Datawarehouse).

L’offre de SAP en ce domaine est SAP BW.
Elle a été largement utilisée avec les versions précédentes de l’ERP et décriée pour sa complexité. BW compte plus de 17 000 installations dans le monde.

Les autres ?
On imagine des datawarehouses non SAP et des extractions vers d’autres outils dont Excel en tête, suivi par une kirielle d’outils BI disposant de schémas de stockage appropriés.

Rappelons aussi une autre (fausse) bonne raison de constituer un Datawarehouse :
vous pensez qu’un système transactionnel n’est pas le lieu pour faire du reporting par peur de faire tomber votre outil productif ou de limiter les ressources pour des moments clés.

S/4HANA et la base de données HANA continuent de s’améliorer pour gérer ce type d’usage.
D’un point de vue ressources, il n’y a pas de contre-indication à faire du reporting « analytique ».

Apparaît donc « Embedded Analytics », la possibilité de calculer à la volée voire de stocker des informations destinées au reporting « analytique ».

Plus de contrainte technique, des vues multi-dimensionnelles virtuelles standard, un outil pour les modifier et en créer de nouvelles, une compatibilité naturelle pour consommer ces vues au sein même de la solution : alors, que manque-t-il ?

Rien sous 2 conditions : les données agrégées ne nécessitent pas d’être archivées (conservées en l’état) et toutes les données proviennent de la seule source S/4HANA.

Pour piloter la performance d’entreprise, S/4HANA ne répondra pas à ces exigences, pas mieux ni moins bien que ses prédécesseurs ou ses concurrents. Dans ce cas, il y a 2 stratégies envisageables: constituer un ou des entrepôts de données ou laisser les métiers extraire des systèmes opérationnels les données nécessaires.

4) Que faut-il faire de ce paradoxe ?

  1. Que faut-il faire de ce paradoxe ?

Le paradoxe est :

  • il n’est plus utile d’extraire les données de S/4HANA pour les analyser : voilà reformulée précisément la promesse faite par SAP en 2015,
  • il reste nécessaire de les extraire pour les archiver et les croiser avec d’autres sources de données.

De ce paradoxe est née une grande confusion.
Nous proposons d’en faire une source d’optimisation considérable.

Alors vous choisissez quel scénario ?

Toutes les utilisations de données internes à S/4HANA peuvent être produites sans quitter S/4HANA, avec un outillage très performant mais plutôt destiné à des experts : reporting standard, Embedded Analytics, tuiles fiori, SAC, etc.

Nous rappelons qu’il est possible de faire sans ces outils mais que ces derniers permettent de simplifier les modèles. A partir d’usages simples, ils deviendront des services au sein même de l’application permettant de la valoriser et, à terme, de favoriser l’innovation.

Si ces outils ne sont pas utilisés, vous aurez opté pour d’anciennes ou (fausses) nouvelles méthodes: reproduire vos développements Abap consommés par du Fiori, par exemple. Ou alors développer des extracteurs pour les dédier à une base de données. Ces méthodes appartiennent maintenant à une architecture passée et non fiable.

Les utilisations de données nécessitant un archivage ou un croisement avec des données externes nécessitent la mise en œuvre d’un entrepôt de données.
Nous favoriserons BW/4HANA, en particulier dans un environnement de données marqué par S/4HANA. Car BW est une solution raisonnablement efficace. SAP a dopé son entrepôt de données et l’a considérablement simplifié, tout en le couplant à S/4HANA.

5) Conclusions

Connaître votre cible permet d’intégrer le sujet reporting et analyses dans la démarche S/4HANA, que ce soit une migration ou un nouveau projet.
Nous pouvons vous aider à poser les questions dans l’ordre et à envisager les options.
Les réponses n’en deviennent que plus évidentes.

Ce faisant, la satisfaction à la livraison de l’application sera meilleure,
les coûts de mise en œuvre du reporting / analyse seront mieux maîtrisés.

En connaissant cette cible et les options qui d’offrent à vous, il est plus aisé de faire des choix cohérents dans l’immédiat, car ces sujets continuent d’exister dans la période qui précède la migration vers S/4HANA.

Laisser un commentaire