Mega-Trend – Big Data
Das Fass läuft über. SAP ist kaum mehr in der Lage, alle Baustellen zu bedienen. Innovation ist gut und richtig, aber das waghalsige Tempo der SAP ist disruptiv. Jetzt rächt sich „Realtime“.
SAP hat zugunsten von „Run Simple“ ihre Sorgfaltspflicht gegenüber den Bestandskunden vernachlässigt. Das Ergebnis sind zahlreiche Projekte, die aus dem Ruder laufen und nur durch intensive Zuhilfenahme von externen Consultants und Partnern gerettet werden können.
Ohne hier Namen zu nennen, es gibt SAP-Partner, die den Großteil ihrer Berater und Programmierer an SAP vermietet haben.
Ich habe vor einiger Zeit an dieser Stelle von einem Kollegen aus dem Handelsbereich berichtet, dessen Hana-System fast zehn Tage stillstand – er war damit noch nicht produktiv.
Selbst SAP konnte nicht helfen, erst das Hinzuziehen eines externen Hana-Experten brachte das System wieder zum Fliegen – richtig geraten, es war der SAP-Partner, der auch den weltbekannten Brausehersteller beflügelt und 2011 auf der Sapphire-Bühne in Madrid stand.
Diese und weitere externe Hilfen für die SAP-Baustellen haben ein so dramatisches Ausmaß angenommen, dass sie Spuren in der Bilanz für das erste Quartal dieses Jahres hinterlassen haben.
Finanzvorstand Luka Mucic hat versprochen, dass es sich um einmalige Aufwendungen handelt, und jeder in Walldorf war offensichtlich schockiert über die Dimension des externen Supports.
Nicht ohne Schadenfreude hat unser SAP-Stammtisch angemerkt: Jetzt spürt auch SAP, wie bitter es ist, Pflegegebühr für Enterprise-Support zu zahlen.
Ich bin nicht der Meinung von SAP-Finanzvorstand Mucic, dass die enormen finanziellen Aufwände für externe Hilfestellungen bei SAP-Projekten sich auf das erste Quartal dieses Jahres lokalisieren lassen. Wir stehen erst am Beginn einer Mega-Data-Entwicklung.
Wenn bereits 150 S/4-Systeme bei Neu- und Bestandskunden die Consulting-Kapazitäten der SAP überfordern, sodass auf massive Unterstützung durch Partner gebaut werden muss, was kann in den kommenden Jahren erwartet werden?
Bereits in einer vorangegangenen Kolumne habe ich prophezeit, dass die Deadline 2025 gerissen wird. Der Termin ist aufgrund der vorhandenen Ressourcen weder bei SAP selbst noch mit den Partnern und auch nicht bei den Bestandskunden zu realisieren.
Unser Stammtisch kann ein guter Gradmesser sein: Einige sind dem Konzept „Hana & S/4“ nicht abgeneigt, aber dieses und kommendes Jahr wird durch kleinere PoCs geprägt sein, dann beginnt eine Evaluierungsphase, Budgetmittel müssen zur Verfügung gestellt werden und ein Releasewechsel für Infrastruktur, für Linux, für Hana, für Abap und für das ERP muss geplant werden.
Ebenso muss Mega Data geplant werden: Wir hatten eine interne Konferenz mit den Produktionsverantwortlichen, CCC-Leitern, CDOs und CIOs. Eines der Themen war IoT und die Bewältigung der Datenmengen. Wir besitzen CNC-Fräsmaschinen, die pro Tag bis zu zwei Terabyte Daten liefern.
Sollen die Daten weitertransportiert werden oder bleiben sie vor Ort?
Kann man lokal genug Speicher und Serverleistung zur Verfügung stellen, um Auswertungen und Interaktionen in Echtzeit durchzuführen?
Moderne CNC-Maschinen sind extrem schnell, was, wenn die Datenleitung zu dünn und Hana zu langsam ist?
Auf die meisten Fragen haben wir gute Antworten gefunden, dennoch blieb zum Schluss eine Mega-Daten-Frage offen: Ob lokal oder Cloud Computing, wohin mit den Datenmengen – und was muss, soll, kann archiviert werden?
Hana ist hinreichend schnell für IoT, aber CNC-Daten können hier nicht gespeichert werden, auch nicht in IQ/ASE archiviert werden, weil es lizenzmäßig viel zu teuer ist. SAP selbst kennt diese Herausforderung und hat die Community mit Vora, einer In-memory-Abfrage-Engine, beglückt.
Vora setzt auf dem Apache Spark Execution Framework auf und ermöglicht Analysen von Hadoop-Daten. Leider stoßen wir bereits an die Grenzen von Hadoop, sodass wir in absehbarer Zeit noch weitere Alternativen brauchen. Hadoop in Kombination mit Hana ist ausgezeichnet, aber IoT ist ein Mega-Data-Projekt.
Ich denke, dass es auf ein Konzept ähnlich der Datenerfassung beim internationalen Forschungszentrum Cern hinausläuft. Nirgends entstehen so viele Sensordaten wie in den unterirdischen Detektoren des Cern.
Hierbei gibt es zwei Herausforderungen: die Quantität und die Geschwindigkeit.
Nicht einmal annähernd reicht die Speicherkapazität der Cern-Rechenzentren für die Datenflut, die in kürzester Zeit entsteht. Somit bedient man sich eines theoretisch einfachen Tricks: Aussortieren und Vergessen, bevor gespeichert wird.
In der Praxis ist dieser Vorgang extrem komplex und nur mit höchstem technischen Aufwand zu bewältigen – aber das Prinzip ist überzeugend und könnte auch uns bei Tausenden CNC-Maschinen helfen. Bevor also Hana/Hadoop die Daten in die Hand bekommt, sollte man ausmisten. Ob daran jemand bei SAP gedacht hat?
