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.

SAP’s Wege zum Data Warehouse

Es ist immer wieder interessant, SAP dabei zuzuschauen, wie man aktuell z. B. im BI-Frontendbereich auf Vereinfachung (Simplification) setzt, andererseits im Bereich Data Warehouse einen Strauß bunter Lösungen entstehen lässt, der kaum noch überschaubar ist. Im Folgenden ein wenig die Geschichte, soweit diese für mich nachvollziehbar ist.

SAP BW erblickte 1997 mit dem Release 1.2A als Business Information Warehouse das Licht der Welt. Nach Jahren der Weiterentwicklung hat die SAP 2016 dem Produkt SAP BW ein Ende gesetzt, nur um es unter dem Namen SAP BW/4HANA neu auferstehen zu lassen. Aber das ist nicht die ganze Geschichte. Bereits mit dem Kauf von BusinessObjects und Sybase ließ sich bereits eine komplett vom SAP BW eigenständige BI- und Data Warehouse-Umgebung schaffen. Mit dem Aufkommen von HANA (als damals High-Performance ANalytical Applicance) war schnell klar, dass hier auch etwas neues entsteht. Und so bewirbt die SAP das HANA Data Warehouse, welches bereits 2013 von Thomas Zurek angedeutet wurde.

SAP BW stellen jedoch nicht die Ursprünge des Data Warehouses von SAP da. Bereits vorher war dies bei SAP vielfältig ein Thema. Geht man heute im SAP ERP durch den Customizing-Leitfaden, so findet man nach wie vor beispielsweise im Logistik-Umfeld das Logistics Data Warehouse.

Wenn man bei SAP also von Data Warehouse redet, muss man sich wirklich erstmal Fragen, welches man hier meint.

 

Pre-SAP BW (ERP DWH-Ansätze)

Ja auch heute noch stößt man bei vielen Unternehmen auf die verschiedenen Ausprägungen, welche noch deutlich weiter als das SAP BW zurückreichen. Da gibt es das Logistik-Informationssystem (LIS), welches für verschiedene Logistik-Module vorkonfigurierte, verdichtete Datenebenen bietet und quasi ein embedded Realtime-Reporting mit einer oft akzeptablen Performance liefert. Mit dem bereits erwähnten Logistic Data Warehouse, war (und ist) es möglich eigene Verdichtungsebenen und Fortschreibungsregeln zu definieren um dann flexibel darauf auswerten zu können. Wer BW-Releases vor 7.0 kennt und sich die Fortschreibung im LIS einmal angeschaut hat, wird überrascht gewesen sein und danach wissen, woher das Fortschreibungskonzept dafür stammte.

Auch vom CO-PA kennt man verschiedene Verdichtungsebenen und Auswertungswerkzeuge. Das Ganze gipfelt im EIS/FIS – also im Führungsinformationssystem, welches schon den Ansatz hat, sich auch den verschiedenen Informationssystemen oder auch externen Daten eine Datenbasis auszuwerten, welche flexibel ausgewertet werden kann.

Auch wenn hier Teile wie gesagt durchaus in vielen Unternehmen noch aktiv sind, so wurde doch irgendwann aus sicherlich vielfältigen und nachvollziehbaren Gründen (Performance, Systemlast, Flexibilität, …) entschieden einen Schritt weiter zu gehen. Dieser Schritt war SAP BW.

 

SAP BW

Wie anfangs erwähnt, hat das SAP BW seinen Anfang etwa 1997 oder 1998 mit dem veröffentlichen Release 1.2A. Das Projekt startete als “Reporting Server”, was möglicherweise die Grundlage für die bekannten RS*-Transaktionen gelegt haben dürfte.

Der Sprung zum Release 2.0 kam im August 2000 mit 2.0B, bei dem z. B. das Operational Data Store seinen Weg ins BW gefunden hat. Eine gewisse Erfolgsgeschichte, haben sich daraus doch 3 Varianten und zuletzt das Advanced DSO entwickelt. Im Dezember 2000 folgte bereits 2.1C.

Mit dem Release 3.0A wechselte der Name von Business Information Warehouse mit dem Akronym BIW zu noch kürzer BW.

Ein großer Sprung ereignete sich dann wieder März 2004. Damals kam das Thema Netweaver auf, und das BW-Release 3.5 war Teil von SAP Netweaver 2004.

Vermutlich am 06.06.2006 gab es ein einen großen Releasesprung. Zuerst unter dem Namen SAP NetWeaver 2014s BI capabilities (so wurde mir das damals von SAP gesagt 😉 ) sollte dies das Release SAP BI 7.0 werden. Eine kurze Periode, in der die SAP dem BW den Namen Business Intelligence verpasste. Kurz deshalb, weil SAP 2007 ein Übernahmeangebot für BusinessObjects machte und 2008 diese vollendete. BI wanderte vom BW zu BusinessObjects und das BW bekam mit dem Release 7.3 offizell wieder seine Bezeichnung BW zurück.

Noch ein wichtiger Meilenstein kam mit dem 7.0-Release. Der BWA (Business Warehouse Accelerator), damals noch unter dem Namen BIA (Business Intelligence Accelerator) wurde released. Der erste Ausflug in die In-Memory Welt für SAP BI/BW und der Vorläufer von HANA.

Mit dem Release 7.3 gab es neben der Rückkehr zum Namen BW auch noch zum nächsten großen Sprung. Mit SAP BW powered by SAP HANA. Mit SAP HANA hatte SAP Ende 2010 einen großen Schritt gewagt und heute, knapp 6 Jahre später fast ihre gesamt Produktstrategie darauf ausgerichtet. Nur etwa 1 Jahr später ging SAP BW 7.3 SP5 in den Ramp-Up für HANA.

Im März 2014 folgte das Release SAP BW 7.4. Dieses Release sollte die möglichkeiten von HANA deutlich besser ausnutzen und neue Features auf Basis der HANA-Technologie liefern. Als Enabler für das Logical Data Warehouse sollte es alle Daten als In-Memory Data Fabric in einen gemeinsam Kontext stellen.

Im Herbst 2015 wurde SAP BW 7.5 vorgestellt. Es soll das letzte seiner Art sein. Das Release wurde in 2 Modi vorgestellt. SAP BW 7.5 powered by SAP HANA und SAP BW 7.5, edition for HANA. Mit dem Modus “edition for HANA” leitete die SAP den nächsten Schritt ein. Ein SAP BW, welches nur noch die neuen, HANA-optimierten Objekte einsetzt und die bisher eingesetzten Modellierungsobjekte wie InfoCubes, Datastore-Objekt, InfoSet, MultiProvider usw. obsolet macht. Neben der Modellierung verändern sich auch auch die Schnittstellentechnologien sowie die Modellierungsfläche, welche für neue Objekte von Anfang an in der Eclipse-Umgebung zu finden war.

 

SAP BW/4HANA

Am 07.09.2016 wurde BW/4HANA offiziell vorgestellt bzw. Verfügbar gemacht. Erste Informationen dazu wurden ab 31.08.2016 bekannt gegeben.

Mit BW/4HANA wurde das SAP BW auf Wartung gesetzt und es wird kein Neues Release mehr geben. BW/4HANA gilt als neues Produkt. Als logischer, jedoch nicht rechtlicher Nachfolger. Das lässt sich leicht darauf erklären, hier eine Menge Code z. B. für die bisherigen Modellierungsobjekte sowie für die BEx-Suite entfernt wurde.

Eine gute Annäherung und Vorstellung, was BW/4HANA bedeutet, bekommt man über die rund um den Startzeitpunkt veröffentlichten Blogs:

Thomas Zurek:

Neil McGovern

Marc Bernard

 

SAP HANA Data Warehouse

Zum SAP HANA Data Warehouse habe ich bereits ein wenig geschrieben und möchte im Wesentlichen darauf und auf die Blogs von Thomas Zurek verweisen:

Thomas Zurek:

Sowie zusammenfassende Blog-Einträge von mir:

 

SAP (Sybase) IQ Data Warehouse

2010 hat SAP Sybase übernommen, welches im Bereich BI/Datenmanagement Lösungen wie Sybase IQ, den PowerDesigner und eine Lösung für Complex Event Processing beisteuerte.

SAP IQ ist im BW-Umfeld am ehesten als Datenbank für Nearline-Storage (NLS) bekannt. Die Datenbank ist spaltenbasiert und auf sehr große Datenmengen (Petabyte). Zuletzt 2014 hat SAP IQ im Zusammenspiel mit SAP HANA einen neuen Weltrekord für das weltgrößte Data Warehouse mit 12,1 Petabyte aufgestellt.

Des weiteren dürfte SAP IQ im Frontendbereich bei SAP Lumira eine gewisse Bekanntheit haben, sollte man sich fragen, wo eigentlich die ganzen Daten gespeichert und verarbeitet werden, welche in die Lumira Desktop-Version integriert werden.

Schaut man sich die lose gekoppelte Umgebung des HANA DWH an, dann liegt der Gedanke nahe, dass man hier eigentlich eine HANA auch gegen eine SAP IQ austauschen könnte. Das scheint aber bei der SAP kein populäres Konzept zu sein.

Eher findet man die Datenbank zur Entlastung von HANA als schneller Nearline-Storage, welcher im Multi-Temperature-Konzept der SAP den Bereich der kalten Daten (cold) abdecken soll.

Alternativ zu IQ als NLS kommt auch immer öfters Hadoop ins Spiel. Vor allem, wenn man über Big Data spricht. Mit HANA Vora hat die SAP hier ja sogar einen eigenen Ansatz vorgestellt.

 

SAP BW/4HANA

Am 31.08.2016 wurde SAP BW/4HANA vorgestellt. Wie SAP S/4HANA ist BW/4HANA ein nur auf HANA laufendes SAP-System. Genau wie S/4 HANA gilt BW/4 HANA NICHT als legaler Nachfolger des SAP BW on HANA. Zukünftige Entwicklungsressourcen werden ganz klar in BW/4 HANA fließen und alle bisherigen SAP BW-Versionen gehen in die Wartung über. Mit dem neuen System wird der Ansatz, welcher mit SAP BW 7.5 begonnen und kurzzeitig unter dem Namen B/4 HANA diskutiert wurde, konsequent fortgesetzt.

SAP sieht das System als „next-generation data warehouse application for running a real-time digital enterprise„:

SAP BW Generationen

Copyright: SAP 2016

SAP möchte damit das Logical Data Warehouse, cloudbasiert (aber zur Not auch On-Premise) und mit HANA Vora für den Data Lake ermöglichen. Man möchte fast sagen: Cloud-, HANA, Big Data-First heißt das Motto.

Nach allem was ich bisher so gesehen habe, lassen sich die wirklichen Neuerungen auf folgende Punkte zusammenfassen:

  • Nur noch HANA, keine andere DB mehr
  • Der Support für SAP BW 7.5 on Any DB endet 2024
  • Kein Legacy-Code (kein InfoCube, Standard DSO, InfoSet, … mehr)
  • SAP NetWeaver wird nicht mit BW/4HANA ausgeliefert
  • Die BEx-Suite wird nicht weiter unterstützt
  • Es werden nur noch ODP-DataSources für SAP-Quellsysteme unterstützt

Die SAP hat zur Veröffentlichung am 31.08. eine zentrale Seite im SCN mit einer Menge weiterführender Informationen eingerichtet.

Auch hat Thomas Zurek (VP of SAP HANA DW) die Neuerungen präsentiert. Jedoch aus meiner Sicht nur weitgehend die Entwicklung zusammengefasst, welche mit BW on HANA zuletzt bereits sichtbar war. Mittlerweile (05./07.09.) hat er jedoch noch etwas nachgelegt und auch das Warum? und den Datenmodellierungsansatz näher erläutert.

Doppelt fleißig war man bei der FAQ. Neben der SAP hat auch John Appleby eine solche zur Verfügung gestellt.

Jetzt sind aber nicht alle ganz so unkritisch, wie bspw. die ASUG, die der SAP News-Meldung kaum nachsteht. Die DSAG mahnt gleich an, bestehende Kunden nicht zu vergessen. Nicht zu unrecht, bedenkt man, dass mit der Ankündigung gleich mal die Weiterentwicklung der SAP BW-Schiene on Any DB ein Ende gesetzt wurde.

Als Berater darf man sich freuen. Sind doch bis 2024 eine Menge BW-Migrationen und ein steigender Beratungsbedarf zu erwarten. Schließlich sind aktuell im Jahre 4 nach BW on HANA gerade mal gut 20 % der SAP-Kunden (3.700 von 17.000) auf HANA. In den nächsten Jahren müssen damit pro Jahr ca. 2.000 BW-Systeme releasegewechselt und auf HANA gebracht werden, womit sich die bisherige Geschwindigkeit verdoppeln würde.

Große Diskussionen kann ich bisher nicht sehen. Fragen, welche gestellt werden sind z.B.:

  • Was sind die Hauptunterschiede zwischen BW 7.5 und BW/4HANA?
  • Laufen auf BW/4HANA weiterhin alle Add-Ons? (SAP Note -> 2189708)
  • Welches Release wird in welche Situation empfohlen?
  • Wie passt das neue Release mit der Übernahme des Big Data-as-a-Service Anbieters Alticscale zusammen?

GA des SAP BW/4HANA 1.0 wird groß zusammen mit Amazon am 07.09.2016 gefeiert. Weitere wichtige Erweiterungen werden dann für Q4/2016 – Q2/2017 erwartet. Auf weitere Informationen in den nächsten Tagen, Wochen und Monaten kann man also gespannt sein.

SAP & Data Warehouse vs. Data Lake

Ich erinnere mich gut an einige Gespräche mit dem Fachbereich, bei denen mein Gegenüber der Meinung war, Big Data ist, wenn Excel nicht mehr ausreicht. Und dafür hätte man dann ja z. B. SAP BW.

Interessanterweise ist das auch oft das Bild, welches man durchaus bekommen kann. Oft werden Begriffe undifferenziert verwendet und Schlagwörter verwendet wie „wenn wir HANA haben, dann sind alle unsere Probleme gelöst“.

Gut das selbst die SAP mittlerweile erkannt hat, das HANA evtl. doch nicht die Eierlegende Wollmilchsau ist und an der einen oder anderen Stelle auf ergänzende Technologien angewiesen ist. HANA Vora (seit 03/2016 GA) ist so ein Beispiel.

Aber schon zuvor hat sich SAP gemeinsam mit Hortonworks an einer Big Data Reference Architecture versucht. Und wirbt gerne auch direkt bei den CIO’s mit ihrem Angebot, Big Data in den Griff zu bekommen.

Nun, wenn das DWH schon für Big Data steht, wofür benötigt man eigentlich ein HANA Vora oder gar ein Data Lake? Im folgenden möchte ich die beiden Konzepte etwas besser voneinander abgrenzen. Zuvor jedoch soll noch erwähnt sein, dass  DATAVERSITY einen empfehlenswerten Übersichtsartikel zu dem Thema bietet, welcher mich auch dazu inspiriert hat, hier einmal zu schauen, wo SAP sich dabei sieht..

Die erste Erwähnung und Prägung des Begriffs „Data Lake“ stammt wohl vom Chief Technology Officer von Pentaho:

If you think of a datamart as a store of bottled water – cleansed and packaged and structured for easy consumption – the data lake is a large body of water in a more natural state. The contents of the data lake stream in from a source to fill the lake, and various users of the lake can come to examine, dive in, or take samples.

– James Dixon, CTO Pentaho
Quelle: https://jamesdixon.wordpress.com/2010/10/14/pentaho-hadoop-and-data-lakes/

SAP hat aus meiner Sicht hier für kompakte 2 1/2 Minuten gar nicht schlecht ihre Sichtweise für die Bedeutung eines Data Lakes dargestellt.

Wie bekommt man den nun ein Gefühl, wie sich Data Lake tatsächlich von Data Warehouse abgrenzt?

DWHvsDL

Die dargestellten Aspekte zeigen gut, dass ein Data Lake und ein Data Warehouse durchaus sich ergänzenden Ansätze darstellen. Nur weil in den letzten Jahren neue Datenquellen relevanter und verwertbarer geworden sind, sind bisherige Ansätze nicht obsolet. Jedoch muss man auch sehen, dass, obwohl gewisse Ansätze und Zielsetzungen recht ähnlich sind, der Skill und die Herangehensweise doch sehr unterschiedlich sein können.

In ihrer Roadmap zeigt die SAP, dass Sie hier eine gemeinsame technologische Architektur mit einer zentralen HANA-Plattform sieht, in der in einer absehbaren Zukunft auch das SAP BW im HANA Data Warehouse aufgehen wird:

SAP HANA DW-Roadmap

Dabei hat eben auch HANA Vora seinen Platz und wird als verbindender und integrierter Bestandteil zwischen Hadoop und HANA in dieser zukünftigen SAP HANA Data Warehousing Plattform dargestellt:

HANA_DW_Plattform

Die Zeit wird zeigen ob diese doch verschiedenen Ansätze tatsächlich sinnvoll kombiniert werden können und evtl. das eine Konzept in dem anderen aufgeht. Oder ob die Ansätze nur eine theoretische Möglichkeit darstellen, mit welcher man schön Marketing machen kann, welche so jedoch nicht Realität werden wird.

BW vs. S/4 HANA

Viel wird diskutiert darüber, ob mit einer S/4 HANA oder eben auch noch einer Suite on HANA ein SAP BW (on HANA) überhaupt noch notwendig ist.

Schon die Frage ist falsch gestellt. Den es gibt schon abgesehen von der Unternehmensrealität gänzlich verschiedene Grundsituationen.

Beispielsweise hat die DSAG bereits 8 grundlegende Szenarien für Analytics on HANA unterschieden:

8 HANA Bausteine

Quelle: DSAG-Leitfaden SAP HANA

Dann stellt sich ja nicht nur die Frage, BW oder ERP on HANA. Es gibt auch ein embedded BW oder ein HANA DW welche in diesem Zusammenhang wieder ganz andere Aspekte hineinbringen und zu berücksichtigen haben. Genauso kann die aktuelle Prüfung von Cloud-Angeboten eine Rolle spielen. Auch ist ein bestehendes SAP BW-System, in welches man bereits über Jahre viel investiert hat, doch ein starkes Kriterium gegen eine Ablösung durch ein ERP-basiertes Reporting.

Aus meiner Sicht favorisiert und kommuniziert die SAP die Ansätze HANA Live und S/4 HANA Analytics für operatives Reporting in einem Kontext, der i. d. R. auf das eine System und die darin regulär vorkommenden Daten beschränkt ist.

Trotzdem will ich im folgenden eine kurze Übersicht über Aspekte geben, welche eine erste Orientierung geben können, wann S/4 HANA evtl. ausreicht oder nach wie vor ein SAP BW, evtl. eben auch „on HANA“, sinnvoll ist.

BWvsS4HANA

Quelle: eigene Recherchen, DSAG-Leitfaden, Erfahrungswerte

Zuletzt ist jedoch immer eine individuelle Betrachtung der eigenen Situation, sowie der zukünftigen Planung entscheidend.

SAP BW 7.5 Sp4

So, bzgl. BW 7.5 habe ich schon eine kleine Tradition und offensichtlich ist dies auch von Interesse.

Bisher gibt es von mir dazu folgende Beiträge:

Nun gibt es seit kurzem Info’s zu SAP BW 7.5 SP4. Wie zu Beginn des Minor-Releases 7.5 liegen die Schwerpunkte nach wie vor auf Simplification, Big Data und die Nutzung HANA-spezifischer Funktionen.

Modelling Tools – Nachdem mit SP1 der Query Designer Feature Complete war und InfoObjects möglich wurden, sind nun folgende Objekte damit modellierbar:

  • DataSource
  • Aggregation Level
  • InfoArea
  • InfoSource
  • Semantic Group (Semantische Partitionierung für ADSO)
  • OpenHub

Als Ausblick und nächste Objekte werden Transformationen und Datenflüsse angedeutet.

Erweiterungen für

  • ADSO (z. B. selektives Löschen über Reverse Image)
  • CompositeProvider (z. B. Temporale Joins -> Feature Complete zu InfoSet)
  • OpenODS-Views (z. B. Navi-Attribute von assoziierten virtuellen InfoObjects)
  • InfoObjects (Transitive Attribute)
  • Prozessketten (Streaming / Real-Time)
  • BW Workspaces (z. B. Übertragung der Daten in ADSO)
  • HANA Transformation (z. B. AMDP für Start-, Feld- und Endroutinen)

Bzgl. Big Data wird vor allem stärker zwischen HOT und WARM data (vgl. Multi Temperatur-Konzept – SAP Help) differenziert und mit Extension Nodes verbesserte Lösungen angeboten. Auch im Bereich NLS mit Sybase iQ und Hadoop tut sich etwas.

SAP BW 7.5, editon for HANA – das kurzzeitig auch mal als B/4 HANA diskutiert wurde, soll ab September 2016 zur Verfügung stehen. Damit ist ein HANA-basiertes BW gemeint, welches:

  • nur die HANA-spezifischen BW-Objekte (ADSO, CompositeProvider, OpenODS-View)
  • Modellierung mit den BW Modelling-Tools in Eclipse
  • BW-Administration auf Basis von UI5-Oberflächen

 

Die zukünftige Roadmap weist klar in Richtung SAP HANA Data Warehouse Strategie:

  • Mixed Szenarios als integrierter Bestandteil
  • BW als Teil des SAP HANA Data Warehouse
  • Integration mit S/4 HANA Analytics

 

SAP HANA DWH

 

SAP BI – Skill Set

Seit HANA, BO, Cloud und immer neue Tools auf die SAP BI-Berater einprasseln, gibt es auch immer wieder Diskussionen über das „Skill Set“, welches man benötigt.

Als ich in der Beratung mit SAP BI angefangen habe, gab es auch eine gewisse Trennung. Es gab Berater eher für das Backend und eher für das Frontend. Zusätzlich gab es noch ein paar Leute, welche sich mit BPS/Integrierte Planung (IP) beschäftigt haben. Als BusinessObjects dazu kam oder das Thema HANA gab es erstmal weitere spezialisierte Teams.

Mittlerweile ist das Skill Set eines SAP BI-Beraters ziemlich umfangreich. Selbst wenn man Big Data und HANA DW noch gar nicht in der Tiefe betrachtet.

Ich habe im folgenden versucht, die wichtigsten greifbaren Skills zusammen zu bringen:

SAP BI Skillset

Dabei ist schon einiges zusammen gekommen. Die Sicht ist die einer relativ aktuellen, SAP BW on HANA-basierten BI-Landschaft. Aus der Inhouse-Erfahrung heraus muss ich sagen, dass man sich oft leider nicht in die Tiefe mit den Werkzeugen beschäftigen kann. Manchmal kommt ein Tool schneller als man schauen kann, wenn es hier nicht eine klare Strategie gibt. Und schon hat man den ganzen Tool-Zoo im Einsatz.

Sicherlich fehlen an der einen oder anderen Stelle noch Tools, während auf der anderen Seite Themen vielleicht eher unter- oder übergewichtet sind in der Darstellung. Trotzdem einfach mal ein Ansatz, den SAP BI-Alltag und die Anforderungen an interne Mitarbeiter einmal greifbar zu machen.

Ad hoc würden mir schon Themen einfallen, welche man evtl. noch unter bringen könnte wie Prozessketten, Widgets, Information Design Tool, Status- und Tracking, etc. Irgendwo kann man das aber auch trotzdem noch reininterpretieren.

Wo passen hier noch Themen wie Self Service BI 0der Agile BI rein? Ist das quer durch das Skill Set? Ist das ein Teil der BI-Architektur bzw. des BI-Projektmanagements?

Nachdem ich diese Woche beim DSAG AK-Treffen war, mache ich mir auch Gedanken, wohin alternative Möglichkeiten gehen, mit SAP BI oder zumindest Data Warehousing zu machen. Der rechte Streifen bildet dies evtl. etwas ab. Jedoch, was dort vorgestellt wurde, war jetzt doch wieder etwas weiter von meinem SAP BW-zentrierten Alltag weg.

Ist das also selbst unter Berücksichtigung von HANA und Mixed Szenarios sowie Fiori bereits das „klassische“ Skill Set? Und mit einem HANA DW kommt ein „neues“, „modernes“ oder vielleicht auch „erweitertes“ Skill Set hinzu?

Von Big Data will ich erst gar nicht anfangen. Oder findet sich das letztendlich mit Predictive Analytics und HANA (Vora) nicht auch schon wieder?

Nach wie vor wird es spannend bleiben im Skill Set. BI Clients wachsen zusammen (Lumira & Design Studio), Big Data treibt die technologische Entwicklung, Cloud eröffnet neue Welten und integriert neue Ansätze mit Hichert, Digital Boardroom & Co. Information Design oder Self Service BI sind Themen, welche von außen reinschwappen und ebenfalls Veränderungen antriggern.

BI is Dead (by Timo Elliott, SAP)

Heute gibt es einen neuen Artikel von Timo Elliott von SAP mit dem Namen BI is Dead. Impulshaft möchte man entgegnen „totgesagte leben länger“. Jeder muss ich der Aussage grundsätzlich recht geben.

Wenn man sein Geld dafür bekommt, in seinem Unternehmen für „Enterprise“-BI verantwortlich zu sein, dann kribbelt es bei solchen Artikeln immer etwas.

Gut, schon lange gilt es als Binsenweisheit, dass z. B. der Enterprise Data Warehouse-Ansatz in Unternehmen nicht funktioniert, BICC’s eher eine Randerscheinung sind und es wahrscheinlich nie einen Single Point/Version/Source of Truth geben wird. Außer die Systemlandschaft ist sehr einfach.

Aber es ist auch klar, das Konzepte kommen und gehen und trotzdem immer etwas bleibt oder sich daraus weiter entwickelt.

Klar ist, das Bild, das man heute von BI hat, wird sich verändern. Enterprise BI wird aber nicht sterben. Auch Timo Elliott will uns das mit seinem Artikel natürlich nicht sagen. Würde er als SAP-Angestellter doch selbst schaden bei solch einer unreflektierten Aussage machen. Im weiteren Artikel stellt er aber gut dar, was Gartner mit dem Shift beim letzten Magic Quadrant sagen wollte. Solch Visualisierungen darf man ja auch nicht unreflektiert hinnehmen sondern muss sie hinterfragen. Timo Elliott hat uns einen Gefallen getan und diese Reflektion zur Beruhigung des BI-Volks in diesem Artikel übernommen.

Trotzdem ist die Entwicklung zu Self Service klar sichtbar. Schaut man sich das SAP-Portfolio im BI-Bereich mal an:

  • Web Intelligence – War schon immer auf den versierten Endanwender zugeschnitten
  • Lumira – ist ganz klar der Hoffnungsträger im Bereich Data Discovery
  • Design Studio – liefert Templates für Self Services, die für den ersten Wurf schon ganz schön liefern und bei Bedarf natürlich noch ausbaubar sind
  • Analysis for Office – des Controllers Liebling, war schon immer so
  • BW Workspaces – Self Service Datenintegration, noch nicht ganz einfach zu handhaben, jedoch ein neuer Schritt, in eine Richtung, die früher klar IT war
  • S/4 HANA – bietet mit den Fiori App’s bereits die Kombination aus operativen Anwendungen und Analyse. Das Analysis Path Framework schließt die Lücke weiter.
  • Mit sowas wie Agile Data Preperation  oder Cloud for Analytics möchte ich hier gar nicht erst anfangen

Die SAP versucht ganz klar zu liefern. Die Dynamik macht es jedoch oft schwer, eine einheitliche Strategie zu erkennen, auch wenn sich Richtungen abzeichnen.

BI – Self Service, Big Data, Advanced Analytics, Data Science, In-Memory, Information Design – Themen die BI stark verändern. Somit bleibt es spannend und die wesentliche Herausforderung ist die permanente Anpassung, wie überall im BI-Umfeld.

Governance, komplexe Datenstukturen, Integration von verschiedenen Datenquellen und die Transformation von Daten werden aber nach wie vor die Arbeitsgrundlage im Bereich Enterprise BI bleiben.

Ich denke das folgende stellt die Richtung dar, in die wir uns entwickeln:

Entwicklung BI

Enterprise BI wird eine starke Basis in der Mitte sein. Self Service wird breit kommen, aber gleichzeitig Enterprise BI unterstützen. Es wird einige Zeit dauern, bis die Probleme und Grenzen von Self Service BI bewusst werden. Data Science & Big Data ist von wenigen für wenige. Aktuell etwas gehyped, jedoch gleichzeitig auch schon in der Gesellschaft angekommen. Jedoch ist die Entwicklung aktuell etwas entkoppelt vom BI. Ich vermute hier aber in den nächsten Jahren eine Annäherung, wenn die Tools reifer werden und der notwendige Skill zunehmend in der breiten Enterprise BI-Schicht ankommt.

 

 

 

Das SAP HANA Data Warehouse

In einem aktuellen Blog schreibt Thomas Zurek (VP for Development of SAP HANA BW) über die Richtung, in die SAP BW sich entwickeln wird. Oder sollte man besser sagen, über die Richtung, wie SAP den Data Warehouse-Ansatz technologisch entwickelt und SAP BW dabei eine Rolle spielen kann?

http://scn.sap.com/community/bw-hana/blog/2015/10/26/the-hanadw

Dies passt letztendlich sehr gut zur ebenfalls mit SAP BW 7.5 kommunizierten SAP Data Warehouse Strategie.

Details – SAP BW 7.5 – SP1

Zu dem neuen BW-Release habe ich ja schon einen Beitrag bereitgestellt. Im Folgenden nun die Diskussion zu ein paar Details zum Stand SAP BW 7.5 SP1 (Stand 10/2015 von Lothar Henkes).

Advanced DataStore Object

Bei solchen Namen frage ich mich immer, wie ein Object den noch heißen soll, wenn es sich nochmal weiter entwickelt. Ganz klar, möchte man sich von den bisherigen DataStore Objects (DSO’s) abgrenzen, welche da wären:

Das Standard DSO wurde mit BW 2.1c eingeführt, während die anderen DSO-Typen erst mit BW 7.0 kamen. Die bisherigen DSO’s wurden mit Hilfe von InfoObjects aufgebaut.

Das Advanced DSO, welches erst mit BW on HANA eingeführt wurde, unterstützt die Modellierung mit InfoObjects sowie feldbasierte Modellierung und kann nur über die Eclipse-Umgebung modelliert werden.

Interessante Neuerungen sind:

  • Verbesserungen bei Bestandskennzahlen
  • Zusätzliche Unterstützung für HANA Dynamic Tiering

Für die Zukunft wird die Unterstützung von Realtime Streaming angegeben.

Das Advanced DSO wird alle bisherigen DSO-Typen ersetzen und die Fähigkeiten des BW im Enterprise Data Warehousing-Layer erweitern.

Composite Provider

Nachdem der CompositeProvider eingeführt wurde, wurde dieser kurz darauf schon wieder zum New CompositeProvider upgedated.

Der CompositeProvider macht den MultiProvider und das InfoSet überflüssig. EIne Schwachstelle hat er aktuell noch und das sind temporale Joins, welche mit InfoSet’s möglich waren. Diese Funktion ist für die Zukunft geplant.

In SP1 gibt es ansonsten nur Vereinfachungen für den Einsatz dieses InfoProviders.

BW Query Designer in Eclipse

Zur Einführung des eclipsebasierten Query Designers konnten noch nicht alle Möglichkeiten des bisherigen Query Designers abgebildet werden. Mit BW 7.5 ist dies nun gelungen. Neben den kompletten Möglichkeiten des Query Designers gibt es folgenden Zusatznutzen:

  • Generierung von HANA Views
  • Integrierter Query Preview
  • Verfügbarkeit der neuen HANA Exit-Variablen AMDP (ABAP Managed Database Procedure)
  • Neuer, vereinfachter Formeleditor (mit If-Operator)

Auch bzgl. BW Workspaces geht es spannend weiter, bspw. mit dem BW Workspace Query Designer.

Zu guter Letzte noch als Übersicht die Featureliste zu BW7.5 SP1:

BW 7.5SP1 Feature Overview