Nouvelle série de blogs de perspectives - 3: principaux défis de l'analyse intégrée à SAP HANA

3 Principaux défis de l'analyse intégrée SAP HANA

Bienvenue dans la série de blogs New Perspectives de TruQua. Cette série de blogs offre aux consultants une plateforme leur permettant de partager leurs points de vue, leurs idées et leurs expériences sur les technologies émergentes telles que SAP HANA et SAP Analytics Cloud.

Cette semaine, nous allons parler à Laura Rossi. Laura est consultante chez TruQua. Elle est spécialisée dans l'utilisation des fonctionnalités d'analyse intégrée de SAP HANA afin de générer des rapports et une planification extrêmement utiles dans SAP S / 4HANA et SAP Analytics Cloud (SAC). Aujourd'hui, Laura et moi-même allons discuter de trois défis clés auxquels sont confrontés les clients SAP HANA et de la façon de les surmonter.

Ces défis proviennent d'implémentations matures où TruQua a d'abord été engagé après la mise en production pour aider le client. Nous voulons couvrir non seulement le correctif, mais également la cause fondamentale des problèmes présentés et la manière dont nous avons veillé à ce que les défis du client ne reviennent pas.

Challenge 1 - Le débit énorme d'HANA

JS Irick: Sans hyperbole, HANA est l'outil que de nombreux scientifiques et analystes financiers ont attendu toute leur carrière. HANA gère facilement le journal universel - des milliards d'enregistrements avec des colonnes 300 +, condensant des centaines de tables ERP en une seule structure plate.

Cette puissance exceptionnelle entraîne des risques - dans le cas d’un engagement, nous avons constaté qu’une seule requête nécessitait une mémoire 700; chez un autre client, des milliards d'enregistrements ont été transmis à la couche SAP NetWeaver, menaçant à plusieurs reprises la stabilité de la production.

Comment conseillez-vous les clients de tirer pleinement parti des atouts de HANA, tant du point de vue du développement que des tests?

Laura Rossi: Comme vous l'avez mentionné, JS, HANA a la capacité de traiter des tables volumineuses en quelques secondes, ce qui permet aux utilisateurs de créer des vues complexes et volumineuses sur leurs données, d'ajouter des calculs, de filtrer, de reformater, etc. et de les stocker dans une seule et même structure. Cependant, le fait que nous peuvent créer des requêtes volumineuses et complexes ne signifie pas nécessairement que nous devrions exploiter ce pouvoir à chaque tournant. Les inefficiences s'aggravent rapidement, ce qui conduit à des exigences de mémoire telles que les systèmes de surcharge et de crash, en particulier s'il s'agit de scénarios en bac à sable ou de tests avec des allocations de mémoire limitées. Sur mon dernier client, une seule requête inefficace est parvenue à ralentir notre système de développement de manière très sensible jusqu'à ce que nous l'ayons identifié et repensé. Quelques heures à repenser la requête du coupable ont converti une requête très lente en pannes fréquentes en un processus qui s'exécute maintenant en environ une minute.

Certaines exigences de modélisation nécessitent des requêtes volumineuses et gourmandes en mémoire, que HANA peut gérer. L'important est de ne pas composer de demandes inutiles autour des demandes réelles et nécessaires. Personne ne veut attendre les minutes 15 pour exécuter une requête pouvant être exécutée dans 1.5.

De plus, certaines optimisations sont simples et basées sur les principes classiques de conception de bases de données. Par exemple, au lieu d'enchaîner un certain nombre de jointures externes pour attribuer des détails fragmentés, le même scénario peut être décomposé en différents cas en fonction de la façon dont l'attribution change, des attributs qui s'appliquent ou non, et de la façon dont ils sont gérés avec des jointures internes. et filtres. Si un critère de sélection complexe nécessite une jointure ou une transposition, il convient de consacrer un peu de temps à évaluer si une autre forme de détail ou de calcul peut servir le même objectif. Ainsi, lorsqu'un besoin nécessitant une grande quantité de mémoire doit être traité, nous insérons ces demandes de mémoire en plus du modèle le plus simple et le plus efficace possible, sans aggraver l'inefficacité.

JS Irick: Vous avez abordé un point très intéressant ici, à savoir le conflit fondamental qui existe entre les vues "à des fins" et "les entrepôts de données". Le premier peut survivre à un problème de filtrage ou deux, mais le dernier requiert la perfection sur l’ensemble de la pile. Outre les avantages sémantiques évidents liés à l'utilisation de vues CDS (Core Data Service), le fait même qu'elles mettent davantage de garde-corps et de rigueur autour des vues HANA en font une option très intéressante pour assurer la stabilité.

D'un point de vue pragmatique, je suis un grand partisan du volume de production (pas de données, mais du volume) en développement. Pour les requêtes complexes, vous devez être capable de voir vraiment l'impact.

Laura Rossi: Je suis d'accord. Encore une fois, lors de mon dernier client, nous avons eu la chance d’avoir un échantillon de données volumineux dans un système sandbox à mémoire relativement faible. J'appelle cela de la chance car cela a permis à notre équipe de concevoir en gardant la simplicité et l'efficacité à l'esprit dès le premier jour, plutôt que de tout construire puis d'optimiser. Le problème avec HANA est qu’il est suffisamment puissant pour exécuter la requête inefficace. Mais encore une fois, cela ne signifie pas que cela devrait l'être. Une autre fonctionnalité utile est la console SQL de HANA, qui vous permet d'analyser la demande en mémoire ou le «coût des sous-arbres» d'une vue et de tous ses sous-composants.

Challenge 2 - Manque de “HANA Gurus”

JS Irick: Pendant près de 40 années, SAP était agnostique à la base de données, les meilleures pratiques garantissant que les experts SAP restent dans la couche application.

Ce pare-feu, qui n’était possible que grâce à l’excellente couche d’intégration entre NetWeaver et la base de données, a disparu. Nous disposons désormais d'un environnement de développement sans précédent pour les données financières enrichies sémantiquement. Nous avons également des équipes incroyablement talentueuses, avec une profonde compréhension des processus et des besoins de leur entreprise, mais pour qui le développement de bases de données est intentionnellement bloqué depuis deux générations.

Qu'est-ce qui était essentiel pour que vous deveniez aussi fort dans le développement de HANA et comment travailliez-vous avec des équipes de clients expérimentés pour les activer dans ce nouvel espace?

Laura Rossi: Une grande partie du paysage SAP évolue. SAC et S / 4HANA sont en train de redéfinir notre façon de concevoir les solutions et ce que les clients choisissent de hiérarchiser. Je dirais donc que le moment est bien choisi pour commencer à apprendre et à réapprendre. Bien sûr, S / 4HANA est basé sur HANA, mais même dans un cas comme SAC, la connexion à une base de données HANA est simple et peut augmenter considérablement les performances de la solution de génération de rapports.

Et s'il est vrai que nous ne pouvons pas exploiter la quantité d'expérience disponible pour d'autres solutions SAP plus anciennes, les meilleures pratiques d'analyse des données peuvent toujours être adaptées et exploitées pour constituer les meilleures solutions commerciales de modélisation dans HANA.

JS Irick: J'aime la positivité! La partie la plus enrichissante du travail de conseil consiste à voir les équipes de clients avec lesquelles vous travaillez acquérir de nouvelles capacités (et reconnaissance). «C’est le meilleur moment pour commencer à apprendre et à réapprendre», dit tout.

Pour ce qui est de savoir où commencer, d’un point de vue fonctionnel, je recommande toujours de trouver cette étape suivante. Vous ne cherchez pas à réinventer FP & A, vous cherchez à apporter de nouvelles compétences à votre expertise existante. Continuez à miser sur vos forces. D'un point de vue technique, je recommande aux clients d'apprendre de la même manière que chez TruQua. Vous devez être capable de tirer parti du visualiseur de plan et de vraiment comprendre comment la plate-forme exécute vos requêtes. De petits ajustements au niveau de la modélisation peuvent avoir un impact incroyable. Vous devez être en mesure de comprendre où se trouvent les goulots d'étranglement pour pouvoir les résoudre.

Laura Rossi: Tout à fait d’accord sur le visualiseur de plans, c’est un excellent endroit pour commencer à diagnostiquer les aspects d’une refonte qui aura l’impact le plus productif. De même, la première étape consiste à comprendre la lignée de vos données et à quelle étape d'une vue ou d'un modèle un calcul est effectué, et pourquoi. En plus de cela, tant que nous gardons une conception allégée à l'esprit, j'aime bien dire que plus il est simple, mieux c'est, tant du point de vue du dépannage futur que de celui de l'évolutivité.

Challenge 3 - Les complexités de la transformation en temps réel

JS Irick: Je ne pense pas qu'il soit exagéré de considérer le chemin de la base de données vers un système fermé. Le processus ETL (extraction, transformation, chargement) et les nombreuses couches d'agrégation, d'enrichissement et de conversion ont disparu avec le passage à S / 4HANA et à l'analyse intégrée, mais la complexité n'a pas disparu, elle est toujours présente dans votre CDS ou dans votre HANA natif. vues.

Les questions standard sur les rapports existent toujours, mais elles se trouvent maintenant dans une seule vue au lieu d'un diagramme d'architecture complexe:

  • Comment cache-t-on les données?
  • De quoi avons-nous besoin pour persister?
  • Comment gérons-nous la configuration?
  • Où sont les points d'extensibilité pour les nouvelles exigences?
  • Comment les modifications des données de base / de la hiérarchie sont-elles gérées?

Comment relevez-vous ces défis avec les clients et comment vous assurez-vous que votre solution leur appartient et qu'ils peuvent se développer?

Laura Rossi: En un sens, je pense que toutes les questions que nous abordons aujourd’hui reposent sur les mêmes principes d’une conception allégée et efficace. Être très clair sur les exigences, ce qui peut ou ne peut pas changer, ce qui a changé historiquement et où tout réside est la clé, alors dans ce sens, il faut commencer par les bases mêmes: examiner de près ce qui est requis et à quoi ressemblent les données pour les données réelles actuelles, les données de planification et les données historiques.

Ensuite, décomposer la modélisation des vues en «couches» de cas d'utilisation ou de scénarios facilite la traçabilité et le dépannage simple tout en réduisant la complexité. En d'autres termes, je recommanderais de créer plusieurs vues pour différents aspects de l'utilisation professionnelle, puis une vue «nœud supérieur» qui combine le résultat de ces couches plus petites. Une vue simple et efficace avec un scénario d'utilisation clair est plus facile à développer et à développer qu'une vue large et complexe combinant plusieurs scénarios de scénario d'utilisation.

JS Irick: J'aime beaucoup le fait que vous ayez présenté une architecture en couches d'un point de vue fonctionnel. (aussi que vous avez fait un signe sournois au développement agile / maigre).

Un développeur doit vraiment comprendre le cas d'utilisation du client, être capable de communiquer avec l'utilisateur et de répondre aux besoins et non aux besoins. Ensuite, pour aller au-delà, vous devez comprendre comment les besoins de l'entreprise peuvent évoluer avec le temps, ou vous vous retrouvez avec une solution fragile.

Il y a tellement d'endroits où laisser des crochets pour l'extension et la configuration - interface Web, XSA, via la couche BW, etc. Je hésiterais à définir clairement où ces points devraient se trouver. La gestion du changement d'un point de vue technique est rarement brillante, mais il vaut vraiment la peine de garder le plus possible «dans la langue du client» pour ainsi dire.

Laura Rossi: Je suis d'accord. Personnellement, je pense que la compréhension de l'analyse de rentabilisation et du «langage commercial» pour tout ce que j'ai construit est un domaine dans lequel j'ai dû apprendre le plus, tout en travaillant avec TruQua, et cela a vraiment porté ses fruits. La meilleure solution ne peut briller que si les utilisateurs le comprennent et en ont besoin. Et bien sûr, avoir une compréhension complète du cas d'utilisation dès le début vous évite de nombreuses retouches dans les questions-réponses. En fin de compte, la solution devrait fonctionner pour le client.

Conclusion

JS Irick: Merci beaucoup d'avoir partagé votre point de vue aujourd'hui, Laura. Les technologies émergentes dans le paysage SAP, notamment HANA, SAP Analytics Cloud, Leonardo et S / 4HANA, offrent aux consultants en début de carrière l’occasion de générer une valeur considérable. Je suis heureux que nous ayons un peu de temps aujourd'hui pour discuter de la manière dont vous aidez les clients à surmonter leurs plus grands défis. Merci de partager vos idées et je suis impatient de pouvoir vous reparler très bientôt!

Laura Rossi: Merci pour l'opportunité de partager! C’est vraiment un moment excitant pour faire partie de l’écosystème SAP et des conversations comme celle-ci créent de grandes opportunités pour la croissance et le partage d’idées. J'ai certainement beaucoup appris de tous les membres de TruQua, c'est donc un plaisir de participer à la conversation.

A propos de nos contributeurs:

JS Irick a le meilleur travail au monde; travailler avec une équipe talentueuse pour résoudre les défis les plus difficiles. JS est un conférencier de renommée internationale sur les thèmes de l'apprentissage automatique, de la planification SAP, de SAP S / 4HANA et du développement de logiciels. En tant que directeur de la science des données et de l'intelligence artificielle chez TruQua, JS a élaboré les meilleures pratiques pour les implémentations SAP dans les domaines de SAP HANA, de la génération de rapports SAP S / 4HANA et de la personnalisation de SAP S / 4HANA.

Laura Rossi est consultante SAP chez TruQua. Elle est spécialisée dans l'application de Data Science à la planification et à l'analyse financières. Laura est hautement qualifiée dans le développement d'applications de bases de données natives pour non seulement résoudre les problèmes actuels du client, mais aussi anticiper et s'adapter à ses objectifs futurs. Le travail de Laura dans la «pile de planification moderne» de SAP HANA, SAP S / 4HANA et SAP Analytics Cloud aide également à fournir une base pour la planification collaborative en entreprise.

Merci de lire notre premier versement dans notre Nouvelles perspectives série de blogs. Restez à l'écoute pour notre prochain article, qui mettra en vedette Andrew Xue, consultant SAP et ses connaissances en matière de planification d'entreprise collaborative.

Pour plus d'informations sur les services et offres de TruQua, visitez notre site Web à l'adresse www.truqua.com. Pour être informé des futurs articles du blog et figurer sur notre liste de diffusion, veuillez compléter le formulaire ci-dessous.

Découvrez comment Truqua peut vous emmener plus loin, plus vite, ensemble.

Notre Mission

Découvrez comment Truqua peut vous emmener plus loin, plus vite, ensemble.

info@truqua.com
312.525.8787