Kommentar von Georg Aholt, NTT DATA Business Solutions Embedded Analytics, Enterprise Analytics oder beides?

Anbieter zum Thema

IBM Deutschland GmbH

Disy Informationssysteme GmbH

Sinequa

NTT DATA Business Solutions AG

In der Vergangenheit waren die Welt der Transaktionen und die Welt der Analysen strikt voneinander getrennt. Prozesse liefen in transaktionalen Systemen, für die Analyse von Daten kamen dezidierte Komponenten zum Einsatz: in der Regel unterschiedliche Storages und ein Data Warehouse als Backend sowie spezifische Modellierungs-, Analyse- und Visualisierungslösungen als Frontend. Dieser Dualismus resultierte unter anderem daraus, dass Datenbanken für Transaktionen (Online-Transaction-Processing; OLTP) andere Voraussetzungen erfüllen müssen als Datenbanken für Analysen (Online Analytical Processing; OLAP).

Mit SAP HANA wurde diese Zweiteilung überwunden. Denn die High Performance Analytic Appliance arbeitet gleichermaßen zeilen- und spaltenorientiert und eignet sich damit sowohl für OLTP- als auch für OLAP-Prozesse. Um das zu nutzen, hat SAP die In-Memory-Datenbank in das neue ERP-System SAP S/4HANA integriert. Und damit die bereits Anfang der 2000er-Jahre entstandene Idee von „Embedded Analytics“ realisiert. Für Analysen müssen Daten also nicht mehr über komplexe Mechanismen extrahiert und transformiert, in separate Analytics-Komponenten geladen und dort redundant gespeichert werden.

Unternehmen haben damit erstmals die Wahl: Setzen sie weiterhin oder künftig auf eine Enterprise-Analytics-Architektur – etwa mit SAP BW/4HANA, der SAP Data Warehouse Cloud (SAP DWC) und der SAP Analytics Cloud (SAC) als Analysetool. Oder entscheiden sie sich für die neuartige Embedded-Analytics-Architektur mit SAP S/4HANA?

Die richtige Wahl treffen

Eine erste Orientierung für die richtige Entscheidung bietet die Gegenüberstellung einiger spezifischer Merkmale. Die jeweiligen Stärken der beiden Architektur-Ansätze zur Kenntnis zu nehmen, ist ein erster wichtiger Schritt. Eine sinnvolle Entscheidung ist aber nur dann möglich, wenn Unternehmen in einem zweiten Schritt ihre aktuellen (und künftigen) Anforderungen kennen. Dazu schlagen wir vor, entlang von fünf Dimensionen eine Reihe von Leitfragen zu beantworten: Erkenntnisinteresse, Daten, Anwender, Kosten und Systemlandschaft.

Dimension 1: Erkenntnissinteresse

Das Erkenntnissinteresse lässt sich verstehen als Fundament für die übrigen vier Dimensionen und ist darüber hinaus ausschlaggebend für die Motivation, sich mit dem Umgang mit Daten zu befassen. Oder eben nicht. Um mehr Klarheit zu gewinnen, hilft ein Blick auf diese Aspekte:

Reifegrad

Bislang beschränkt sich die Analyse von Daten vor allem darauf, Daten aus der Vergangenheit zu Kennzahlen oder Key Performance Indicators (KPI) zu verdichten und diese in Berichten zusammenzustellen. Erkennen lässt sich also beispielsweise, wie hoch der Umsatz war – in einem bestimmten Zeitraum, in einer bestimmten Region, mit einem bestimmten Produkt. Diese Descriptive Analytics gibt damit Antworten auf die Frage, was passiert ist. Mittlerweile lässt sich mithilfe von Auswertungen auch beantworten, warum etwas passiert ist (Diagnostic Analytics), was passieren wird (Predictive Analytics) und wie Unternehmen etwas passieren lassen können (Prescriptive Analytics). Mit diesem steigenden Reifegrad nimmt auch der Umsetzungsgrad einer Data-driven Culture zu, die zu einer Steigerung der Wertschöpfung des gesamten Unternehmens führt.

Unternehmensbereich

Ein Großteil der Analysen bezieht sich bislang auf das Finanzwesen – allein schon deshalb, weil die Kennzahlen und KPIs für die Rechnungslegung – also für das externe Rechnungswesen – erforderlich sind. Eng damit verbunden sind die ebenfalls ziemlich üblichen Auswertungen im Vertrieb. Dieser kann die im Finanzwesen erzeugten Kennzahlen nutzen und mit vertriebsspezifischen Größen kombinieren. Insbesondere die jeweiligen Mitarbeiterinnen und Mitarbeiter und die Kunden sind dabei relevant. Darüber hinaus kommen Analysen zwar in allen möglichen anderen Bereichen eines Unternehmens zum Einsatz. Das aber fast immer deutlich weniger konsequent. Aus unserer Sicht bleibt damit eine Menge Potenzial ungenutzt.

Dimension 2: Daten

Einerseits wird durch das Erkenntnissinteresse maßgeblich definiert, welche Daten für die Analyse erforderlich sind. Anderseits gibt ein Überblick über die verfügbaren Daten Impulse für die Identifizierung nützlicher Use Cases – schränkt sie aber auch auf das Machbare ein. Um sich Klarheit zu verschaffen, bietet sich die Orientierung am 3V-Modell von Gartner an:

• Volume: Welches Datenvolumen soll verarbeitet werden?

• Variety: Welche Datenquellen (SAP-Systeme, Non-SAP-Systeme, IoT-Devices etc.) und welche Datentypen (strukturiert, unstrukturiert) sollen verarbeitet werden?

• Velocity: Welche Geschwindigkeit soll bei der Verarbeitung der Daten erreicht werden?

Dimension 3: Anwender

Analysen nutzen nur dann etwas, wenn die Anwenderinnen und Anwender auch damit arbeiten. In vielen Unternehmen war das nicht immer der Fall. Es wurden mit viel Aufwand zig Excel-Reports erstellt, die dann ungelesen auf den Festplatten verstaubten. Insofern sollte unbedingt geklärt sein, unter welchen Bedingungen die User den größten Benefit aus den Analysen ziehen – um die Akzeptanz und Nutzungshäufigkeit zu erhöhen. Anforderungen lassen sich vor allem daraus ableiten, welche Anwendergruppen was mit den Daten vorhaben.

Dimension 4: Kosten

Dass bei einer Entscheidung für eine Architektur auch die Kosten eine Rolle spielen, ist selbstverständlich. Die Identifizierung aller Kosten und deren Beurteilung ist es ganz und gar nicht. Denn zum einen muss eine Reihe von Faktoren beachtet werden. Zum anderen müssen die Kosten immer auch in Relation zum dadurch realisierten (monetär ausgedrückten) Nutzen gesetzt werden:

Capex oder Opex

Bis vor ein paar Jahren war es üblich, eine IT-Lösung zu kaufen und dafür Lizenzkosten zu zahlen. Es entstanden also Capex-Kosten. Mittlerweile gibt es etliche Subscription-Modelle, bei denen die Software nicht gekauft, sondern die Nutzung bezahlt wird – und damit Opex-Kosten entstehen.

Betrieb

Neben den Kosten für die IT-Lösung an sich fallen Kosten für den Betrieb an. Wie hoch diese sind, hängt maßgeblich davon ab, wer sich wie intensiv um die Software kümmert.

Return

Mithilfe der Analytics-Architektur werden unterschiedliche Use Cases realisiert, die einen Mehrwert bringen sollen. Beispielsweise können Kosten gesenkt oder der Umsatz gesteigert, neue Produkte und Services kreiert oder innovative Geschäftsmodelle etabliert und die User Experience verbessert werden. Wie hoch der Mehrwert ausfällt, lässt sich vorab nur selten exakt sagen. Eine Annährung ist aber dennoch für eine fundierte Entscheidung unverzichtbar.

Dimension 5: Systemlandschaft

Schließlich können sich Anforderungen aus der vorhandenen oder gewünschten Systemlandschaft ergeben. Das betrifft zum einen das Deployment: On-Premises, Cloud oder Hybrid? Zum anderen geht es um die Skalierbarkeit der Architektur – hinsichtlich der Funktionen und der Leistung.

Fazit

Embedded-Analytics- und Enterprise-Analytics-Architekturen unterscheiden sich zwar erheblich. Mit der Entscheidung für eine Architektur schaffen Unternehmen aber keine irreversiblen Fakten. Denn die einzelnen Komponenten bauen aufeinander auf. Wer also heute zu dem Schluss kommt, dass die Embedded-Analytics-Möglichkeiten von SAP S/4HANA genügen, kann morgen als Ergänzung die SAP Analytics Cloud einführen. Und wer eine elaborierte Enterprise-Analytics-Architektur mit der SAC, SAP BW/4HANA und einem zusätzlichen Data Warehouse in der Cloud betreibt, für den ist der Einsatz von Embedded Analytics in bestimmten Use Cases dennoch sinnvoll.

Wichtig ist nach unserer Erfahrung dieser Punkt: Sobald ein Unternehmen die Architektur-Variante wählt, die im Augenblick am meisten für sie leistet, begünstigt das sehr die Transformation zu einem Data-driven Unternehmen. Bietet die Architektur dagegen zu wenig oder zu viel, führt das rasch zu Frustration und sinkender Motivation.

(ID:47888645)