Neue SAP Analytics Technologien und der Einfluss in das Beraterleben

Gestern habe ich folgenden Blog von Felipe de Mello Rodrigues gelesen:

Blog1

Diesen kann ich sehr gut nachfühlen. Jedoch hat mich nun der Impuls gepackt, diesen für SAP Analytics nochmal spezifischer nachzuvollziehen.

Beispielhaft kann man sich, wenn man als Partner Zugiff hat unter SAP PartnerEdge mal anschauen, was die SAP alles unter SAP Analytics Solutions einordnet:

Partner1
Quelle: SAP PartnerEdge

Das ist natürlich schon ein ganz schönes Spektrum. Als Berater muss man letztendlich sagen, man muss hier ja nicht alles können.

Ich will aber auch mal beispielhaft an Hand von typischen Re-Tweets auf meinem Twitter-Account zeigen, was sich bei den Themen so tut.

Gestern gab es ein Webinar zum Thema SAP Leonardo Machine Learning:

Tweet1
Quelle: SAP, 2019 (PDF)

Eigentlich gleich schon ein Themenfeld für sich, welches verschiedenen SAP-Technologien zusammenfasst oder zumindest berührt:

SAPLeoML
Quelle: SAP, 2018 (PDF)

Daneben hat man als ambitionierter Data Scientist natürlich auch Python und R drauf und nutzt diese im SAP-Kontext:

Tweet10
Tweet-Link

Ein Thema, welches ebenfalls im Zusammenhang mit Machine Learning seit einiger Zeit gesehen wird ist Robotic Process Automation:

Tweet2
Tweet-Link

Ebenfalls dazu kann man das Thema Conversational AI zählen, welches durch die Übernahme von Recast.AI Anfang 2018 seither an Schwung gewonnen hat:

Tweet7
Tweet-Link

Ein eher klassisches Thema ist, ob das BW eigentlich schon tot ist, weil S/4HANA Embedded Analytics hier die Themen übernehmen wird:

Tweet3
Tweet-Link

Ich denke, wie im Artikel auch vermerkt, wurde diese Frage schon ausführlich diskutiert. Die SAP sieht mit BW/4HANA dies als ausreichend beantwortet und auch die DSAG hat sich bereits 2015 klar positioniert.

Trotzdem darf man sich hier gerne mit der neuen Datengrundlage für Analytics auseinandersetzen – ABAP Core Data Services:

Tweet18
Tweet-Link

Im klassischen BW-Umfeld war das Release 2.0 von BW/4HANA ende Februar ein wichtiger weiterer Meilenstein:

Tweet16
Tweet-Link

Für Berater und Mitarbeiter im BW-Umfeld bedeutet das aber auch sich nicht mehr nur mit einer Datenbankmigration nach HANA auseinanderzusetzen oder sich Veränderungen bei einem Upgrade anzuschauen. Auf der Agenda steht nun in den nächsten Monaten und Jahren das Thema Conversion:

Tweet23
Tweet-Link

Bei vielen klassischen SAP BI-Beratern müsste das Thema SAP Analytics Cloud mittlerweile angekommen sein. Optisch haben sich die Update-Zyklen verlangsamt:

Tweet4
Tweet-Link

Allerdings zeigen die Releasestände, dass sich trotzdem ständig was tut und kontinuierlich Neuerungen geliefert werden. Aktuell Stand 08.2019 welcher nicht nur kleine Verbesserungen sondern z. B. die neue Anwendung Application Design, welche nach längerer Testphase nun für alle freigeschaltet wurde:

SAC1

Nicht das einem mit 2-wöchentlichen Updates noch langweilig wird 😉

Das Thema geht noch weiter. So ist über PAi – Predictive Analytics integrator das Veröffentlichen von in SAP Analytics Cloud Smart Predict erstellten Modellen in S/4HANA möglich:

Tweet6
Tweet-Link

Neben den verschiedenen Tools in SAP Analytics Cloud ist die Verwendung neuer Visualisierungen relativ einfach. Jedoch darf man sich gleichzeitig u. U. auch mit neuen, nicht immer nur strukturierten Datenquellen wie z. B. JSON auseinandersetzen:

Tweet13
Tweet-Link

SAP Analytics Cloud wird auch sofort bei den neusten Übernahmen wie Qualtrics als Enabler und Brücke gefeiert:

Tweet22
Tweet-Link

Auch ist das Thema SAP Analytics Cloud für die Planer im SAP BI-Umfeld zunehmend relevant und wird stärker mit S/4HANA verknüft:

Tweet17.PNG
Tweet-Link

Wer sich noch erinnert, SAP Analytics Cloud hat ja eine längere Namenshistorie. Aber alles hat soweit ich das sehe mal mit C4P – Cloud for Planning begonnen. Daher spielt das Thema in SAC nach wie vor eine wichtige Rolle:

Tweet19
Tweet-Link

Als klassischer BW-Berater muss man sich mit BW on HANA und BW/4HANA zunehmend mit HANA selbst auseinandersetzen:

Tweet5
Tweet-Link

SQL und vom gleichen Autor auch ein Update zu SQLScript ist nur ein Themenkomplex innerhalb von HANA, der hier relevant und interessant ist.

Ein Einsatzgebiet für SQL ist im Rahmen der HANA Modellierung mit Table Functions:

Tweet15
Tweet-Link

Beim Arbeiten rund um HANA und der Integration von Daten spielt dort SDI – Smart Data Integration eine zentrale Rolle:

Tweet11
Tweet-Link

SAP Data Hub ist ein riesen Thema im Big Data-Umfeld, welches wir uns aktuell z. B. auch für IoT-Themen anschauen:

Tweet8
Tweet-Link

Der SAP Data Hub ermöglicht die Erstellung und Verwaltung von Data Pipelines und bietet auch die Integration von SAP BW. Der zuletzt gelaufende OpenSAP-Kurs dazu bietet hier einen ganz guten ersten Überblick und Einstieg:

Tweet9
Tweet-Link

Auch Thomas Zurek als VP of SAP BW/4HANA + HANA Data Warehouse sieht das Zusammenspiel von BW/4HANA und Data Hub als logischen Schritt zum Intelligent Data Warehouse:

Tweet20
Tweet-Link

Auch die klassischen On-Premise BI Frontendtools wie SAP Lumira, discovery edition spielen natürlich nach wie vor eine Rolle:

Tweet14
Tweet-Link

Und auch hier muss man auf kontinuierliche Neuerungen nicht verzichten:

Tweet21
Tweet-Link

Wenn man sich jetzt anschaut, dass die dargestellten Tweets hauptsächlich von April sind, dann zeigt sich schon eine Flut an Neuigkeiten in vielen Bereichen. Daher muss natürlich jeder für sich filtern, was relevant ist. Ob man schon auf BW on HANA ist oder noch nicht oder gar BW/4HANA in irgendeiner Art und Weise angeht. Ob man im Bereich Planung ist oder sich evtl. schon intensiver mit den Möglichkeiten im Bereich Machine Learning und Data Science beschäftigt. Ob Cloud überhaupt ein Thema ist oder man seine On-Premise-Strategie bewahrt. Ob man sich eher im Backend oder im Frontend bewegt.

Zum Abschluss meines Blogs möchte ich das von Felipe de Mello Rodrigues einleitend dargestellte Bild in seinem Blog wiedergeben:

Tweet24

SAP BW/4HANA Architekturtypen

Mit SAP BW/4HANA propagiert SAP auch verschiedene Architekturtypen, welche neue Möglichkeiten mit BW/4HANA im Vergleich zum klassischen SAP BW aufzeigen sollen. Weitgehend sind die Architekturtypen bereits für SAP BW on HANA realisierbar.

Vielleicht ist dies ein schlechter Zeitpunkt, über BW/4HANA 1.0-Architektur zu schreiben, wo sich doch BW/4HANA 2.0 aktuell ankündigt. Zum 25.02.2019 ist das neue Release angekündigt!

Nun gut, ein neues Produkt oder Major-Release von SAP ist natürlich immer das beste, tollste, schönste, schnellste, einfachste, …. wie von jedem anderen halt auch. Bisher etablierte Prinzipien verlieren selten ihre Gültigkeit.

Hier ein Überblick mit Kurzbeschreibung:

sEDW – Simplified EDW (Vereinfachtes Enterprise Data Warehouse)

Das vereinfachte EDW orientiert sich als Architekturtyp an der LSA++. Die Prinzipien und die technische Umsetzung werden bereits in der SAP Hilfe recht ausführlich beschrieben.

Dieser Architekturyp zeichnet sich durch folgende Eigenschaften aus:

  • Referenziert auf die LSA++
  • Geringe Agilität
  • Hoher konzeptioneller Aufwand (Big Design Upfront)
  • Projektmodus: Wasserfallmodell
  • Umsetzung vollständig durch die IT
  • Typischer Konvertierungspfad von BW on Any DB ist In-Place oder Remote-Konvertierung
  • Modellierungsart ist Top-Down

Im BW/4HANA zeichnet sich das sEDW durch optionales Staging aus. Durch Operational Data Provisioning (ODP) wird die PSA quasi ins Quellsystem verschoben. InfoCubes sind nicht mehr existent. Star Schemas werden virtuell durch CompositeProvider realisiert (Dynamic Star Schema).

InfoObjects werden nach wie vor und typischerweise auch noch aus der Historie heraus eingesetzt.

 

fEDW – Flexible EDW (Flexibles Enterprise Data Warehouse)

Das fEDW ergänzt das sEDW um neue Möglichkeiten:

  • OpenODS-Layer/Raw DWH (feldbasiert)
  • Replication Layer (SLT/SDI)
  • Remote Integration (SDA)
  • Transformations (HANA Calculation Views)

Dieser Architekturyp zeichnet sich durch folgende Eigenschaften aus:

  • Referenziert auf die LSA++
  • Mittlere Agilität
  • Hoher konzeptioneller Aufwand (Big Design Upfront)
  • Projektmodus: Wasserfallmodell
  • Umsetzung vollständig durch die IT
  • Typischer Konvertierungspfad von BW on Any DB ist Remote- oder Shell-Konvertierung
  • Modellierungsart ist Top-Down und Bottom-Up möglich

Somit ist durch die Hinzunahme neuer Technischer Möglichkeiten eine höhere Agilität im bisherigen Data Warehouse möglich. Von einem klassischen SAP BW kommend, kann dies als nächster Evolutionsschritt gesehen werden, um Mehrwerte aus der Konvertierung zu generieren.

 

EDP – Enterprise Data Platform

Der Ansatz EDP wird auch als Data Warehouse on demand beschrieben und stellt den versuch dar, mit SAP-Mitteln eine Datenplattform für maximale Agilität aufzubauen. Dabei liegt der Schwerpunkt in der HANA Plattform.

Virtuelle Integration (Logical Data Warehouse) oder Real-time Replikation ist die bevorzugte Art, Daten bereitzustellen. Die Daten kommen im optimalen Fall aus einem Data Lake der in Kundenszenarien auch schon mal als Corporate Memory 2.0 benannt wird.

Dieser Architekturyp zeichnet sich durch folgende Eigenschaften aus:

  • Datenhaltung nach Bedarf
  • Sehr hohe Agilität
  • Nur der nötigste konzeptionelle Aufwand (Sufficient Design Upfront)
  • Projektmodus: evolutionär, inkrementell
  • Umsetzung business-getrieben
  • Typischerweise wird hier Greenfield gestartet, um sich frei zu machen, von evtl. vorhandenen Strukturen und Einschränkungen
  • Modellierungsart ist Bottom-Up (Self-Service, feldbasiert, schnelle Ergebnisse)

Dieser Ansatz steht genau im Gegensatz zu klassischen Enterprise Data Warehouse-Implementierungen. Der schnelle, kurzfristige Nutzen steht im Vordergrund, in der Hoffnung, mit einem agilen, leicht anpassbaren System mit der Zeit und wachsendem Reifegrad auch die notwendige Integration und Harmonisierung leisten zu können.

 

aDWH – Agile Data Warehouse (Agiles Data Warehouse)

Dem aDWH kann man sich von zwei Seiten nähern. Aus Sicht einer EDP kann es ein Stabilisierungsschritt sein, indem zur Historisierung, Versionierung und Qualitätssicherung eine persistente Schicht (OpenODS-Layer/Raw DWH) im BW/4HANA eingeführt wird.

Auch der Weg vom klassischen SAP BW schließt die Evolution in diese Richtung nicht aus.

Dieser Architekturyp zeichnet sich durch folgende Eigenschaften aus:

  • Referenziert noch auf die LSA++
  • Hohe Agilität
  • Nur der nötigste konzeptionelle Aufwand (Sufficient Design Upfront)
  • Projektmodus: evolutionär, inkrementell
  • Umsetzung business-getrieben
  • Vom klassischen SAP BW kommend empfiehlt sich die Shell-Konvertierung, um die notwendigen Vereinfachungen vor dem Datenaufbau vornehmen zu können. Greenfield kann hier jedoch ebenso die Option sein.
  • Modellierungsart ist Bottom-Up (Self-Service, feldbasiert, schnelle Ergebnisse)

 

Im Prinzip sind damit, je nach Ausgangsbasis verschiedene evolutionäre Entwicklungen beschrieben. Eine klare Abgrenzung der Architekturtypen ist eher schwierig und wird sich auch in Zukunft am Bedarf und sich verändernder Anforderungen orientieren.

Da SAP Data Hub, zunehmende cloudbasierte Datenquellen, sowie die eigene Bereitstellung als Cloud-Anwendung (Blueberry) sicherlich noch weiter starken Einfluss auf die aktuelle Entwicklung des BW/4HANA haben werden, dürfen wir uns auf weitere Möglichkeiten in der Zukunft freuen.

 

 

Is Business Intelligence a Data Science Role?

Vor etwa einem Jahr hat ein Teilnehmer in meines Coursera-Kurses „Big Data Specialication“ in einem der Foren die Titelfrage gestellt. Als ich vor etwa vier Monaten darauf gestoßen bin, habe ich neben anderen Teilnehmern versucht, die Frage zu beantworten.

Solche Abgrenzungen sind natürlich grundsätzlich schwierig. Im Beitrag zur Frage war sogar Business Intelligence und Business Analyst zusammen geschmissen. Grundsätzlich finde ich es auch immer interessant, wenn in einem Big Data oder Data Science-Buch Abgrenzungen sehe. I. d. R. finde ich diese immer etwas seltsam…

Ich hatte etwas Zeit damit verbracht, die Diskussionen zu lesen und darüber nachzudenken. Die Antwort von meiner Seite war dann auch recht umfangreich, weshalb ich gedacht habe, es könnte sich lohnen, diese hier wieder zu geben.

Meine Antwort:

Hi all!

Very interesting discussion. As a BI and DW specialist who is learning more about Data Science and Big Data, let me give my part to this discussion.

Where I‘m working and living (Germany), you can clearly differentiate between a Data Scientist and someone doing BI and DW. This is not primarily about tools. And from my point of view it is changing over time.

Data Scientists I know work with NoSQL, maybe Hadoop ecosystem and Spark and more and more in the cloud. Data comes from everywhere and can be structured or unstructured. Social Media, IoT, Business Data, … And they work with machine learning, statistics, also visualizations. E. g. deep learning with TensorFlow and Keras is very popular and Tableau for visualization and story telling. Some of them are very specialized on certain domains like IoT/time series or banking area (fraud detection, …).

So typical BI/DW-tools (DMBS, Viz-Tools) are also used by Data Scientists. What I would like to see as a Data Scientist is experience in working with math methods and machine learning and knowing specialiced tools like KNIME or know programming with R or Python.

CRISP-DM is a typical process and can be found in different variants. As a result Data Scientists found and explain interesting patterns in data and/or implement data driven solutions to optimize business or extend existing business models (or create new ones like Uber, Spotify, Google, Amazon, …)

But at the end I’m not a Data Scientists. So these are things I,ve learned, what maybe is missing to become on, if ever…

As a BI/DWH guy I follow the process ETL->DWH->BI. Typically with internal business data. My job is to extract, integrate and harmonize data from different sources like ERP systems or databases. We try to create an efficient, current (as needed) and integrated high quality base of data in a core data warehouse (a database) which delivers, based on business specification, transactional and master data.

In times before In-Memory databases, we modeled dimensional schemas delivering data very fast and flexible for queries, reports, dashboards, OLAP analysis or further applications like planning and data mining. For reports and dashboards definition of key performance indicators (KPIs) and a good understanding of the transactional process and master data is very often necessary and part of the project. At the end we deploy the report with BI clients, embedded, in a BI portal, mobile and so on.

While machine learning in DS is rather data driven, OLAP Analysis is hypothesis driven and manual work. At the end both can be done on a DW.

I think on a high level a lot of tasks are very similar. Gathering data. Load data on time or regularly to a kind of database. Integrate data (before doing analysis (BI/schema on write) or while doing analysis (DS/schema on read). Test the solution and deploy it. Maybe working on strategy, governance, operations, authorizations, optimization and so on.

For both there are a lot of tools, methods and approaches doing all this. In the last years I see on the one hand, that more and more classical BI vendors getting open for Data Science and Big Data approaches bringing both worlds together. On the other hand I see in both areas that these are not jobs just for one unicorn but for maybe two (like Data Engineer and Data Scientists) or a whole team. As it is in BI. Very often we have specialists for ETL/DW, for BI Clients or for Planning.

Hope this helps a little bit for future learners.

Maybe on last point. Data Science is much more of interest in these days 🙂 while BI/DW is still there since long time and in a broad range of businesses today. I’m looking forward to learn more and see what happens in the next years with these topics.

 

Im weiteren Verlauf gab es auch nochmal eine Antwort von einem Mentor mit folgender Meinung:

„In my view, the largest distinction between business intelligence and data science is that the former focuses on reporting what happened in the past, and the later focuses on predicting the future.“

Eine Aussage, welche ich immer wieder höre und etwas seltsam und im besten Fall etwas unzureichend dargestellt finde. Meine Antwort darauf:

I think no one in BI is building a report just to see what happened. This is an interesting discussion which came up very often. Machine Learning too is analyzing past data. Because you don’t have future data…

In BI you work with planning and forecasting (what could be based on predictive analytics or often not). You analyze past patterns and current trends in data to understand influences and changes to make future predictions and support decisions. You simulate and enhance this with expert knowledge like changed processes, planned promotions, new logistic technologies which can not predicted just maybe calculated or simulated.

In BI you also close the loop and bring analytical information back to ERP/OLTP or other operational Systems to support or automate decisions.

Difference between BI and DS is here maybe that in BI decisions and analysis is mostly done manually and hypothesis driven while DS implement solutions which learn by machine and data driven.

Master the Basics of Analytics

Wenn man sich mit einem Gebiet im Bereich Analytics beschäftigt oder vielleicht auch von einem bestimmten Anbieter oder Tool kommt, dann steht man evtl. irgendwann vor der Frage, woher das eigentlich alles kommt?

Manchmal ist es evtl. eine gute Idee mal ein Buch in die Hand zu nehmen, um von jemandem zu lesen, der sich als einer der Ersten mit dem Thema beschäftigt hat. Oder eben es als erster schaffte, dass auch auf Papier zu bringen.

 

Data Warehouse

Barry Devlin – Erste Definition des Begriffs (Business) Data Warehouse

Homepage | Twitter | Artikel „Business Data Warehouse“

William (Bill) Inmon – Vater des Data Warehouse

Twitter

Ralph Kimball – Vater der Dimensionalen Modellierung

Homepage

Dan Linstedt – Begründer von Data Vault

Homepage | Twitter

 

Business Intelligence

Hans-Peter Luhn – Vater der Business Intelligence

Artikel „A Business Intelligence System

Howard Dresner – Prägte „Business Intelligence“

Homepage | Twitter

Edward F. Codd – Prägte „On-Line Analytical Processing – OLAP“

Collected Work | Artikel „OLAP“

 

Information Design

Ben Shneiderman – Visual Information Seeking Mantra; Erfinder Tree Maps

Homepage | Twitter

Edward Tufte – Erfinder Sparklines; Prägte „Chart Junk“ und „Data-Ink-Ratio“

Homepage | Twitter | GitHub

Stephen Few – Leader in Datenvisualisierung; Erfinder des Bullet Graph

Homepage I | Homepage II

Rolf Hichert – Mitbegründer der SUCCESS-Rules und des IBCS

Homepage | Twitter | YouTube

 

Data Science

John W. Tukey – Begründer der explorative Datenanalyse

Biography | Report (1993, pdf)

Gregory Piatetsky-Shapiro – Prägte „Knowledge Discovery in Databases – KDD“

Homepage | Twitter

Andrew Ng – Mitgründer Google Brain-Projekt, Mitgründer Coursera

Homepage | Twitter

 

Big Data

Doug Cutting – Vater von Hadoop; Chefarchitekt Cloudera

| Blog | Twitter | Github

Matei Zaharia – Erfinder von Apache Spark; Miterfinder von Apache Mesos

Homepage | TwitterDissertation | GitHub

James Dixon – CTO Pentaho; prägte den Begriff „Data Lake“

Blog „Data Lake“ | Twitter

Nathan Marz – Erfinder von Apache Storm; Erfinder der Lambda-Architektur

Homepage | Twitter | GitHub

BARC Score Data Discovery 2017 vs. 2018

BARC hat für 2018 einen neuen BARC Score für Data Discovery veröffentlicht. Fast genau ein Jahr nach Veröffentlichung des ersten BARC Scores zu dem Thema kommt somit die Neuauflage.  Mit dem Neuzugang Datameer sind in 2018 dreizehn Anbieter zu finden.

Was das Thema ausmacht, jedoch auch wie SAP (mit SAP Analytics Cloud) und auch Microsoft (mit MS Power BI) hier abschneiden, möchte ich im Folgenden etwas genauer betrachten.

BARC hat eine eigene Definition für den Begriff Data Discovery:

„Data Discovery is the business user driven and iterative process of discovering patterns and outliers in data“

– BARC, 2017

Wikipedia fast den Begriff etwas pragmatischer:

„Der Begriff Data Discovery („Datenentdeckung“) gilt als Schlagwort für weiterentwickelte Business-Intelligence-Werkzeuge, die mehr Bedienerfreundlichkeit und Flexibilität sowie höchstmögliche Autonomie der Anwender gewährleisten sollen. Der Schwerpunkt liegt in der Visualisierung der Datenanalyse.“

Wikipedia, 19.09.2018

BARC fasst unter Data Discovery drei wesentliche Komponenten zusammen:

  • Data Preparation
  • Visual Analysis
  • Guided Advanced Analytics

An diesen Aspekten muss man sich auch messen lassen, um im BARC Score aufzutauchen.

2015 beschreibt Rita Sallam von Gartner im News-Beitrag Gartner Says Power Shift in Business Intelligence and Analytics Will Fuel Disruption“ Smart Data Discovery. Die Vorstellung von BARC und Gartner dürften sich hiermit weitgehend treffen.

Mitte 2017 greift Rita Sallam das Thema erneut auf und gibt der seitherigen Entwicklung einen neuen Namen: Augmented Analytics – mit Machine Learning und Conversational Analytics als neue Treiber.

Im Vergleich der Überblicksartikel sowie weiterer große Textteile im BARC Score fällt auf, dass sich hier im Prinzip nicht viel geändert hat und für BARC Copy & Paste offensichtlich weitgehend ausgereicht hat.

Inklusionskriterien und Evaluationskriterien haben sich zum Vorjahr im Wesentlichen nicht verändert. Zu den oben genannten drei Aspekten der ersten Score-Achse „Portfolio Capabilities“ kommt noch der Aspekt „Platform“ hinzu. Die individuelle Verarbeitung von Daten sowie die Verbreitung inkonsistenter Analyseergebnisse haben in der Vergangenheit zu einem Vertrauensverlust geführt. Deshalb bewertet BARC auch den Aspekt, lokale und globale Governance zu unterstützen sowie die Kollaboration rund um die Daten zu ermöglichen, ohne den Anwender im Fachbereich zu sehr einzuschränken.

In der Zweiten Score-Achse „Market Execution“ gab es eine kleine Anpassung. Wurde 2017 der Aspekt „Financials“ noch mit Medium bewertet, ist die Gewichtung in 2018 nur noch Low. Unter Financials versteht BARC Marktkapitalisierung, EBITDA, Cash, Profitabilität usw. Es ist anzunehmen, dass die großen Anbieter darunter etwas leiden. Jedoch ist dies hier nur eines von acht Kriterien.

Der BARC Score beginnt in sofern interessant, als das es keinen „Dominator“ rechts oben mit auf beiden Achsen extrem starken Wertungen gibt. Offensichtlich haben alle Tools auch Ihre Schwächen.

Wie 2017 finden sich im zweitbesten Bereich „Market Leaders“ Tableau und MicroStrategy. Neu hinzugestoßen in 2018 ist Qlik mit Qlik Sense. Vergleicht man mal mit den aktuellen Gartner Magic Quadrant für Analytics & BI, überraschen die Market Leader wenig. Der Fokus mag nicht genau der gleiche sein, was es interessant macht zu sehen, warum Power BI von Microsoft zwar auch im BARC Score stark ist (beste Market Execution), jedoch im Bereich Portfolio Capabilities zu den anderen zurück bleibt und somit nur im nachfolgenden „Challenger“-Bereich landet. Microsoft findet sich dort recht nahe zu SAP, welche zwar immer noch Challenger ist, jedoch im Vergleich zu 2017 in der weiteren Entwicklung wohl nicht ganz mit Microsoft mithalten konnte.

 

Bewertung von Microsoft Power BI 

Analytix_MSPowerBI

Beispiel für MS Power BI Desktop (eigene Darstellung)

Produktlink

Update Power BI-Service für Juli & August 2018

MS Power BI (PBI) ist ein Desktop BI-Tool mit cloudbasiertem BI-Service für die Veröffentlichung und Verteilung von BI-Inhalten. Eine On-Premise-Version (Berichtsserver) ist aktuell in Arbeit und bereits einsetzbar.

Treiber für PBI ist die starke Verbreitung von Microsoft sowie der sehr günstige Einstiegspreis. Die Sprache DAX erlaubt komplexe Funktionen in der Datenvorbereitung, erschwert jedoch den einfachen User u. U. die Nutzung. Die Stärke liegt in den Visualisierungsmöglichkeiten. Advanced Analytics steht bedingt zur Verfügung, R kann für fortgeschrittene User integriert werden.

Während BARC das im Unternehmen oft vorhandene Microsoft-Wissen als klare Stärke ansieht, ist die Kundenzufriedenheit in 2017 doch eher niedrig. In 2018 hat sich Microsoft hier aufgrund regelmäßiger Updates deutlich verbessert.

Stärken:

  • Quick Insights für geführte fortgeschrittene Analysen (nur 2017)
  • Natural Language Query-Funktionen für Visualisierungen (Q&A)
  • Integration in die Microsoft-Produktwelt
  • Nachvollziehbarkeit aller Datenvorbereitungsschritte, sowie diese zu ändern oder rückgängig zu machen
  • Gute Führung innerhalb der Datenvorbereitung (nur 2018)

Herausforderungen/Schwächen:

  • Datenimporte (Volumen) sowie der Live-Zugriff auf Quellen ist noch recht eingeschränkt
  • Datenvorbereitung und Modellierung ist nur im Desktop möglich
  • In der Datenvorbereitung sind nicht alle Funktionen über Wizards oder kontextsensitive Aktionen abgedeckt (2018)
  • Automatisierte Insights sind nur in der Cloud verfügbar und brachten in den Testfällen keine signifikanten Muster hervor.

 

Bewertung von SAP Analytics Cloud

Analytix_SAPAnalyticsCloud

Beispiel für SAP Analytics Cloud (eigene Darstellung)

Produktlink

Aktuelles Update (2 Wochen-Rythmus)

SAP vollzieht aktuell einen Wechsel im Bereich Data Discovery. Bisher war SAP Lumira als Desktop-Werkzeug das führende Produkt in diesem Bereich.  In 2018 hat die Strategie komplett zu SAP Analytics Cloud (SAC) gewechselt. SAC wird von BARC als Produkt mit einer vollständigen Vision für Data Discovery angesehen. Einschließlich Datenvorbereitung, visuelle Analyse, fortgeschrittene Analysen sowie als einziges der getesteten Werkzeuge Planung und Budgetierung. Jedoch ist der Reifegrad in bestimmten Bereichen noch nicht sehr ausgeprägt.

Der Umfang an Konnektoren ist bei SAC deutlich geringer als bei anderen Anbietern. Jedoch ist die Datenvorbereitung noch schwach ausgeprägt und ein grundlegendes Datenprofiling ist zwar möglich, jedoch aktuell nur bedingt hilfreich.

Advanced Analytics ist mit den Smart Discovery-Funktionen eine starke Säule des Produkts. Auf Basis der Testdaten konnten jedoch keine in den Daten verfügbaren Muster identifizieren.

Die Führung bei der Datenexploration wird aktuell nicht als ausreichend und flexibel genug angesehen. Jedoch gibt es anständige Visualisierungsmöglichkeiten kombiniert mit guten Kollaborations-, Kommentierungs- und Storytellingmöglichkeiten.

Stärken:

  • Breite BI- & Analytics-Fähigkeiten, integriert in einem Angebot
  • Die Möglichkeit, Ad-hoc Datenmodelle sowie zentrale Datenmodelle in Lösungen zu nutzen
  • Eine gute Führung bei fortgeschrittenen Analysen mittels „Smart Discovery“
  • Konnektivität und vordefinierte Inhalte für SAP-Datenquellen und -Anwendungen

Herausforderungen/Schwächen:

  • SAC ist nur in der Cloud verfügbar und immernoch ein relativ junges Produkt mit in einigen Bereichen eingeschränkten Möglichkeiten
  • Konnektoren fokussieren auf SAP
  • R-Integration ist nur für Datenvisulisierung, jedoch nicht für die Datenvorbereitung verfügbar
  • SAC ist die einzige Lösung im Anbieterfeld, welche in mehreren Bereichen keine Ergebnisse liefern konnte
  • Geringe Wahrnehmung außerhalb der SAP Kundenbasis

 

Fazit

Nun, das Urteil bzw. die Schwächen bei SAP Analytics Cloud erscheinen aktuell sehr hart. SAP hat hier aktuell einen Strategiewechsel hinter sich und liefert in hoher Geschwindigkeit neue Features aus. SAP hat eine große Vision mit SAC, jedoch aktuell noch viele Schwächen. Die aktuelle Roadmap macht das ganze nur noch ambitionierter. Nicht untypisch für SAP fokussiert SAP erstmal auf SAP. Das ist Stärke und Fluch zugleich.

MS Power BI steht aktuell stark da und wird schon länger von Microsoft als führendes Frontend-Werkzeug fokussiert. Auch hier hatte man eine Lernkurve, welche deutlich früher begonnen hat und ist daher z. B. SAP heute in einigen Bereiche noch klar voraus. Auch der Community-Support macht heute bei MS einen besseren Endruck im Vergleich zur SAP.

Einerseits ist es schön, hier doch recht unterschiedliche Fokussierungen und Entwicklungspfade zu sehen. Anbieter wie Qlik und Tableau sind in dem Umfeld bereits lange unterwegs und spielen ihre Erfahrung als Stärke aus. Andererseits zeigen sich ähnliche Releasezyklen im Rahmen agiler Entwicklungsmethoden und oberflächlich betrachtet unterscheiden sich die Tools in den Möglichkeiten erstmal nur bedingt. Cloud ist ein großer Enabler für Innovation und gefühlt wird jede neue Technologie reingebuttert, um dem Kunden einen Mehrwert zu bieten und sich von der Konkurrenz abzuheben.

Forrester Wave™: Big Data Fabric – 2018 vs. 2016

Im Juni diese Jahres hat Forrester die Wave für „Big Data Fabric“ veröffentlicht. Ende 2016 gab es bereits eine entsprechende Forrester Wave. Schauen wir mal, was sich seither entwickelt hat. Neben der allgemeinen Betrachtung ist natürlich die Entwicklung von SAP hier besonders interessant.

Zunächst einmal ist der Begriff „Big Data Fabric“ nicht so einfach zu greifen.

Grob umreißt es Forrester wie folgt:

Big data fabric, an emerging platform, accelerates insights by automating ingestion, curation, discovery, preparation, and integration from data silos.

Quelle: Forrester

Als Inklusionskriterium gibt Forrester das Folgende an:

Evaluated vendors must provide big data fabric features and functionality, such as data access, data discovery, data transformation, data integration, data preparation,
data security, data governance, and data orchestration of data sources (including big data sources) to support various big data fabric workloads and use cases.

The solution must be able to ingest, process, and curate large amounts of structured, semistructured, and unstructured data stored in big data platforms such as Apache Hadoop, MPP EDW, NoSQL, Apache Spark, in-memory technologies, and other related commercial and open source projects.

The solution should be able to store metadata/catalogs for data modeling and data access to support a globally distributed data fabric.

Quelle: Ebenda

TDWI hat ebenfalls einen Versuch unternommen, den Begriff greifbar zu machen:

The term big data fabric is loosely defined at present, representing a need rather than a specific solution. A big data fabric is a system that provides seamless, real-time integration and access across the multiple data silos of a big data system.

Quelle: TDWI

Evtl. lässt es sich ja über die eingesetzten Tools noch greifbarer machen:

BDF Tools

Nun, SAP Data Hub wurde erst im Herbst 2017 gelaunched. Im Herbst 2016 wurde Altiscale von SAP übernommen. Wohl zu spät um damals noch Berücksichtigung zu finden. Die Entwicklung zeigt ein Stück weit, dass sich bei SAP auf jeden Fall einiges getan hat.

Somit ist also ein breites Technologie- und Anwendungsspektrum von SAP im Einsatz, welches auch typischerweise im Umfeld Big Data bei der SAP kommuniziert wird.

Interessant vielleicht auch ein Blick auf die zwischendurch in Q2/2017 erschienene „Forrester Wave: Big Data Warehouse“. Dort war SAP Leader u. a. mit AWS und Oracle. Dabei wurden folgende Tools evaluiert:

  • SAP HANA 2.0
  • SAP Vora 1
  • SAP BW/4HANA
  • SAP Data Services
  • SAP Cloud Platform Big Data Services

Interessant, dass der gleiche Author, Noel Yuhanna 2017 bereits BW/4HANA evaluiert, hier jetzt in 2018 für Big Data Fabric jedoch noch BW 7.5. Für Data Hub war es noch zu früh und die Enterprise Information Management (EIM)-Tools werden hier wohl zusätzlich betrachtet. Das ist leider nicht ganz eindeutig. Früher war hier Data Services durchaus noch damit gemeint. Aktuell betrachtet man ja eher unter dem Begriff die HANA-orientierten Tools rund um Smart Data Integration. Somit sind für wohl verschiedene Use Cases doch sehr ähnliche Tools im Rennen. Jedoch ist der Teilnehmerkreis dabei recht unterschiedlich. Nur SAP, Oracle, IBM, Hortenworks und Cloudera sind in beiden zu finden von jeweils 15 Anbietern.

Aber nun zu den Bewertungen von SAP vs. dem klaren Leader. Leider haben sich die Kriterien ein wenig geändert und auch der Leader von 2016, Informatica ist 2018 weit abgeschlagen und Talend, in 2016 auch schon Leader, hat hier die Rolle übernommen.

BDF Score

Es scheint recht klar, SAP kommt nicht an die Leader heran. SAP ist als Strong Performer in der Gesamtsicht eher im Mittelfeld der Anbieter zu finden. Beim Current Offering haben sich alle Werte verbessert, während die Roadmap und Vision wohl nicht mehr so ausgeprägt wahrgenommen werden wie noch 2016. Sicherlich hat die SAP bereits einige Schritte unternommen und mit Data Hub eine Lösung bereitgestellt, welche eine größere Lücke gefüllt hat. Zu den Führenden ist es jedoch noch ein weiter Weg.

Leider stehen in dem mir vorliegenden Dokument keine genaueren Definitionen zur Verfügung, was z. B. „Data Fabric Access“ bedeutet, bei dem SAP ganz gut abgeschlossen hat.

 

Old School vs. Modern BI

Wird BI heute anders angegangen, als noch vor einigen Jahren? Was hat sich verändert? Wo geht die Entwicklung hin?

Nun, als Berater sehe ich ganz kleine und auch ziemlich große Unternehmen und wie diese dort BI machen. Folgende Aspekte sind mir in letzter Zeit zunehmen aufgefallen, was heute (Modern) doch schon häufig anders ist als zu den Zeiten, als ich mit BI gestartet habe (so 2006…).

OldSchool_Modern_BI

Sicherlich hat sich einiges geändert. Die Tools sind zunehmend Self-Service-like, alles muss ziemlich fancy aussehen, man ist total agil und möchte intern viel mehr selbst machen. Unternehmen haben BI und Analytics für sich entdeckt, sei es um an der Digitalen Transformation teilzuhaben oder einfach nur alle Prozesse optimiert und transparent zu haben. Daten generieren Wert und steuern indirekt oder auch direkt, strategisch, taktisch oder operativ das Business.

Nun, heute gibt es sicher noch genug Unternehmen auf beiden Seiten. Ob eine Seite über die Zeit gewinnen wird, wird sich zeigen. Wahrscheinlich wird es kein komplettes Zurückfallen auf die Old School geben. Trotzdem gibt es dort Stärken, die sich evtl. erst in der nächsten Krise zeigen. Möglicherweise hat man bis dahin genug von der modernen Seite gelernt, um für sich den Besten persönlichen Modus zu finden.