MAG 15-11 Management

Hana-Roadmapping – Die Daten-Falle

2015

Unstrukturierte Daten, das Internet der Dinge, maschinelles Lernen und Entscheiden: Für viele Kunden werden fünf, zehn oder 15 Jahre ins Land gehen, bevor die gesamte funktionale Bandbreite von Hana im Einsatz ist. Nur: Wer jetzt nicht über sein Zielbild nachdenkt, dem wird dann die Datenbasis dafür fehlen.

In diesem Artikel stellen wir ein Roadmapping-Modell für einen schrittweisen Einstieg vor. Neben Software, Hardware und entsprechenden Mitarbeitern braucht man für den Eintritt in die schöne neue Welt von Digitalisierung und Big Data vor allem eines: Daten.

Mit der Sammlung unverdichteter Rohdaten im Universal Journal, im Central Finance und im One Exposure from Operations Hub oder mit dem neuen, stark virtualisierten LSA++-Architekturmodell schafft die SAP derzeit geeignete Behältnisse für die Auswertung großer Datenmengen. Schade nur, dass deren Inhalt für statistische Analysen oft nicht zu gebrauchen ist.

Der Grund: Einerseits sind bestehende Geschäftsprozesse nicht an dieser Zielvorstellung ausgerichtet, andererseits hängt bei praktisch allen statistischen Verfahren die Aussagekraft von Stichprobenumfang und -güte ab. Will sagen: Wer sich jetzt über sein Zielbild in Sachen Digitalisierung und den Weg dorthin keine Gedanken macht, der steht in zehn Jahren datenseitig mit leeren Händen da.

Winshuttle

1. Migration

Für SAP-Kunden beginnt der Einstieg in die digitale Unternehmenssteuerung mit einer Migration von einer klassichen Datenbank wie Oracle oder MaxDB auf Hana. Diese reine Datenbankmigration führt dazu, dass Berichte und ausgewählte Funktionen (zum Beispiel Transformationen oder Aktivierungen im BW) deutlich schneller werden.

Außerdem stehen neue Schnittstellen (z. B. zu ereignisverarbeitenden Systemen oder zu Hadoop) zur Verfügung. Ohne neue Geschäftsprozesse liegen diese Schnittstellen aber erst einmal brach.

Ein Return-on-Investment aus einer reinen Datenbankmigration ergibt sich nur für den Fall, dass die Beschleunigung von Softwarefunktionen allein schon Nutzen stiftet.

Wenn zum Beispiel durch eine schnellere Aktivierung und durch den Wegfall einzelner Prozessschritte (zum Beispiel: Löschen und Neuaufbau von Indizes, Datenbankstatistiken und Roll-up) Ladeprozesse im BW um 50 oder 75 Prozent schneller laufen, dann kann dies zwei Konsequenzen haben:

Engpässe bei der Batch-Verarbeitung lösen sich in Wohlgefallen auf und entscheidungsrelevante Daten stehen der Fachseite schon früh am Morgen und nicht erst am Nachmittag zur Verfügung. Ersteres hilft vielleicht dabei, neue Hardware-Investitionen zu vermeiden, Letzteres mag zu besseren Entscheidungen führen.

2. Neue Funktionen

Ist die Umstellung der Datenbank erst einmal erledigt, lassen sich die neuen „Simple“-Lösungen der SAP einfach über das Switch Framework (SFW5) aktivieren.

Das Resultat: Weitere Geschäftsprozesse werden durch schlankere Tabellenstrukturen und Code Push-down beschleunigt und ganz neue Funktionen (zum Beispiel das neue Bank Account Management im Cash Management) bereitgestellt.

Nach der Migration ist es auch an der Zeit, kundenspezifische Lösungen Hana-fit zu machen. Logischerweise wird man sich hierbei zunächst einmal auf geschwindigkeitskritische Geschäftsprozesse konzentrieren.

3. Neue Methoden

Als Plattform und zentraler Hub für die Datenbereitstellung öffnet Hana Türen in Richtung Ereignisströme (Stichwort: ESP Plug-in for Hana Studio) und schwach strukturierte/unstrukturierte Daten (Stichworte: HDFS/MapReduce oder NoSQL).

Nur: Klassische ERP-Geschäftsprozesse haben keine Verwendung für derartige Daten. Entsprechende Wertpotenziale lassen sich nur durch die Umgestaltung bestehender Prozesse erschließen.

So wäre es etwa denkbar, Daten aus sozialen Netzwerken zur Betrugsprävention zu verwenden und fragwürdige Zahlungsvorschläge zwecks weiterer Analyse hervorzuheben.

Hierzu müssen aber Anwendungen (SAP Fraud Management, Business Rules Framework) eingerichtet und bestehende Applikationen (zum Beispiel: das Zahlprogramm/F110) eventuell erweitert werden. Der Kunde ist also noch stärker gefordert als beim „Tuning“ von Berichten oder Ladeprozessen.

4. Neue Algorithmen

Die durch Hana erreichbare Beschleunigung macht es möglich, bekannte Algorithmen anders als bislang zu nutzen oder neue, performanceintensive Algorithmen erstmalig einzusetzen.

Beispiel: Eine Segmentierung von Kunden nach Preissensitivität kann jetzt nicht nur einmal monatlich, sondern praktisch fortlaufend stattfinden. Anstatt – wie bislang – Basis- und Premiummarken mit klar definierten Zielgruppen unterschiedlich zu bepreisen, kann jetzt auch ein und dasselbe Produkt uhrzeitabhängig zu unterschiedlichen Preisen angeboten werden.

Mit der flächendeckenden Einführung einer digitalen Preisauszeichnung ist nach Fluglinien und Webshops auch der stationäre Handel jetzt dabei, die technischen Voraussetzungen für eine zeitorientiere Kundensegmentierung zu schaffen.

5. Neue Strategien

Sensordaten liefern rasch große Mengen an teilweise fehler- oder lückenhaften Daten. Das allein stellt eine große Herausforderung für klassische IT-Organisationen dar.

Hinzu kommt aber ein weiteres Problem: Das Internet der Dinge hat nämlich obendrein die – aus Governance-Sicht – äußerst unangenehme Eigenschaft, sich strukturell ständig zu verändern.

Ein Mittelklasse-Pkw kann momentan Daten aus etwa 100 bis 150 Sensoren liefern. Mit jedem Modellwechsel kommen neue hinzu, fallen alte weg oder ändern sich deren technische Eigenschaften.

Mit den Messeinheiten in einem Smartphone oder einem Pumpengehäuse sieht es nicht anders aus. Datenflüsse und Funktionen, die auf der Annahme stabiler Eingabedaten fußen, sind also schon vor dem Go-Live obsolet.

Um mit instabilen Rahmenbedingungen umgehen zu können, braucht es neue Architekturmodelle in der IT. Spätestens in dieser Phase steht eine grundlegende Neugestaltung der Datenarchitekturen und der Datenflüsse an.

6. Neue Paradigmen

Mit den Entwicklungsschritten 4 und 5 (in der Grafik) halten geschlossene Rückkoppelungskreisläufe – in Prozessleitsystemen längst Usus – Einzug in die Steuerung von Geschäftsprozessen.

Aber während ein Maschinenpark in der Produktion einen relativ stabilen Rahmen für die Definition von Regeln bietet, fallen Entscheidungen in Geschäftsprozessen in einer Umwelt, die sich stündlich oder minütlich grundlegend ändert.

Der Versuch, die Spielregeln dieser Umwelt in starren Regeln (und Customizing-Einstellungen) abzubilden, muss zwangsläufig scheitern. Über kurz oder lang werden Organisationen deshalb gezwungen sein, Entscheidungen an sich selbst anpassende (auto-adaptive) Algorithmen zu delegieren.

Das mag ungewohnt oder sogar furchteinflößend klingen. Wenn wir aber ehrlich sind, dann überlassen wir im Alltag Entscheidungen längst Algorithmen, von denen wir nicht mehr wissen, wie sie im Detail funktionieren.

Kaum jemand prüft jede Anweisung seines Navigationssystems auf der Karte nach, die wenigsten Disponenten werden wissen, wie die Bedarfsplanung im SAP ERP funktioniert, und nur wenige Flugpassagiere haben Bedenken, in eine Maschine einzusteigen, die bei schlechter Landebahnsicht vom Rechner und nicht von der Crew gelandet wird.

Daten als kritischer Erfolgsfaktor

Business Cases mit Mustererkennung und maschinellem Entscheiden sind mit heutigen Datenbeständen aber oft gar nicht umsetzbar. Musterkennende Algorithmen in der Betrugsprävention zum Beispiel brauchen saubere und granulare Daten aus vielen Hundert oder gar Tausend gut und klar strukturiert dokumentierten Fällen.

Um in einem, zwei oder drei Jahrzehnten über einen solchen Datenschatz zu verfügen, muss heute mit Architekturgestaltung und Sammlung begonnen werden. Internet-Giganten wie Amazon oder Google haben das längst erkannt. Den Pionieren von Big Data geht es in erster Linie darum, eine möglichst große Menge an Daten zu sammeln und flexibel strukturierbar zu verwalten.

Was sich mit diesen Daten dann später machen lässt, darüber kann man sich auch in zehn Jahren noch Gedanken machen. Vor diesem Hintergrund dürfte auch Googles Einstieg in die Automobilindustrie, die Robotik oder das Geschäft mit Haustechnik zu sehen sein.

In allen drei Fällen geht es nicht primär um den Verkauf von Hardware, sondern um die Herrschaft über die von der Hardware produzierten Datenbestände.

Fazit

Wer ein Haus baut, der beginnt nicht erst beim Verlegen der Dachziegel mit der Planung. Architektur und Design des Gebäudes werden definiert, schon lange bevor der erste Bagger auf das Grundstück fährt. Vielleicht entsteht die Vision sogar noch vor dem Grundstückskauf.

Natürlich wird es während der Umsetzung der Baupläne Anpassungen geben. Der Baugrund selbst hält die eine oder andere Überraschung bereit oder ein Fenster muss für eine bessere Aussicht ein paar Zentimeter verschoben werden.

Ebenso wie beim Bau muss aber auch eine Datenarchitektur nicht zwangsläufig starr sein. Für Kunden und Interessenten bietet Horváth & Partners ab Dezember 2015 ein Roadmapping-Bootcamp mit Videos und Webinaren an.

Hierbei werden wir uns intensiver mit der Frage befassen, wie flexible Datenarchitekturen für die Digitalisierung aussehen können.

Über den Autor

Michael Mattern, Horváth & Partners

Michael Mattern ist Projektleiter, Senior Consultant und Enterprise Architect bei Horváth & Partners, einer internationalen Managementberatung für Unternehmenssteuerung und Performanceoptimierung.

Hinterlassen Sie einen Kommentar