Préparatifs pour le voyage Hana

L'expérience montre que : Dans le contexte de l'ERP, Hana aide plutôt dans des scénarios spécifiques qui peuvent être accélérés par la technologie en mémoire. Il s'agit aussi bien de classiques comme l'analyse du résultat et des segments de marché ou les systèmes d'information logistique que de processus à long terme comme la gestion des salaires dans les ressources humaines ou la planification des besoins en matériel.

Certains modules et processus pour Hana doivent actuellement être optimisés. Pour d'autres applications, SAP entame un renouvellement complet. La première d'une série de "S-Innovations" est SAP Simple Finance. D'autres solutions basées sur Hana sont prévues.

Dans le domaine des entrepôts commerciaux, c'est différent. Une simple migration 1:1 d'une base de données classique vers Hana peut améliorer considérablement les performances. Bien entendu, cela ne transforme pas automatiquement un mauvais modèle de données en un bon modèle efficace.

Une migration peut être une première étape simple pour obtenir des "quick wins" dans le domaine de la performance et du fonctionnement du système. Mais elle devrait toujours être associée à des projets d'accompagnement - du housekeeping à la gestion des données (nearline storage ou smart data access) et à l'optimisation du code jusqu'au monitoring du système ou à l'alerting. Une simple migration vers Hana est une bonne première étape, mais elle est loin d'augmenter le potentiel existant.

Il ne fait aucun doute que Hana est une grande réussite, mais il ne s'agit "que" d'une base de données. Si la modélisation des données n'est pas optimale, cela peut aussi réduire les performances de Hana. Dans certains cas, la plateforme fonctionne même plus lentement que l'ancienne base de données "classique".

La raison en est que, dans les systèmes SAP, une grande partie de la charge de travail reposait jusqu'à présent sur les serveurs d'application, raison pour laquelle les programmes ont été conçus dans ce but. Si les systèmes SAP fonctionnent désormais entièrement sur Hana afin d'exploiter la vitesse de la technologie in-memory, il est recommandé d'adapter la modélisation des données et, le cas échéant, le code Abap.

Fonctionnement simple en tant que base de données

Dans la pratique, Hana est facile à exploiter en tant qu'entrepôt de données, par exemple en remplacement d'une base de données traditionnelle. Il n'est pas nécessaire de disposer d'un grand nombre de moteurs spéciaux ni de Hana-Studio.

Tous les clients SAP peuvent profiter des avantages, en particulier en ce qui concerne la vitesse et la flexibilité qui en découle dans le reporting, surtout dans l'environnement BW.

Le mythe d'une "migration coûteuse vers Hana" n'est pas fondé. Mais dans la pratique, les entreprises utilisatrices de SAP associent généralement les projets de migration à d'autres projets qui auraient dû être réalisés depuis longtemps.

Les classiques pour cela sont les consolidations de systèmes, les harmonisations, les mises à niveau, l'archivage/NLS, les conversions Unicode, l'externalisation ou encore les changements de processus. En raison de ces projets intégrés, les migrations vers Hana sont perçues à tort comme longues, coûteuses et difficiles à gérer.

Sur demande ou sur place ?

Les entreprises utilisatrices de SAP peuvent utiliser Hana aussi bien à la demande que sur site. Même dans la variante on-premise, les entreprises peuvent exploiter la technologie avec un effort raisonnable.

Elles profitent du fait qu'elles peuvent mieux contrôler Hana et acquérir une expérience précieuse. Pour d'autres entreprises, l'alternative à la demande est plus appropriée. Elles devraient alors vérifier le contrat, y compris les accords de niveau de service convenus.

En tout état de cause, l'introduction de Hana et la réalisation d'une migration nécessitent un peu plus que la simple migration du système d'exploitation ou de la base de données.

Grâce à la technologie in-memory, le modèle de données et l'exploitation du système doivent être adaptés pour que le système soit prêt pour l'avenir.

Ne pas migrer toutes les données

Lors de l'introduction, les coûts matériels et logiciels représentent le plus grand défi pour les entreprises. De plus, le stock de données ne cesse de croître alors que leur valeur diminue.

La clé à ce stade est la migration sélective du système vers Hana. Celle-ci permet non seulement une introduction simple, mais aussi une réduction de la taille du système, une amélioration des performances de chargement et une diminution des coûts d'exploitation.

Au lieu de simplement copier l'ensemble du système, un système vierge est créé sur la base du modèle de données du système productif - mais sans données de transaction ou données maîtres.

Les données sont migrées vers le nouveau système Hana en fonction de critères de sélection prédéfinis, tels que des critères temporels ou organisationnels. Les données critiques pour l'entreprise restent toujours accessibles en temps réel.

En même temps, cela permet de réduire le coût total de possession (TCO), car seules les données pertinentes sont migrées et l'ensemble de l'environnement SAP est simplifié.

Dimensionnement efficace de Hana

Pour le dimensionnement du matériel de l'appliance Hana, il existe différentes possibilités d'effectuer le dimensionnement dans l'environnement "non Hana" :

• Hana Sizing avec l'outil QuickSizer - un outil basé sur le web qui peut être exécuté via SAP Service Marketplace.
  Dimensionnement Hana avec des scripts spécifiques à la BD - Téléchargement via SAP Note 1637145 - SAP BW on Hana : Sizing SAP In-Memory Database
• Dimensionnement Hana avec un rapport Abap - Téléchargement via SAP Note 1793345 - Dimensionnement pour SAP Suite on Hana
• DataVard BW Test de fitness
  - Preuve de concept pour le projet de migration
  projet sur Hana

Le rapport Abap est la norme

La plupart des entreprises utilisatrices de SAP utilisent le rapport Abap. Il vérifie tous les objets (tables, tailles) dans l'environnement "non-Hana". En se basant sur les résultats, le rapport Abap propose un sizing dédié.

Cela comprend entre autres la mémoire pour le Row Store, la mémoire des colonnes, la mémoire des lignes, le CPU, les disques, etc. La sortie pour le rapport Abap se présente par exemple comme suit :

Le rapport Abap ne calcule pas avec la technologie ADK (Archive Development Kit). Dans une entreprise, cela a par exemple entraîné la perte de 6 To de données dans des fichiers archivés.

Dans ce cas, Hana était trop petite dès le départ. De plus, le rapport Abap ne se référait pas à la base de données "Deep Compression" (à l'exception de la compression DB2).

Conclusion

Hana n'est pas la panacée, mais la technologie in-memory est une base de données extrêmement rapide. Elle apporte de grands avantages aussi bien dans le domaine ERP que dans celui des entrepôts commerciaux.

Les entreprises seraient bien avisées de profiter de ces avantages. Mais elles devraient en tout cas réfléchir au préalable à l'utilisation qu'elles veulent faire de Hana. Elles pourront ainsi en déduire une gestion des données impérative.

La grande question est la suivante : quelles données doivent être conservées en temps réel dans la mémoire principale ? C'est pourquoi la gestion des données et la gestion du cycle de vie de l'information deviennent de plus en plus importantes.

Il ne fait aucun doute que l'avenir appartient à Hana. Mais la plupart des entreprises utilisatrices de SAP doivent encore s'y préparer efficacement. Car même lors des migrations vers Hana, la préparation est essentielle.