Méga-tendance - Big Data

Le baril déborde. SAP n'est plus guère en mesure d'assurer tous les chantiers. L'innovation est une bonne chose, mais le rythme téméraire de SAP est disruptif. C'est maintenant que le "temps réel" prend sa revanche.

SAP a négligé son devoir de diligence envers les clients existants au profit de "Run Simple". Il en résulte de nombreux projets qui partent à la dérive et qui ne peuvent être sauvés que grâce à l'aide intensive de consultants et de partenaires externes.

Sans citer de noms, il y a des partenaires SAP qui ont loué la plupart de leurs consultants et programmeurs à SAP.

Il y a quelque temps, j'ai évoqué dans ces colonnes le cas d'un collègue du secteur commercial dont le système Hana était resté à l'arrêt pendant près de dix jours - il n'était donc pas encore productif.

Même SAP n'a pas pu aider, c'est l'intervention d'un expert Hana externe qui a fait redémarrer le système - en devinant bien qu'il s'agissait du partenaire SAP qui a également donné des ailes au fabricant de boissons gazeuses de renommée mondiale et qui était présent sur la scène Sapphire à Madrid en 2011.

Ces aides, ainsi que d'autres aides externes pour les chantiers SAP, ont pris une ampleur si spectaculaire qu'elles ont laissé des traces dans le bilan du premier trimestre de cette année.

Le directeur financier Luka Mucic a promis qu'il s'agissait de dépenses ponctuelles, et tout le monde à Walldorf a visiblement été choqué par l'ampleur du support externe.

Ce n'est pas sans une certaine jubilation que notre table ronde SAP a fait remarquer : "Maintenant, SAP aussi sent combien il est amer de payer des frais de maintenance pour le support d'entreprise.

Je ne suis pas d'accord avec le directeur financier de SAP, Mucic, lorsqu'il dit que les énormes dépenses financières pour l'aide externe aux projets SAP peuvent être localisées au premier trimestre de cette année. Nous ne sommes qu'au début d'une méga-évolution des données.

Si déjà 150 systèmes S/4 chez des clients nouveaux et existants dépassent les capacités de conseil de SAP, de sorte qu'il faut compter sur un soutien massif de la part de partenaires, à quoi peut-on s'attendre dans les années à venir ?

Dans une chronique précédente, j'avais déjà prédit que l'échéance de 2025 serait dépassée. En raison des ressources disponibles, cette date ne pourra être respectée ni par SAP lui-même, ni par ses partenaires, ni même par ses clients existants.

Notre Stammtisch peut être un bon baromètre : certains ne sont pas hostiles au concept "Hana & S/4", mais cette année et l'année prochaine seront marquées par de petits PoC, puis une phase d'évaluation commencera, des moyens budgétaires devront être mis à disposition et un changement de version pour l'infrastructure, pour Linux, pour Hana, pour Abap et pour l'ERP devra être planifié.

De même, les Mega Data doivent être planifiées : Nous avons organisé une conférence interne avec les responsables de la production, les responsables CCC, les CDO et les CIO. L'un des thèmes était l'IoT et la gestion des volumes de données. Nous possédons des fraiseuses CNC qui fournissent jusqu'à deux téraoctets de données par jour.

Les données doivent-elles être transférées ou rester sur place ?

Est-il possible de mettre à disposition localement suffisamment de mémoire et de puissance de serveur pour effectuer des évaluations et des interactions en temps réel ?

Les machines CNC modernes sont extrêmement rapides. Que se passe-t-il si la ligne de données est trop fine et Hana trop lent ?

Nous avons trouvé de bonnes réponses à la plupart des questions, mais une méga-question de données est restée en suspens à la fin : que ce soit en local ou en cloud computing, que faire des quantités de données - et qu'est-ce qui doit, doit, peut être archivé ?

Hana est suffisamment rapide pour l'IoT, mais les données CNC ne peuvent pas y être stockées, ni archivées dans IQ/ASE, car la licence est beaucoup trop chère. SAP lui-même connaît ce défi et a fait plaisir à la communauté avec Vora, un moteur de requête en mémoire.

Vora s'appuie sur le framework d'exécution Apache Spark et permet des analyses de données Hadoop. Malheureusement, nous atteignons déjà les limites d'Hadoop et nous aurons donc besoin d'autres alternatives dans un avenir proche. Hadoop combiné à Hana est excellent, mais l'IoT est un projet de méga-données.

Je pense qu'il s'agit d'un concept similaire à la collecte de données du centre de recherche international Cern. Nulle part ailleurs, il n'y a autant de données de capteurs que dans les détecteurs souterrains du Cern.

Il y a deux défis à relever dans ce domaine : la quantité et la vitesse.

La capacité de stockage des centres de calcul du Cern est loin de suffire pour le flot de données généré en très peu de temps. On a donc recours à une astuce théoriquement simple : trier et oublier avant de stocker.

Dans la pratique, ce processus est extrêmement complexe et ne peut être maîtrisé qu'au prix d'un effort technique maximal - mais le principe est convaincant et pourrait également nous aider pour des milliers de machines CNC. Avant que Hana/Hadoop ne mette la main sur les données, il faudrait donc faire le ménage. Est-ce que quelqu'un chez SAP a pensé à cela ?