S/4HANA Embedded Analytics

S/4HANA Embedded Analytics ist der Ansatz von SAP, ein performantes und flexibles operatives Reporting zu ermöglichen.
SAP® S/4HANA embedded analytics is the collection of all analytics fea-
tures integrated in the SAP S/4HANA suite that enables business users,
business analysts, and IT to perform real-time process analytics and

operational reporting on live transactional data.

Aus: SAP S/4HANA Embedded Analytics FAQ

Die Datengrundlage bilden virtuelle Datenmodelle (VDM), welche hauptsächlich auf den Core Data Services basieren. Im Frontend sind die aktuellen BusinessObjects BI-Werkzeuge sowohl On-Premise, wie auch in der Cloud verfügbar. Auf Fiori-Basis wurden jedoch neue Werkzeuge  entwickelt, welche man zwischen den Rollen Endanwender und Analysespezialist unterscheiden kann.

Für die Endbenutzer:

  • Multidimensionale Reports

  • Smart-Business-KPIs

  • Analytische Apps basierend auf Analysis Path Framework (APF)

  • Abfrage-Browser

  • Analytische Fiori-Apps

Für den Analysespezialisten:

  • Multidimensionale Reports

  • Smart-Business-KPIs

  • Analytische Apps basierend auf Analysis Path Framework (APF)

  • Abfrage-Browser

  • Analytische Fiori-Apps

Um das Thema „Embedded Analytics“ ganzheitlich zu betrachten muss man sich auch mit den ein Stückweit alternativen Ansatz HANA Live auseinandersetzen, welcher hier immer noch im Einsatz ist. Und auch das Embedded BW verliert seine Bedeutung durch die neuen Möglichkeiten nicht sondern kann in vielen Fällen aus meiner Sicht an Bedeutung gewinnen. Genauso entwickelt sich in diesem Kontext das BW selbst weiter, behält jedoch in vielen Bereichen noch seine bisherige Bedeutung.

Natürlich kann man sich auch fragen, ob S4H Embedded Analytics nicht nur einfach eine Modernisierung von LIS, SAP Query und ABAP Reports ist. Aber das würde hier zu weit führen.

Der Gedanke ist, diesen Blog in Zukunft evtl. auszubauen, wenn sich damit ein Mehrwert zeigt. Aktuell soll er jedoch im Schwerpunkt als Referenz für die aktuellen Quellen und verfügbaren Informationen zu dem Thema dienen. Es gibt bereits sehr gute Blogs zu dem Thema welche u. a. im Folgenden aufgelistet sind.

Best Practices von SAP: https://rapid.sap.com/bp/#/BP_S4H_ANA (mit S-User)

Das SAP FAQ zum Thema. Leider seit 11/2015 nicht mehr aktualisiert.

2-teilige Blog-Serie von Anirban Kundu aus dem SAP Produktmanagement, welcher einen guten Einstieg darstellt, gute weiterführende Referenzen bietet, jedoch technisch nur bis in eine überschaubare Tiefe geht: Teil 1, Teil 2

SAP S/4HANA Embedded Analytics – A detailed Walkthrough – 5-teilige Blog-Serie mit sehr guten Beschreibungen der relevanten Aspekte von prabhith prabhakaran: Teil 1, Teil 2, Teil 3, Teil 4, Teil 5

Die Einstiegsseite für S/4HANA Release 1610. Unter SAP S/4HANA > Übergreifende Komponenten > Analysen findet sich die aktuell SAP-Hilfe zu Embedded Analytics.

Developer Guide für Analysis Path Framework (APF)

SAP-Hilfe zu SAP Smart Business Cockpits

SAP Fiori Library – Rolle „Analytics Specialist“ – unter Categories > by Roles > Analytics Specialist :

sapanalytix_s4heaapps01
SAP Fiori Library – Rolle „Analytics Specialist“

 

 

Advertisements

SAP Logical Data Warehouse

Immer wieder höre ich mit dem Aufkommen von BW/4HANA auch den Begriff Logical Data Warehouse.

Der Begriff selbst scheint auf Mark Beyer von Gartner zurückzuführen zu sein, welcher auch als „Father of the Logical Data Warehouse“ bezeichnet wird. In einem Blog verweist er dabei etwa auf 2009 bzgl. der ersten Verwendung des Begriffs.

Gartner defines a logical data warehouse (LDW) as a data warehouse that uses repositories, virtualization, and distributed processes in combination.

Quelle: http://www.informationweek.com/software/information-management/data-warehouse-disruptions-2016-gartner-magic-quadrant/d/d-id/1324544

In dem Blog beschreibt er das LDW wie folgt:

“the best name is probably a Logical Data Warehouse,…because, it focuses on the logic of information and not the mechanics that are used.”

– Mark Beyer, 2009

Bei SAP taucht der Begriff Logical DW (LDW) im Rahmen der 2016er-Vision für SAP HANA Data Warehouse auf. Vor allem im Kontext Adapter/Integration.

Bereits 2014 wurde das Thema durch Ulrich Christ auf der TechEd im Kontext BW on HANA vertieft. Er beschreibt darin die Umsetzung des Logical Data Warehouses im SAP BW on HANA mit Smart Data Access als Kerntechnologie für den virtuellen Zugriff auf Daten.

Die SAP hat das Logical Data Warehouse als klaren Bestandteil und Ansatz in die LSA++ übernommen.

Auch für BW/4HANA habe ich leider bisher keine genauere Beschreibung gesehen, wie man das Thema evtl. weiter entwickeln will. Das BW/4HANA jedoch den Ansatz grundsätzlich gut unterstützt ist fast überall zu finden. So ist dies bereits bei der Angekündigungsmeldung zu finden, wie auch auf der Produktseite oder in der FAQ von John Appleby/Bluefin. Nur wirklich viel Neues seit der TechEd 2014 kann ich leider auch nicht sehen.

Letztendlich hat Ulrich Christ jedoch am 13.09.2016 beim BW/4HANA Launch genau den Ansatz als wichtiges Feature gezeigt, als er zu einem bestehenden Datenmodell innerhalb von 1-2 Minuten Daten aus einer neuen Quelle, welche nicht persistent im BW war integriert hat.

BW/4HANA SPS01

Nach dem Start des neuen BW/4HANA im September spendiert die SAP in KW13 2017 auch das erste Support Package für ABAP. Leicht enttäuschend dafür, dass in den Präsentationen immer mal erwähnt wird, dass durch die Loslösung von SAP NetWeaver schnellere Updates möglich sind. Denn bis dahin sind gut 6 Monate seit GA vergangen.

Da man sich ja nun bzgl. BW 7.5 auf keine großen Neuerungen mehr freuen kann, ist es besonders interessant zu beobachten, wohin BW/4HANA sich nun entwickelt.

Schauen wir zuerst auf die interessanten neuen Funktionen:

  • Big-Data-Quellsystem – Über Smart Data Access und den Adapter SPARK SQL sowie des Spark Controllers wird ein Zugriff auf Big Data zur Verfügung gestellt. Open ODS-Views und CompositeProvider ermöglichen die Integration ins BW.

  • API für Hierachien – Hier hat die SAP wohl auf BW/4HANA angepasste Funktionsbausteine ausgeliefert. Oberflächlich scheint damit die eine oder andere Funktion dazu gekommen zu sein:

    bw4hier01
    Vergleich Hierarchie API’s BW7.5 und BW/4HANA
  • Bearbeitung von Stammdaten – Was hat man sich nicht so gedacht, womit die SAP ab Release 7.4 hinwollte, als sie die Stammdatenpflege vom SAP GUI in ein Web Dynpro verlegt hatte. Lt. Doku wollte man damit besser die Business User unterstützen. Nun hat SAP die Bearbeitung in die BW Modellierungswerkzeuge integriert. Da man unter BW Modellierungswerkzeuge Eclipse versteht, ist damit wohl gemeint, dass hier einfach alles an einem Ort, aber doch noch in Web Dynpro ist.
  • SAP Dynamic Tiering pro Partition – für DSO’s (advanced) können die Daten jetzt pro Partition in Extension Nodes verschoben werden.
    • Query anlegen – Prioritäten definieren: Hier können bei Queries mit 2 Strukturen jeweils festgelegte Eigenschaften priorisiert werden. Diese Funktion ist extra für Power User gedacht.

Auch zwei Änderungen/Erweiterungen, welche auf interessante Eigenschaften von BW/4HANA hindeuten:

  • CDS-Views für Data-Warehouse-Monitoring: Hier werden Core Data Services-Views als Nachfolger für den Technischen Content eingesetzt. Das vereinfacht natürlich auch das Monitoring, da keine Stamm- oder Bewegungsdaten ins BW geladen werden müssen.
  • SAP HANA-Views für Queries mit Hierarchiefilter: Eine Erweiterung, um in der HANA DB Calculation Views zu erzeugen. Offensichtlich ist es gut, hier auch die Einschränkungen zu kennen.

So, als kurzes Fazit ist aus der Release-Information noch nicht viel Großes herauszulesen. Man scheint sich dem Thema Big Data zu nähern und liefert an sonsten nur kleinere Anpassungen. Vielleicht sickern aber bis zum Erscheinungstermin auch noch ein paar größere Themen durch.

Mit den oben dargestellten Themen hat man es auf jeden Fall geschafft, die Roadmap für Q4/2016 zu erfüllen. Auch wenn erst Ende Q1/2017 geliefert wird.

Zu den angekündigten HANA native DataStore object (NDSO) konnte man leider nicht viel in der BW/4HANA-Hilfe finden. Im HANA 2-Kontext werden sie als Integrationsebene zwischen HANA DW und BW beschrieben, welche typische BW-Funktionalitäten wie Delta und Request-Handling ermöglicht. Das NDSO soll mit den nächsten Release von SAP HANA Data Warehousing Foundation und ab HANA 2 verfügbar gemacht werden. Es ist somit also erstmal ein HANA-Thema, auch wenn es auf der BW/4HANA Roadmap steht. Die HANA Academy auf YouTube hat einige einführende Videos dazu geteilt.

Für Q2/2017 sind folgende Neuerungen geplant:

  • HANA Analysis Process kann BW-gesteuert auf Spark/Hadoop ausgeführt werden.
  • Erweiterte HANA EIM-Integration: Delta und Realtime-Streaming Unterstützung für native HANA-Tabellen
  • HANA-View Generierung für Open ODS-View
  • Parallel-Loads für Stammdaten
  • Weiterer Push-Down von OLAP-Funktionen wie Ausnahmeaggregationen einschließlich Währungs- und Mengeneinheitenumrechnung

Damit kommen aus meiner Sicht die spannenden Themen erst unter dem Stichpunkt „Future Innovation“. Na dann freuen wir uns einfach mal auf zukünftig noch konkretere Information bzgl. BW/4HANA.

SAP Core Data Service (CDS)-Views für Analytics

Mitte 2015 gab es in den Niederlanden eine Videoaufzeichnung zu einem BI Podcast zwischen Ulrich Christ (SAP Produktmanager für HANA im Bereich Data Warehousing), der auch aus den OpenSAP-Kursen zu BW-Themen bekannt ist und Jürgen Haupt, SAP Produktmanager SAP EDW, der auch sehr bekannt für das Thema LSA ist, mit dem Titel „S/4HANA Analytics with CDS views and BW as evolutionary extension„.

Ulrich Christ zeigt dabei eine Demo mit Analysis for Office auf einem CDS-Modell, welches in einem S/4HANA-System liegt. Er erklärt die Mächtigkeit im Vergleich zu Data Dictionary Views und wesentliche Elemente eines CDS:

  • Annotations – besonders interessant hier ist die Analytics Annotation.
    • SAP beschreibt diese als „Enable the analytic manager for multidimensional data consumption, performing data aggregation, and slicing and dicing data. BI frontends like Design Studio and Analysis Office can consume the data via the analytic manager.
    • Durch die Annotation wird z. B. definiert, um welche Kategorie von Daten es sich handelt  – Stammdaten (#DIMENSION) oder transaktionale Daten (#FACT, #CUBE) oder um Plandaten (#AGGREGATIONLEVEL).
    • Hier wird auch festgelegt, ob der CDS-View für die Extraktion geeignet ist und evtl. Delta-Verfahren unterstützt. Damit bildet der View beispielsweise auch die Basis für eine BW DataSource.
  • Associations – Diese dienen der Ergänzung der grundlegenden Daten. So können hier für transaktionale Daten noch Attribute oder Texte hinzugefügt werden. Im Vergleich zu einen SQL-Join sind Associations wiederverwendbar.

Ulrich Christ macht klar, dass CDS-Views langfristig die neue Grundlage für BW-DataSources in S/4HANA sind. Wie SAP in der Präsentation „SAP S/4HANA Analytics & SAP BW Data Integration“ zeigt, geht dies mittlerweile sogar noch darüber hinaus. SAP sieht CDS-Views im ABAP-Layer als Virtual Data Model (VDM), welches Daten für BI (über Transient Provider), Hybride transaktionale und analytische Anwendungen (HTAP) und weitere S/4HANA-Anwendungen Daten bereitstellt:

sapanalytix_cds01

Quelle: „SAP S/4HANA Analytics & SAP BW Data Integration

Auf HANA-Ebene hat diese Rolle im Wesentlichen HANA Live, wobei das CDS-Konzept ja mittlerweile auf HANA übertragen wurde. Eine Erklärung der Unterschiede und Gemeinsamkeiten der beiden Konzepte findet sich von Horst Keller in seinem Blog. Ein guter Überblick und Vergleich findet sich auch hier.

Von Ulrich Christ kommt dazu die Aussage, dass HANA Live durch das veränderte Datenmodell in S/4HANA evtl. nicht mehr vollständig funktionieren wird und CDS das Konzept für Operational Reporting sein wird.

In einer Präsentation der SAP TechEd 2015 werden folgende Nachteile von SQL im Vergleich zu CDS aufgezeigt:

  • Eine große semantische Lücke zwischen der konzeptionellen Anforderung und der Umsetzung in SQL
  • Die Komplexität der Anforderung führt zu einer verschlechterten Performance

Bzgl. dem Argument „Aber dann nutze ich ja gar nicht mehr die Performance einer HANA-Datenbank aus, da die Anwendungslogik auf dem Application Server läuft“ gibt die Präsentation zwei Antworten:

  • Eingebaute SQL-Funktionen/-Ausdrücke können komplexe Berechnungen in die HANA-Datenbank oder auch jede andere von SAP unterstütze Datenbank pushen.
  • CDS Table Functions nutzen native HANA-Funktionen, welche in CDS implementiert wurden.

Mittlerweile hat sich Ulrich Christ in einem Blog vom November 2016 nochmal die genaue Verwendung von CDS im Kontext BW angeschaut und einige Dinge klar gemacht:

  •  Erweiterung von BW InfoProvidern um zusätzliche Informationen -> Nein!
    • Das BW-Datenmodell ist sehr ausgereift und komplex. Dies nachzubilden wäre nicht sinnvoll. Ein Ansatz, BW-Datenmodelle für SQL zu öffnen wären HANA Calculation Views. Ein Ansatz zur Integration von Non-BW-Daten ist über den OpenODS-View möglich.
    • CDS würde das Konzept der Analyseberechtigung umgehen. Ebenfalls HANA Calculation Views und die Ableitung von HANA Privileges aus Analyseberechtigungen wären hier der Ansatz.
  • SAP BW Technischer Content -> Ja!
    • Hier wird tatsächlich seit BW 7.5 SP04 Content auf Basis von CDS-Views ausgeliefert.
  • Integration von Daten ins BW über CDS -> Ja!
    • Die Extraktion von S/4HANA-Daten über den Quellsystemtyp ODP-CDS ist möglich.
    • Über OpenODS-View können CDS-Views auch virtuell konsumiert werden.
  • BW Transformationen -> Vielleicht!
    • Ein komplexer Look-Up auf eine Z-Tabelle wäre denkbar.

Nun gut, aus meiner Sicht ist und bleibt CDS eine Technologie, welche zunehmend eine Rolle spielen wird und es gut ist, wenn man weiß, was sich tut und die CDS-Entwicklung evtl. sogar beherrscht. Hoffen wir nicht, das wie bei HANA Live der Ansatz wieder schneller weg ist, als S/4HANA in der Breite ins Laufen kommt.

Rückkehr des Embedded BW?

Bereits vor einiger Zeit habe ich aufgrund immer wiederkehrender Diskussionen versucht, Aspekte aufzuzeigen, welche abzuwägen sind, wenn man S/4HANA einführt, und sich im gleichen Zuge Gedanken macht, ob man dann auf das BW-System verzichten kann:

BW vs. S/4 HANA

Gerade die Unternehmen von Typ:

  • (Gehobener) Mittelstand
  • 1 zentrales ERP-System auf dem alle Standorte laufen
  • und in dem der Großteil der Unternehmensprozesse abgebildet sind
  • Verbunden mit einer hohen Kostensensibilität

sind nicht so ganz einfach zu überzeugen bzw. haben evtl. dafür genau das richtige Szenario um über sowas nachzudenken.

Durch ein Embedded BW kann man schließlich immer noch sagen, man nutzt hier bei Bedarf entsprechende Funktionalitäten, welche vielleicht so im ERP nicht verfügbar sind.

Hier ist bereits der erste wichtige Punkt. Fange ich an, ein Embedded BW zu nutzen und:

  • die Nutzung nimmt zu, immer mehr Szenarien sollen dort abgebildet werden
  • durch einen Zukauf hat man evtl. ein Unternehmen, welches unterschiedliche Prozesse hat und welches man nicht mal kurz in das zentrale ERP-System integrieren kann
  • Führe ich doch ein Non-SAP-System ein, welches Daten für das Reporting liefern soll
  • Kann/Will ich SAP-Systeme nicht integrieren (z. B. HCM aus Datenschutzgründen oder SAP Cloud-only Systeme)
  • Möchte ich die analytischen Fähigkeiten von SAP für neue Arten von Daten nutzen (z. B. Social Media, IoT, …)

Dann steigt u. U. recht schnell die Datenmenge.

Die Empfehlung der SAP ist hier, nicht mehr als 20% des Gesamtdatenvolumens im Embedded BW zu halten. Dies schließt Daten aus dem eigenen ERP, aus Fremdsystemen oder aus Planungsprozessen mit ein.

Auch an die Ressourcenseite ist zu denken. Es ist anzunehmen, dass analytische Funktionen höhere Anforderungen auch an ein HANA-System stellen, als dies bei einem transaktionalen System der Fall ist.

Man schränkt sich bzgl. analytischen Funktionen selbst ein. Einerseits durch die Abhängigkeiten des ERP-Releases. Andererseits hat die SAP klar gemacht, dass die nächste Entwicklungsstufe des SAP BW, das BW/4HANA, nicht Teil eines S/4HANA-Systems sein wird und somit die Weiterentwicklungen der nächsten Jahre nur sehr begrenzt zur Verfügung stehen.

Also nach wie vor, und gerade wenn man bereits ein bestehendes BW-System hat, gilt es, diese Entscheidung ganz genau mit der strategischen Planung der nächsten Jahre abzugleichen und keinesfalls aufgrund kurzfristiger Hoffnung auf Einsparungen zu folgen.