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“

 

 

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.

BI & Machine Learning

Howard Dresner stellt in seinem aktuellen Blog die Frage „Is Artificial Intelligence the Future of Business Intelligence?

Bei SAP selbst tauchen Begriffe wie Machine Learning (ML) oder Artificial Intelligence (AI) immer wieder auf. So ist Bernd Leukert als SAP Vorstand für Produkte & Innovationen auch Aufsichtsrat des Deutschen Forschungszentrum für Künstliche Intelligenz (DFKI). Bill McDermott hat in einem vor Kurzem erschienen Interview klar gesagt, dass SAP zukünftig eine führende Rolle in diesem Bereich einnehmen will. Er wird dabei wie folgt zitiert:

“We want to become the world-wide machine learning leader for corporate businesses, hands down,” …

“Our goal is to have the most intelligent business applications and we’re doing everything we can to achieve that.”

Nicht zuletzt hat SAP aktuell auf der MOOC-Plattform OpenSAP einen Kurs mit dem Titel „Enterprise Machine Learning in a Nutshell“ laufen.

Nun, schaue ich mir den OpenSAP-Kurs so an, dann sehe ich kaum Unterschiede zu dem, was ich schon 2006 zu Diplomarbeitszeiten gesehen und gelesen habe und was heute oft unter dem Label Predictive Analytics verkauft wird.

Schaut man sich die aktuellen Tools von SAP an, so findet man immer wieder die Verwendung der Automated Predictive Library (APL) und der Predictive Analysis Library (PAL) sowie der OpenSource Statistik-Bibliothek R, welche sich bei vielen Anbieter großer Beliebtheit erfreut. APL und PAL sind natürlich Teil von HANA selbst. Und im BW ist die Integration mit dem HANA Analysis Process möglich. Dann gibt es auch noch das Werkzeug SAP Predictive Analytics, welche grafische Oberflächen zur Modellierung bietet. Und auch in das noch sehr neue SAP Produkt SAP BusinessObjects Cloud hat Predictive mittlerweile Einzug gehalten.

Begriffe, welche man in dem Zusammenhang neben Künstliche Intelligenz und Maschinellem Lernen immer wieder hört, sind Data Mining, Statistik, Deep Learning und manchmal vielleicht auch noch Data Science.

Gartner beschreibt Maschinelles Lernen/Machine Learning wie folgt:

Advanced machine learning algorithms are composed of many technologies (such as deep learning, neural networks and natural-language processing), used in unsupervised and supervised learning, that operate guided by lessons from existing information. 

Lt. Gartner stellt sich Künstliche Intelligenz/Artificial Intelligence deutlich komplexer dar:

Artificial intelligence is technology that appears to emulate human performance typically by learning, coming to its own conclusions, appearing to understand complex content, engaging in natural dialogs with people, enhancing human cognitive performance (also known as cognitive computing) or replacing people on execution of nonroutine tasks. Applications include autonomous vehicles, automatic speech recognition and generation and detecting novel concepts and abstractions (useful for detecting potential new risks and aiding humans quickly understand very large bodies of ever changing information).

Gerade der hier auftauchende Begriff „Cognitive Computing“ zeigt, dass in dem Bereich aktuell viel Bewegung ist, bei dem IBM mit Watson ein Vorreiter ist. Jedoch beispielsweise auch die deutsche BITKOM das Thema für sich entdeckt hat.

Als ich 2006 meine Diplomarbeit zum Thema Data Mining (DM) schrieb, war die Welt noch etwas einfacher. Daten waren noch nicht so „Big“ oder „Smart“ und die Begriffswelt noch nicht so ausdifferenziert.

Data Mining beschrieb ich neben OLAP und Planung als Analysetechnik welches typischerweise auf einem Data Warehouse basiert:

„Data mining is the process of discovering meaningful new correlations,
patterns and trends by „mining“ large amounts of stored data using pattern
recognition technologies, as well as statistical and mathematical techniques.“
(Ashby, Simms 1998)

Bei der Herkunftsbestimmung aus diversen Büchern fand ich:

  • Statistik
  • Datenbankmanagement
  • Mustererkennung
  • Visualisierung
  • Künstliche Intelligenz – vor allem der Bereich „Maschinelles Lernen“

Viele der Begriffe versucht man heute viel deutlicher voneinander abzugrenzen, als das nach meinem Gefühl vor 10 Jahren der Fall war. Möglicherweise ist das aufgrund der weitergeführten Forschung in den Bereichen, dem technologischen Fortschritt sowie geänderter Rahmenbedingungen (z. B. 3 V’s) auch absolut sinnvoll.

Nehme ich mal die drei aus meiner Sicht am engsten miteinander verbundenen Begriffe und schaue mir mal die Trends bei Google an, zeigt sich folgendes:

ki_ml_dm01

Offensichtlich zeigen AI und DM eine gewisse Korrelation über die Zeit. Machine Learning hat dafür lange vor sich dahingedümpelt, bis die letzten Jahre der Trend doch angezogen hat, so das Machine Learning an den anderen beiden Begriffen vorbeigezogen hat. Interessant auch der Blick auf die weltweite Verteilung:

ki_ml_dm_02_welt

Möglicherweise sind die Begriffe auch noch sehr regional geprägt. Während Data Mining doch recht verbreitet zu sein scheint, ist Machine Learning wohl vor allem in Skandinavien populär.

Gartner hat im Hype Cycle für Advanced Analytics und Data Science, 2015 das Thema Machine Learning auf dem Gipfel der überhöhten Erwartungen gesehen. Direkt vor Predictive Analytics. Der Hype Cycle 2016 hat sich dazu kaum verändert.

Bei den vor Kurzem für 2017 veröffentlichten Technologie-Trends sieht Gartner das Thema AI & ML als Top 1 und meint:

AI and machine learning have reached a critical tipping point and will increasingly augment and extend virtually every technology enabled service, thing or application.

In diesem Sinne folgen an Stelle 2 und 3 auch gleich die Themen „Intelligent Apps“ und „Intelligent Things“, welche letztendlich wieder stark auf AI basieren.

Howard Dresner schließt seinen Blog mit der Überlegung, das AI im BI-Umfeld ein Thema ist, wenn sie die Daten besser analysieren kann, als ein Mensch. Jedoch warnt er auch, dass AI trotz seines Alters (Ursprünge in den 50er-Jahren) heute keine reife Technologie ist und für Fehler sehr wohl anfällig sein kann, wie bspw. Microsoft im Frühjahr 2016 erfahren musste.

Was bedeutet dies nun für den klassischen SAP BI-Berater, der mit SAP BW, BEx und evtl. BusinessObjects BI unterwegs ist? HANA kommt, aber ist eben noch nicht überall angekommen. Bis zur BusinessObjects Cloud ist es für viele vor allem in Deutschland ebenfalls noch ein langer Weg. Und SAP Predictive Analytics ist aus meiner Erfahrung von der Lizenz her recht teuer.

Ich glaube zurück zur SAP BW Data Mining Workbench und zum Analyseprozessdesigner möchte auch niemand unbedingt. Die Automated Analytics-Ansätze richten sich schon an den Business User. Muss man dann evtl. nur noch technisch und bei der Bereitstellung der Daten unterstützen? Oder braucht man gleich die Weiterbildung zum Data Scientist?

Ich denke es sind einfach auch verschiedene Skills, wie auch verschiedene Anforderungen an die IT, die hier im Spiel sind. Trivial zu beantworten ist dies deshalb sicherlich nicht. Jedoch ist aus heutiger Sicht klar, alles, was eine SAP aktuell unter Analytics zusammenfasst, kann sowieso nur im Team abgedeckt werden. Dieses aufzubauen und zu strukturieren ist vielleicht die wahre Herausforderung.

Hans Peter Luhn

Hans Peter Luhn (1896 – 1964) war ein deutscher Informatiker bei IBM.

Er arbeitete seit 1941 bei IBM und leistete wichtige Arbeit im Bereich der Datenverarbeitung. Bekannt wurde sein Name in den letzten Jahren durch den 1958 veröffentlichten Artikel „A Business Intelligence System„, welcher oft als Ursprung des Begriffs „Business Intelligence“ angesehen wird.

Der Artikel beschreibt jedoch eher die Verarbeitung und Extraktion von Informationen aus Dokumenten, weshalb der Bezug zum typischen Verständnis von BI umstritten ist.

Dazu passt es, dass er u. a. als Vater des Information Retrivial genannt wird.