L'alternative de la base de données Hana

Après APO, Hana

L'invention SAP APO, Advanced Planner and Optimizer, n'était une révolution qu'en théorie. L'idée d'automatiser et d'optimiser les cycles MRP était bonne, mais les quantités de données issues de la production dépassaient les algorithmes APO. Comme souvent avant et après, le professeur Hasso Plattner a eu l'idée salvatrice : une petite base de données bien cachée dans la mémoire principale du serveur APO a accéléré le système et a fourni les chiffres de planification et leur optimisation en temps voulu sur les écrans des utilisateurs SAP. APO était sauvé !

A l'époque, SAP n'avait pas fait grand cas de cette étape technique. La balle était dans le camp de SAP, car il s'agissait enfin de faire d'APO un succès et de consolider la suprématie de SAP en matière d'ERP au-delà de la finance et du contrôle de gestion. La base de données en mémoire d'APO était donc considérée comme une fonction auxiliaire qui ne méritait pas d'être mentionnée.

Potsdam réinvente l'ERP

À l'Institut Hasso Plattner de l'Université de Potsdam, le professeur Plattner et ses étudiants réfléchissent de manière approfondie à ce que pourrait être un futur ERP. Une idée centrale était un nouveau comportement de temps de réponse en temps réel, c'est-à-dire un système ERP qui ne fait pas attendre l'utilisateur - voir le désastre APO.

Une fois de plus, Hasso Plattner est tombé dans le piège de la base de données In-memory Computing. Mais cette fois-ci, la base de données ne devait pas être cachée dans les profondeurs du système ERP, mais devenir la star de la communauté SAP en tant que système autonome ! La nouvelle base de données devait être utilisable de manière universelle pour tous les modules et systèmes SAP et devait toujours pouvoir fournir les réponses en temps réel. Une base de données SQL en mémoire a été développée à l'Institut Hasso Plattner.

Hana-only versus AnyDB

C'était un coup de génie de la part de SAP de ne proposer que Hana comme base de données pour le successeur de l'ECC S/4 avec le système d'exploitation open source Linux. Avec SAP R/3 et la Business Suite 7 (ERP/ECC 6.0), SAP n'était pas le seul à faire d'excellentes affaires, les fournisseurs de systèmes d'exploitation et de bases de données en faisaient naturellement autant. Oracle et IBM, en particulier, se sont réjouis des ventes élevées de bases de données sans effort de distribution notable.

Il y a plus de 20 ans déjà, Hasso Plattner déclarait lors d'une conférence de presse au CeBIT qu'il se concentrait sur l'ensemble de la chaîne de création de valeur, du bureau au serveur. Le résultat est maintenant visible après de nombreuses années : de Fiori à Linux et Hana jusqu'à S/4 et la plateforme informatique SAP BTP, la revendication de pouvoir est sans faille. N'est-ce pas ?

Bon chiffre d'affaires, mauvaise performance

Dans la phase de transition actuelle d'ECC avec AnyDB vers S/4 et Hana-only, SAP fait de très bons bénéfices, car de nombreux clients existants doivent exploiter pendant des années leurs bases de données Microsoft, IBM et Oracle, où SAP gagne aussi beaucoup d'argent, et doivent déjà payer les licences correspondantes pour Hana. Actuellement, de nombreux clients existants de SAP paient deux fois les frais de base de données.

Par nature, Hana ne peut pas tenir la promesse d'un système ERP en temps réel. Ceux qui peuvent se le permettre ont désormais toutes leurs données dans la mémoire principale du serveur S/4, ce qui accélère de manière sensationnelle les requêtes analytiques. Chaque solution de datawarehouse profite de Hana de manière inédite. Les utilisateurs SAP jubilent ! Mais tout autant de fonctions ERP sont indépendantes d'une vitesse théorique de la base de données. D'autres facteurs déterminent le comportement des temps de réponse, de sorte que le stockage très coûteux des données au moyen de Hana dans la mémoire principale S/4 n'apporte aucun avantage. Les clients SAP existants paient des licences Hana onéreuses sans contrepartie apparente.

Démocratisation par le BTP

Hana a ses heures de gloire dans le domaine analytique, de sorte qu'un système hybride pourrait probablement être la solution optimale pour les clients existants de SAP : Hana pour l'entrepôt de données et une base de données traditionnelle bon marché pour les fonctions ERP opérationnelles et de série, n'est-ce pas ?

Cette gestion hybride des données n'existe pas encore, mais la SAP Business Technology Platform avec les fonctionnalités de SAP Datasphere et les compléments open source comme Kafka-Apache pourrait ouvrir une voie. Il se passe beaucoup de choses dans le domaine de la gestion des données : Data Fabric, Data Lake et le Kafka-Apache mentionné plus haut offrent aux clients SAP existants sur les plateformes des hyperscaleurs des possibilités d'évitement pertinentes par rapport à Hana-only. Même les extensions et les modifications ERP au moyen de CAP, RAP et Steampunk ne dépendent pas singulièrement de Hana. Ceux qui veulent échapper à l'exécution forcée de Hana devraient s'intéresser à BTP, Datasphere, Steampunk et Open Source.