Introduction
Les solutions RapidViews ont pour objectif de proposer un véritable accélérateur de déploiement de vos projets décisionnels SAP HANA mais également de les gérer et de les maintenir. Les RapidViews sont composés de datamarts virtuels ou comptoirs de données, de rapports prédéfinis et de tables de fait/dimension (Vues HANA), c’est le socle de la solution. Ils sont disponibles sur les modules de l’ERP SAP FI-CO, SD, MM et PP.
Nous estimons que la solution RapidViews couvre en moyenne 70% des besoin BI du client une fois installée. Pour couvrir les 30% de besoins restants et ainsi satisfaire l’ensemble des demandes additionnelles des clients, nous proposons de les accompagner dans la réalisation des développements.
Pour cela nous utilisons une méthode qui se décompose en plusieurs étapes :
- Dans un premier temps nous travaillons en collaboration directe avec le client pour comprendre son besoin. Cette étape aboutit grâce à un outil inclus dans les RapidViews à la génération de spécifications techniques.
- En même temps, grâce à ce même outil, nous déterminons la liste des demandes qui sont déjà couvertes par les RapidViews et celles qui devront être ajoutées au modèle.
- Enfin, une fois les développements sous HANA Studio, et le reporting achevé nous procédons à la recette des données.
Use Case – Réalisation d’une vue additionnelle pour le carnet de commande
Pour illustrer cette méthode nous allons présenter le travail réalisé chez un de nos clients dans le cadre de déploiement BI sur les ventes (module SD).
Le client a exprimé le besoin de créer des reporting opérationnels « Order-to-Cash » (OTC or O2C), c’est à dire contenant l’ensemble des données du flux SD : commande, livraison, et facturation.
Présentation des RapidViews SD
Commençons par présenter les RapidViews du module SD.
Il existe 4 vues de base :
- La vue des documents de vente (F_SALES_ORDER_DV)
- La vue des livraisons (F_DELIVERIES_DV)
- La vue des factures (F_BILLING_DV)
- La vue des échéances de livraison (F_SCHEDULE_LINES_DV)
Autour de ces 4 vues principales gravitent d’autres vues annexes :
- Une vue pour le calcul de l’OTIF des ventes (F_OTIF_DV), basée sur une jointure entre la vue des commandes et la vue des livraisons. Cette jointure nous permet de calculer l’OTIF, un indicateur représentatif du ratio de livraisons livrées dans les délais et les quantité voulus.
- Une vue affichant le reste à livrer (F_BACKLOG_DV).
- Une vue contenant le flux des documents SD (F_SD_FLOW_DV)
Inscrivez-vous à la newsletter Rapid Views !
Soyez notifiés de nos derniers articles de blog, de nos prochains webinars et nos actualités !
Résumé des spécifications
On note que les RapidViews contiennent les vues dont nous avons besoin pour répondre au besoin « Order-to-Cash ». En effet les vues des commandes, livraisons et factures ont été installées chez le client clés en main.
On remarque aussi que ces vues sont indépendantes, or l’intérêt d’une vue « Order-to-Cash » est de remonter les données des trois vues citées précédemment au sein d’une seule et même vue, et d’y ajouter des calculs d’indicateurs et des règles métiers propres à notre client.
L’objectif des développements additionnels est donc de créer une vue « Order-to-Cash » que nous appellerons F_ORDER_BOOK, qui réalisera la jointure entre les commandes, les livraisons, et les factures, et qui inclura les règles métiers propres à notre client.
La vue F_ORDER_BOOK fera partie de la couche des vues supérieures aux RapidViews :
Développements HANA
Toutes les vues SD contiennent dans leur liste de champs le N° du Document de vente et N° du Poste du document de vente. Les jointures requises dans F_ORDER_BOOK sont donc réalisables en utilisant ces deux champs.
Il existe tout de même une petite subtilité concernant les jointures. En effet nous souhaitons que la vue finale ait une maille au niveau poste de commande (une ligne par poste de commande). Comme il est possible de trouver plusieurs postes de livraisons pour un même poste de commande, il y a un risque de dupliquer les postes de commande. Pour parer à ce problème nous avons un travail à faire en amont de la jointure, qui consiste à filtrer sur un poste de livraison par poste de commande.
La règle chez notre client dans ce cas de figure est : de garder les attributs de la livraison la plus récente par poste de commande et d’agréger les indicateurs de tous les postes de livraisons par poste de commande.
En développement HANA cela se traduit par la création de deux branches en sortie de la projection 3 vue des livraisons (c.f. schéma ci-dessous) : une branche pour classer les livraisons et filtrer ces dernières sur la date de création (Projection_6), et une branche pour agréger les indicateurs.
Extrait du schéma de la Calculation Views HANA : F_ORDER_BOOK
Nous rencontrons aussi ce type de cas pour les factures, c’est pourquoi nous avons développé un schéma identique sous la jointure des factures.
Voici la version finale de la vue F_ORDER_BOOK dans SAP HANA Studio :
Nous retrouvons principalement les éléments suivants :
- Une jointure entre les commandes et les livraisons
- Une jointure entre les commandes et les factures
- Des colonnes calculées au sein de la dernière projection. Voici quelques exemples de calculs :
- Statut du poste de commande :
- Quantités restantes à facturer
- Date de livraison prévue
- ….
Les développements HANA se clôturent par la réalisation d’une vue datamart qui a pour fonction de jointer à notre nouvelle vue de Fait (F_ORDER_BOOK), les multiples dimensions ou axes d’analyse nécessaires à la réalisation de notre rapport. Les vues de dimensions peuvent elles aussi être sujettes à des développements additionnels à la demande du client (hiérarchies complémentaires, Règles métier propre au client, …).
Reporting sur Power BI
Les vues HANA construites dans la partie précédente sont désormais exploitables sur les outils de reporting comme Web Intelligence de SAP BusinessObjects, Analysis for Office, Power BI de Microsoft, Tableau Software, …
Ci-dessous un exemple du tableau de bord : Carnet de Commande, réalisé sur Power BI
La partie gauche du rapport affiche les filtres utilisables dans ce rapport : année de commande, organisation commerciale, client et article.
Le camembert ou « Pie chart » nous donne le nombre de commande par statut :
- Facturé : commande avec un ID de livraison et un ID de facture
- Encours distribution : commande avec un ID de livraison uniquement
- Encours carnet : commande sans ID de livraison ni d’ID de facture
La courbe à droite du rapport affiche l’évolution du nombre de commande « En cours » dans le temps (Encours carnet et Encours distribution) en fonction de la date de création de la commande.
Le graphique en bas à gauche rappelle les clients pour lesquels des commandes sont en cours (trié par nombre de commande).
L’histogramme en bas à droite permet de comparer les montants commandés et les montants facturés.
Conclusion
La vue “Order-to-Cash” que nous avons réalisé est une des vues les plus complète du module SD car elle réunit les données des documents de vente (contrat, commande, etc.), des livraisons et des factures. Elle permet de déployer des indicateurs globaux sur l’activité des ventes.
Par exemple, au sein du même rapport, nous pouvons comparer les quantités commandées, livrées et facturées, et nous sommes capable de détailler ces indicateurs jusqu’au niveau du poste de commande via des fonctions de Drill Down ou d’exploration.
Les développements additionnels ne sont pas toujours identiques, certains peuvent nous demander d’ajouter des tables SAP dans le cas où les tables requises ne sont pas présentes dans les RapidViews Standard (Ex : tables Z_…). D’autres d’ajouter de règles de gestion spécifiques au client, des calculs de nouveaux indicateurs, …
Article rédigé par Alexandre ROHAN
