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.

SAP BI Statement of Direction für On-Premise

Heute wurde ein aktuelles Statement of Direction (SOD) für BusinessObjects BI veröffentlicht.

Nachdem vor Kurzem auf zum Start der SAPPHIRENOW bereits kund getan wurde, dass alle BI-Lösungen, On-Premise und Cloud unter BusinessObjects laufen. Und mit der starken Präsentation der Cloud BI-Lösung von SAP überlegt man sich natürlich schon, wo geht das alles hin.

Nun, was kann man aus dem SOD mitnehmen, welches immerhin auf 20 Seiten präsentiert wird?

Mit dem SOD möchte SAP eine Roadmap für die nächsten 2 Jahre aufzeigen. Zunächst tut die SAP dies, in dem Sie klar darstellt, dass sowohl in die Cloud wie auch in On-Premise BI weiter investiert wird. Die Strategie ist „Innovate the core and lead the cloud“.Durch die Digitale Transformation werden Themen wie Predictive, Self-Service und Realtime immer wichtiger.

Innovate the core
Timo Elliott, 2016

SAP sieht Analytics und BI als die Schlüsseltechnologie, um aus der dem digitalen Business Werte zu schöpfen. SAP wirbt hier mit dem Stichwort „Reimagine Analytics

Nach der Vorstellung der allgemeinen Richtung liegt der Schwerpunkt des SOD auf den folgenden Tools:

Schade, dass Crystal Reports hier nicht auftaucht. Ist es doch immer noch Teil der Simplification-Roadmap von SAP.

SAP sieht zwei Trends am Markt. Den Trend in Richtung Self-Service BI. SAP sieht hier Lumira und Analysis for Office positioniert. Bei Lumira wurde massiv investiert in neue Funktionen und durch die Verschmelzung mit Design Studio Ende 2016 wird hier die Strategie weiter entwickelt. Bei Analysis for Office wurde ein gemeinsames Add-In mit BPC entwickelt, um den Nutzen beider Welten zu erhöhen.Zukünftig soll dieses noch um Live Office-Funktionen erweitert werden.

Der zweite Trend ist, in die IT-gesteuerte Unternehmens-BI skalierbarer und vertrauenswürdiger zu machen. Erreicht werden soll das durch die Vereinfachung des SAP BI-Portfolios, ein einfacheres Plattformmangement und die Modernisierung der BI-Werkzeuge. Die SAP sieht hier Design Studio, Web Intelligence und Crystal Reports (also doch Crystal Reports, im Dokument jedoch ohne BusinessObjects vorangestellt???):

Mit Design Studio 1.5 und 1.6 sollten hauptsächlich die Lücken zu BEx Web Application Designer und SAP BusinessObjects Dashboards geschlossen werden. Aber auch viele neue Features wie die Scorecard-Komponente oder Smart Objects. Die BI Plattform 4.2 liefert die vertrauenswürdige Basis für BI im ganzen Unternehmen.

Auch Web Intelligence liefert viele Erweiterungen mit BIP 4.2 und für alle Tools wird weiter investiert und an den oben genannten Zielen gearbeitet.

Auch die BusinessObjects Mobile-Lösung ist klar weiter gesetzt und hat ihren Cloud-Gegenspieler nun mit Roambi gefunden. Zukünftig wird Lumira hier u. a. noch stärker unterstützt werden.

SAP BusinessObjects Predictive Analytics soll seine Position weiter ausbauen. Ebenso wird in die prädiktiven Fähigkeiten von HANA investiert. Predictive Anaytics soll für jeden Anwender nutzbar werden. Das wird von SAP als ein „data scientists in a box“ beschrieben.

Des weiteren sieht SAP die HANA Plattform als Digital Enterprise Platform, welche zwar auf der „Cloud First“-Philosophie beruht, jedoch bereit ist, die Brücke zwischen Cloud und On-Premise zu schlagen. BusinessObjects BI-Werkzeuge sind Schlüsselelemente dieser Plattform.

Bzgl. S/4 HANA werden die Core Data Services das zentrale Element sein, um im gesamten Kontext von S/4 HANA alle Möglichkeiten für operative, taktische und strategische Analytics , unterstützt auch durch ein embedded BW zu liefern. Das Ziel ist dabei alle Standard-ABAP-Berichte abzulösen.

Und zu guter Letzt, nach einem erneuten Werbeblock für die Cloud BI-Welt fordert die SAP die Community auf, mitzumachen und sich einzubringen.

Alles in allem, nicht viel unerwartetes. Wenig, was nicht schon die letzten Wochen bekannt geworden ist. Jedoch sicherlich eine gute Zusammenfassung, um klar zu stellen, wohin der Weg geht.

Seien wir gespannt wie es weiter geht…

SAP BPC für Konsolidierung (High Level)

Aktuell ist es recht schwierig, genauere Informationen bzgl. SAP Business Planning and Consolidation (BPC) zu bekommen. Speziell wenn man sich für die Konsolidierung interessiert. Und dann evtl. auch noch, wenn man sich für die Microsoft-Variante interessiert…

Somit sind die folgende Informationen

a) von mir ohne großes Vorwissen im Bereich Planung/Konsolidierung 

b) aus einer High Level-Sicht bzgl. Konsolidierung

c) nicht abschließend und nach bestem Wissen und gewissen 

zusammengestellt.

Vorab sollte ich vielleicht auch noch schreiben, dass SAP natürlich auch noch andere Werkzeuge zur Konsolidierung im Portfolio hat. Das sind konkret:

  • SAP EC-CS (Enterprise Controlling – Consolidation)
    • SAP ERP-integriert
    • Vorgänger von SEM-BCS
  • SEM-BCS (Strategic Enterprise Management – Business Consolidation)
    • SAP BW-integriert
  • BO-FC (BusinessObjects Financial Consolidation)
    • Standalone
  • BPC (Business Planning and Consolidation)
    • Standalone, BW-integriert, S/4 HANA-integriert (über Embedded BW)

Dies Werkzeuge haben sicherlich verschiedene Stärken, Schwächen und Einsatzszenarien, welche auch in Zukunft noch den Bestand der Werkzeuge rechtfertigen. (Ausser vielleicht EC-CS, welches wirklich nicht mehr weiter entwickelt wird…)

Bei BPC tut sich jedoch aus meiner bisherigen Sicht besonders viel. Vor allem im Bereich Planung wurde viel entwickelt und BPC z. B. in die NetWeaver (NW)-Welt integriert.

Dazu kommt, dass SAP mit BPC, wie vor kurzem beschrieben, als Flagship-Produkt die führende Rolle sowohl im aktuellen Gartner Magic Quadrant für Strategic, sowie für Financial Corporate Perfomance Management (CPM) einnimmt.

Da zur Zeit mein besonderes Interesse der Konsolidierungsfunktion gilt, habe ich die folgenden Informationen aus diesem Blickwinkel zusammengestellt, um mir einen grundlegenden Überblick zu verschaffen. Natürlich sollten die Angaben für Planung genauso gültig sein.

BPC consolidation

Für mich ist vor allem die Möglichkeit interessant, nachher über BI-Werkzeuge wieder auf die konsolidierten Daten für ein Management-Reporting zuzugreifen. Dabei hat mir ein schneller Blick in die CMC gezeigt, dass hier sogar direkt eine Verbindung auf ein BPC for MS bzw. BPC for NW erstellt werden kann:

BPC in CMC

Dies kann natürlich die weitere Verarbeitung erleichtern und erscheint recht einfach, wie eine Demo auf YouTube zeigt.

Wie man sich nun entscheidet, bedarf sicherlich einer tiefergehenden Betrachtung. Geht es um eine Einführung mit dem Fokus auf Konsoliderung sind aktuell ganz klar BPC für MS bzw. BPC für NW Standard Model die Tools der Wahl. Als nächstes die Frage, ist die IT eher mit SAP oder Microsoft unterwegs? Damit sollte sich auch schon fast die Frage erledigen, ob die Daten eher aus einer heterogenen bzw. nicht SAP-Systemlandschaft stammt (was eher für MS spricht) oder ob die Daten sowieso schon im Schwerpunkt im SAP ERP (bzw. S/4 HANA)  oder auch schon integriert für weitere Verwendungszwecke in einem SAP BW vorliegen (was eher für NW spricht).

Wenn es denn Standalone und nah am Fachbereich sein soll, muss man sich sicherlich auch nochmal überlegen, ob SAP hier überhaupt die Lösung der Wahl ist. In dem Fall gibt der Markt ja auch noch ganz andere Lösungen her.

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.

SAP BW Kunden-Statistik

Heute habe ich mal wieder die Zahlen zu SAP BW-Kunden auf dem SCN-Blog von Tammy Powlas gesehen:

  • 15000+ SAP BW-Kunden
  • 7000+ SAP BW 7.3/7.4-Kunden
  • 2500+ SAP BW on HANA-Kunden

Das ist schon grundsätzlich eine interessante Darstellung. Ich habe mal versucht, das zu visualisieren:
SAP BW Kundenstatistik

Lassen wir doch hier einfach mal das + weg. Wo fängt das schon an? 15.001 Kunden mit SAP BW? Kosmetik, die nach mehr schreien soll würde ich sagen.

7.000 Kunden mit einem Release 7.3 oder 7.4. Aktuell ist ja 7.5 im Ramp-Up. Damit will man also wohl sagen, schon viele aktuelle Kunden. Gut, 7.3 ist lt. SCN-Seite am 07.11.2011 released worden. Also ziemlich genau 4 Jahre alt. Wer von den 7.000 Kunden 7.4 hat, wird damit im Unklaren gelassen. Dass mehr Kunden (8.000) ein System im Einsatz hat, seinen Ursprung vor mehr als 4 Jahren hatte, sagt ja auch ein wenig aus…

Und dann 2.500 Kunden mit BW on HANA. Heißt ja im Prinzip auch nur, das bisher ganze 16,66% auf ein HANA-System gewechselt sind und sich 83,33% das noch überlegen… Bedenkt man, dass es für das BW HANA bereits am längsten gibt, ist das eigentlich nichts, was mich hier vom Hocker reißt. HANA ist seit Mitte 2011 verfügbar ist und gilt als Technologie bzw. Plattform der Zukunft bei SAP.

Man kann ja nur hoffen, dass es mit S/4 HANA schneller geht. 1.300 Kunden werden hier bereits genannt. Ich musste etwas suchen, um die Anzahl der SAP Business Suite-Kunden zu finden. Hier komme ich 2013 auch > 40.000. Damit stehen wir hier nach gut 9 Monaten doch auch schon bei 3,3%. Rechne ich das mal linear auf 4 Jahre hoch, komme ich auf ähnliche Zahlen wie beim BW. Na, vielleicht gewinnt das Thema ja noch an Speed. Ansonsten benötigt die SAP ca. 23 Jahre, nur um die bestehenden Kunden umzustellen. Und ich vermute mal, die heutigen S/4 HANA-Kunden sind zu einem großen Teil Neukunden…

Liebe SAP, weniger Marketing und mehr zeigen, was das Ding kann bitte. Value statt Werbung. Gerade die BI-Leutchen mögen harte Facts 😉