Mit S/4HANA Embedded Analytics können Analysen in Echtzeit auf operative Daten realisiert und mit Hilfe von Fiori Applikationen dargestellt werden. In diesem Beitrag gebe ich einen Überblick über die verschiedenen, dem Thema Analytics zuzuordnenden SAP Tools sowie deren Techniken und Architekturen. Dabei gehe ich insbesondere auf die folgenden beiden Fragen ein:

  • Wie lassen sich Embedded Analytics in die bisherige Analytics Landschaft einfügen?
  • Welche neuen Reporting-Möglichkeiten ergeben sich mit Embedded Analytics?

Übersicht über SAP Analytics Lösungen

Starten möchte ich mit einem Überblick über die verschiedenen Analytics Lösungen in Bezug auf S/4HANA.

Abbildung1: Architektur Ansätze unter S/4HANA

Abbildung1: Architektur Ansätze unter S/4HANA

In der obigen Grafik werden die unterschiedlichen Ansätze aufgezeigt. Der Klassische Ansatz kombiniert die Agilität der virtuellen Datenmodelle und die Flexibilität des Business Warehouse (BW). Die primäre Aufgabe des BWs ist dabei der ETL (Extraction, Transformation, Loading) Prozess und die Aufbereitung extrahierter, heterogener Daten in harmonisierte Datenstrukturen. Darüber hinaus bietet das „klassische“ BW die Möglichkeit große Datenmengen historisiert zu verarbeiten.

Der Mixed Architecture Ansatz integriert die Vorteile der virtuellen Datenmodelle und die standardisierten Funktionalitäten des BW noch stärker als der klassische Ansatz. So bietet dieser beispielsweise die Möglichkeit, Daten in Echtzeit abzufragen und gleichzeitig historisierte Daten im Reporting einzubinden. Die SAP empfiehlt, dass die im Embedded BW persistierten Daten ein Volumen von 20 Prozent des Gesamtvolumens des Systems nicht überschreitet. Weiter muss zum Benutzen des SAP Business Planning and Consolidation (BPC) eine separate Lizenz erworben werden.

Der Virtuelle Ansatz bietet die Möglichkeit, operationale Daten in Echtzeit bereit zu stellen, ohne diese redundant vorzuhalten. Das Virtualisieren der Datenflüsse lässt dabei eine agile Modellierung zu, welche sich bei Erweiterungen oder Änderungen der Strukturen sofort auf das Ergebnis auswirkt. Gerade die Wiederverwendbarkeit wirkt sich fördernd auf die Interoperabilität der Entwicklungen aus, so dass beispielsweise zukünftige Weiterentwicklungen problemlos möglich sind.

S/4HANA Embedded Analytics

Was steckt hinter „Embedded Analytics“

S/4HANA Embedded Analytics ist Part des Fiori Launchpads und enthält verschiedene vordefinierte Standard Fiori Apps sowie ein Framework zur Erstellung eigener Fiori Apps. Hauptsächlich basiert Fiori auf dem Frontend JavaScript Framework SAPUI5, dessen Fokus auf der intuitiven Bedienbarkeit liegt, sowohl für den Desktopanwender als auch in der mobile Nutzung.

Embedded Analytics Technologien

Technologisch wird SAP ABAP Core Data Services (CDS) zur Modellierung verwendet. Die CDS Views konsumieren die Daten aus den persistenten Datenbanktabellen. Die Abfrage kommt über das Fiori Launchpad und wird an die Fiori UI Applikation weitergereicht. Via OData Services werden dann die Daten über CDS Views aus den physischen Datenbanktabellen (DB) der Fiori Analytical Applikation bereitgestellt. Die Abfragen auf die Daten in den Datenbanktabellen kann dabei von einer oder mehrerer CDS Views geschehen. Im Standardszenario erfolgt dies durch mehrere, voneinander abhängige/verknüpfte CDS Views, welche zusammen ein virtuelles Datenmodell (VDM) bilden.

Abbildung 2: Abfrage der Daten mit CDS View

Abbildung 2: Abfrage der Daten mit CDS View

ABAP Core Data Services (CDS) und Virtual Data Models (VDM)

ABAP CDS Views wurde mit dem ABAP Release 7.40 SP05/SP08 eingeführt. Die Views nutzen OpenSQL und werden mittels eigener DDL (Data Definition Language) geschrieben. Ausgeführt werden die Views aber in der HANA Datenbank. Die SAP nennt das „Code-Pushdown“ und ermöglicht, dass die Berechnungen nicht mehr in der Applikationsschicht laufen, sondern in einer performanteren Datenbank. Das garantiert eine optimierte Laufzeit der Applikationen, wie in nachfolgender Grafik dargestellt.

Abbildung 3: Code Pushdown

Abbildung 3: Code Pushdown Prizip

ABAP CDS Views können beliebig verschachtelt sein. Sie können mittels Assoziationen mit Tabellen und weiteren Views verknüpft werden. Dabei ist zu erwähnen, dass Assoziationen im Grunde wie JOINs funktionieren. Der Unterschied liegt darin, dass diese Beziehung nur dann abgerufen wird, wenn die aus der Assoziation stammenden Informationen benötigt werden. Darüber hinaus können mit Hilfe von Annotationen zusätzliche Metadaten definiert werden. So geben Annotationen den Views unterschiedliche Eigenschaften und Informationen mit, welche den Zugriff oder das Verhalten der Views ändert. In einem Reporting Beispiel kann so ein ABAP CDS View durch Setzen einer bestimmten Annotation die Funktionalität einer BW-Query erhalten.

Bei VDMs handelt es sich um standardisierte ABAP CDS View Modelle, welche in der S/4HANA die Grundlage des Datenzugriffs bilden. Sie verknüpfen im Zusammenhang stehende Geschäftsdaten über mehrere Datenbanktabellen um die notwendigen Geschäftssemantiken für z.B. eine analytische Applikation bereit zu stellen. Diese Modelle bestehen aus mehreren Modellierungs-Schichten, welche einer konsistenten Nomenklatur Struktur folgen:

Consumption View Schicht:

  • Consumption Views bilden die analytische Abfrage, welche die Daten aus der Interface Schicht an die Frontend Tools aus Fiori, Analytics Cloud sowie Business Objects bereitstellt. Am Beispiel eines Reporting ist eine Consumption View gleich einer Query.

Interface View Schicht:

  • Der Composite Interface View bündelt bzw. berechnet die Informationen aus den Basic Interface Views. Aus Sicht eines Reporting ist diese Art von View gleich einem Composite Provider bzw. Cube.
  • Die Basic Interface Views bilden den Basisteil des Datenzugriffs auf die Datenbanktabellen.
Abbildung 4: Virtual Data Model

Abbildung 4: Virtual Data Model

Fiori Analytical App

SAP Fiori ist in drei App Typen unterteilt, „Transactional Apps“, „Analytical Apps“ und „Fact Sheet“. Nachfolgend werde ich ausführlich auf die “Analytical Apps“ eingehen. Zu den anderen Typen nur so viel: die „Transactional Apps“ bilden eine Oberfläche zur Steuerung von Dateneingaben, -änderungen auf transnationaler Ebene. Das „Fact Sheet“ gewährt die Sicht auf Zentrale Informationen, wie Stammdaten oder auch die Weiterleitung zu den transnationalen Applikationen.

Die „Analytical Apps“ hingegen bieten eine Vielzahl der für ein Reporting notwendigen Optionen: Die rollenbasiert (Arbeitsbereich bezogen) aufgebauten Apps werden beispielsweise im Echtzeit-Monitoring der wichtigsten Key Performance Indicators (KPI’s) eingesetzt oder um komplexe Aggregationen bzw. Business Logik abzubilden. Es gibt zwei Arten von „Analytical Apps“:

  • SMART Business Apps werden speziell für das Monitoring der wichtigsten KPI’s und Operational Performance Indicators (OPI’s) genutzt. Mit den in Fiori enthaltenen Apps zur Modellierung können diese erstellt und verwaltet werden.

Der Unterschied zwischen KPI’s und OPI’s liegt in der Identifikation und Bemessung der Metriken im Unternehmen. KPI’s bestimmen die Hauptkennzahlen im Unternehmen. KPI’s im Einzelhandel wären beispielsweise Gesamtumsatz, Einkaufswert pro Kunde und Rückgabequote.

OPI’s dagegen bemessen einen bestimmten Teil eines Prozesses oder Vorgang. Typisch für solch eine Spezifizierung sind Prozesse mit potentiellen Engpässen. Der OPI im Einzelhandel würde beispielsweise die pünktliche Bestellung von Kundenaufträgen betrachten.

  • Virtual Data Models (HANA) innerhalb der Fiori „Analytical Apps“ gewähren den direkten Zugriff auf die Unternehmensdaten. Der Zugriff auf die Daten wird mit Standard SQL oder OData Abfragen realisiert. Dabei wird direkt auf den in der HANA Datenbank abgelegten Daten mittels HANA Views operiert. Eine Zwischenebene, wie beispielsweise ein APAB Applikation System, wird nicht benötigt. Es gibt drei Arten von Views: Query View, Reuse View und Private View.

Standard Angebot der S/4HANA für Analytics mit Fiori

Im S/4HANA System gibt es zahlreiche „Ready to Use“ Applikationen. Aktuell werden für den Applikationstyp „Analytical“ 452 standardisierte Apps von der SAP bereitgestellt. Die Apps können über die SAP eigene „Fiori Apps Library“ gefunden werden. In dieser gibt es Vorschaubilder, Hinweise zu Installation, Konfiguration sowie weitere Informationen zu den einzelnen Apps. Die Standard Apps können bei Bedarf auch teilweise erweitert werden. Die Informationen zu den Erweiterungsoptionen sind zudem in der „Fiori Apps Library“ hinterlegt.

Beispiel: Sales Management Overview (App ID F2601):

Abbildung 5: SAP Fiori Analytical Apps

Abbildung 5: SAP Fiori Analytical Apps

Tools des Embedded Analytics

Es gibt oftmals sehr komplexe und umfangreiche Geschäftsprozesse in Unternehmen, die eigens für diese Prozesse aufgebaute Applikationen erfordern. Für diesen Fall – und für alle weiteren Individualisierungsanforderungen – gibt es verschiedene Tools zur Bearbeitung der Fiori Apps. Gebündelt bezeichnet man diese als „Key User Tools“, hier in einer tabellarischen Übersicht dargestellt:

Inhalt Beschreibung
UI Adaptation Mode Direkte Layout Anpassung der Fiori App
Custom Fields & Logic Einfügen und Bearbeitung kundeneigener Felder und Businesslogik mit ABAP
Custom Business Objects Erstellung eigener Eingabemasken mit dahinter liegender Prozesslogik (ABAP / CDS)
KPI Design Erstellung von KPI anzeigenden Kacheln
Custom Analytical Queries Erstellung analytischer Queries basierend auf VDM / CDS Views
Custom CDS Views Modellierung eigener Datenzugriffe über CDS Views
Custom Forms Adobe Form Designer z.B. E-Mail Steuerung
Custom Tiles Zum Aufbau eigener Fiori Launchpad Kacheln
Custom Catalog Extensions Erweiterbarkeit der Katalog Sicht im Fiori Launchpad
Custom Communication Scenarios Steuerung und Anpassung der OData Services

Tabelle: Key User Tools

Allgemein hängt die Erweiterbarkeit von den freigegebenen Erweiterungsoptionen ab. Neben den Tools werden hierfür APIs und Extension Points benutzt. Es gibt bereits viele Erweiterungen die applikationsbezogen über den SAP API Business Hub gefunden werden können.

Embedded Analytics in Verbindung mit BW / Embedded BW

Wie anfangs in der Übersicht aufgezeigt , gibt es verschiedene Ansätze, wie eine Reporting-Architektur aufgesetzt werden kann. Ob mit den gegebenen Möglichkeiten des Embedded Analytics überhaupt noch ein BW für ein unternehmensweites Reporting benötigt wird, ist fraglich.

Betrachtet man die unterschiedlichen Ansätze wird klar: Embedded Analytics ist kein Ersatz, sondern viel mehr eine Ergänzung des herkömmlichen Reporting. Die Analytics Werkzeuge haben verschiedene Einsatzgebiete mit unterschiedlichem Fokus.

Embedded Analytics legt den Fokus auf die in Echtzeit stattfindende Analyse, limitierter und differenzierter Datenbereiche. Hierdurch können hybride Szenarien erstellt werden in welchen transaktionale und analytische Funktionen zusammengeführt werden. D.h. die analytische Erweiterung kann, im hybriden Szenario, den herkömmlichen Arbeitsprozess unterstützen.

Der Fokus des BW liegt im ETL Prozess. Daten werden harmonisiert und konsolidiert. Die Datenaktualität wird durch kontinuierliche Datentransfers aus den Quellsystemen gewährt. Das im BW stattfindende Reporting ermöglicht somit einen gesamtheitlichen, strategischen Überblick auf die im Unternehmen generierten Daten.

Anders als beim „Standalone“ BW bezieht das Embedded BW hauptsächlich Daten aus einer Datenquelle, sprich aus der S/4HANA in welche das BW integriert ist. Der Fokus liegt auf der Planung (BPC) und kleinen, nicht komplexen Datenmodellen. Auf Empfehlung der SAP sollte die Größe des Embedded BW nur 20% der gesamten Datenmenge des S/4HANA Systems ausmachen.

Fazit

Mit SAP S/4HANA Embedded Analytics erweitert sich das Reporting-Portfolio erheblich. Embedded Analytics wird eher für das operative Reporting eingesetzt. BW findet seinen Einsatz im taktischen und strategischen Reporting. Der vollständig integrierte Ansatz mit Embedded BW umfasst kleine Datenmodelle und Planungslösungen. Durch die bereits starke und weiterhin wachsende Integration der Technologien verwischen die Grenzen zwischen transaktionalen und analytischen Anforderungen. Dabei entstehen Chancen bereits bestehende Reporting / Analytics Lösungen im Unternehmen zu erweitern und zu ergänzen. Datenquellen können somit neu erschlossen und bereits vorhandene, für eine bessere Wertschöpfung, optimiert werden.