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.

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.

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.