SAP BW/4HANA und BW auf HANA

BW, HANA

Wird SAP Business Warehouse in Zukunft nicht mehr unterstĂŒtzt, abgelöst von HANA, ersetzt durch S/4HANA? Solche und Ă€hnliche Fragen wurden in der Vergangenheit hĂ€ufig gestellt.

Diese Zweifel sind mit dem Announcement von SAP BW/4HANA Ende 2016 obsolet – die Zukunft von SAP BW manifestiert sich in SAP BW/4HAN.

SAP BW/4HANA und BW auf HANA

Was hat uns dazu bewegt, SAP BW/4HANA als die neue Innovations-Codeline zu entwickeln, und warum werden die geplanten Innovationen nur mit BW/4 ausgeliefert und nicht auch mit SAP BW 7.x powered by HANA? Die Antwort ist ganz wesentlich geprÀgt von den Herausforderungen, die wir mit BW/4 lösen (wollen), deren Lösungsumfang und dem zeitlichen Aspekt der Auslieferung.

Evolution und Überblick

SAP hat In-Memory-Datenbanken (IMDB) nicht erfunden. Diese Nischentechnologie existiert schon lĂ€nger, spielte aber bisher eine eher untergeordnete Rolle in sehr speziellen AnwendungsfĂ€llen. Mit der EinfĂŒhrung von HANA erlöste SAP sie aus ihrem Dornröschenschlaf und verhalf ihr als zukunftsweisende Technologie zum Schritt auf die große BĂŒhne der Enterprise-Applikationen.

In diesem Kapitel schauen wir kurz auf die Historie der beiden Hauptprodukte SAP HANA und SAP BW zurĂŒck und betrachten BW auf HANA sowie die neueste Version BW/4HANA im Allgemeinen.

Evolution von SAP HANA

Seit der MarkteinfĂŒhrung 2010 hat sich HANA zu einer reifen Plattform entwickelt, die sich in jeder Hinsicht mit den etablierten Datenbanken in OLTP (Online Transactional Processing) und OLAP (Online Analytical Processing) messen kann. Nach Unternehmensangaben hat HANA Ende 2015 bereits ĂŒber 10.000 Kunden. Von den mehr als 16.000 SAP-BW-Kunden konnten bis MĂ€rz 2017 mehr als 4.000 fĂŒr eine Migration auf BW auf HANA bzw. BW/4HANA gewonnen werden [1]. Das ist die HĂ€lfte aller Kunden mit einem HANA-fĂ€higen Release.

HANA ist damit nicht nur im Mainstream angekommen, es ist die logische Plattform fĂŒr innovative Data-Warehouse-Implementierungen auf SAP-Basis.

 

SAP BW/4HANA und BW auf HANA - HANA-Plattform

Von der Idee zum Produkt vor 2010

Abbildung 1.2 zeigt grafisch die Entwicklungsgeschichte von HANA. SAP besitzt eine lange Erfahrung mit In-Memory-Technologien. Bereits 1998 wurde mit dem Advanced Planning and Optimization (APO) Live Cache eine In-Memory-Applikation auf Basis von MaxDB zur Absatz-, Distributions- und Produktionsplanung im Supply-Chain-Umfeld auf den Markt gebracht. Im Jahre 2000 folgte mit TREX (Text Retrieval and information EXtraction) eine In-Memory-Suchmaschine fĂŒr Volltextsuche, Klassifikation und Text Mining, die auf spaltenweiser Datenablage funktionierte.

SAP BW/4HANA und BW auf HANA - Evolution

Die Weiterentwicklung von TREX in den Bereich der strukturierten Daten brachte 2005 den BI Accelerator (BIA, spÀter BWA) hervor, der bereits Multi-Core CPUs und 64-Bit-Architekturen nutzte. Noch im gleichen Jahr wurde mit P*Time eine In-Memory OLTP-Datenbank akquiriert.

Im Jahr 2006 kam der entscheidende Anstoß zur Entwicklung einer IMDB von SAP-MitgrĂŒnder Hasso Plattner. Nach eigener Aussage in der EinfĂŒhrung seines In-Memory Data Management-Kurses am Hasso-Plattner-Institut (HPI) in Potsdam (https://openhpi.de/course/imdb2013) langweilte er seine Studenten mit einer Vorlesung ĂŒber Enterprise Resource Planning (ERP)-Systeme so sehr, dass er sich im Nachgang mit seinen Assistenten zusammensetzte und ĂŒber die Zukunft von Enterprise Software Gedanken machte [2]. Sie stellten sich die Frage:

Wie wĂŒrde ein ERP-System aussehen, wenn wir es heute von Grund auf neu entwickeln wĂŒrden?

Dabei sahen sie zwei wesentliche Fortschritte in der Hardwaretechnologie, die es zu nutzen galt:

  • massive Parallelisierung mit Multi-Core CPUs,
  • immer weiter steigende RAM-GrĂ¶ĂŸen auf Hauptplatinen.
Die MarkteinfĂŒhrung 2010–11

Im Mai 2010 wurde HANA auf der SAPPHIRE NOW in Orlando offiziell vorgestellt und Ende des Jahres im Rahmen eines Ramp-Up-Programms (Release to Customer – RTC) den Kunden zur VerfĂŒgung gestellt. Im Juni 2011 wurde die allgemeine VerfĂŒgbarkeit (General Availability – GA) erklĂ€rt.

Die ersten Einsatzszenarien von HANA waren im Bereich des operativen Reportings von Business-Suite-Daten in Echtzeit und dem Einsatz sogenannter Accelerators (siehe Abbildung 1.3). Ähnlich wie beim BWA, wurde hier ein HANA-System neben das Business-Suite-System gestellt, um spezielle Prozesse zu beschleunigen. Ein prominentes Beispiel ist der CO-PA Accelerator zur Beschleunigung der Ergebnisrechnung im ERP. Technisch wird dabei das HANA-System als sekundĂ€re Datenbank angebunden und die relevanten Daten aus der primĂ€ren ERP-Datenbank repliziert. Die entsprechenden Programme fĂŒhren sodann ihre langlaufenden Arbeiten auf Daten in HANA aus. FĂŒr die Nutzer ist dieser Zugriff völlig transparent, funktioniert allerdings um ein Vielfaches schneller.

SAP BW/4HANA und BW auf HANA - Sidecar

SAP HANA 2.0

Auf der SAP TechEd Konferenz 2016 in Barcelona wurde HANA 2.0 vorgestellt [3]. Damit ist HANA 1.0 offiziell im Wartungsmodus bis Mai 2019 [4]. Die neue Version von HANA bringt, Àhnlich wie die halbjÀhrlichen Service Packs zuvor, einige inkrementelle Verbesserungen und neue Features in allen Bereichen der HANA-Plattform. Unter anderem ist hier die neue FunktionalitÀt »Active/Active Read-Enabled« zu nennen, die es ermöglicht, dass auf das sekundÀre HANA-System im dualen Rechenzentrumsbetrieb auch lesend zugegriffen werden kann.

Dann gibt es einen SAP Enterprise Architecture Designer. Als Web-Applikation dient dieses Werkzeug den Kunden dazu, ihre komplexe SAP-Architektur abzubilden und zu visualisieren.

Ganz neu sind auch die cloudbasierten SAP HANA Microservices. Diese umfassen zur Drucklegung des Buches: Text Analysis Entity Extraction, Text Analysis Fact Extraction, Text Analysis Linguistic Analysis und Earth Observation Analysis Service.

Vorbereitung der Umstellung auf HANA

SpĂ€testens mit der Entscheidung, HANA als Datenbank fĂŒr Ihr Business Warehouse einzusetzen, sollten Sie Themen wie Sizing, Migration, Housekeeping und Rechenzentrumsbetrieb von HANA als Datenbank fĂŒr Ihr BW-System in Angriff nehmen.

Idealerweise haben Sie im Vorfeld der Entscheidung fĂŒr HANA schon ĂŒber diese Themen gesprochen. So ist etwa das Sizing nicht nur fĂŒr die GrĂ¶ĂŸe und Anzahl der benötigten Server maßgebend. Je nach Lizenzierungsmodell hat die DatenbankgrĂ¶ĂŸe auch Einfluss auf die Lizenzkosten.

Sizing

In den letzten Jahren waren wir beim Sizing vieler BW-auf-HANA-Systeme beteiligt. Der mit Abstand hĂ€ufigste Fall ist, ein bestehendes BW-System auf HANA zu migrieren, der sogenannte Brownfield-Ansatz. Weniger hĂ€ufig kommt der Greenfield-Ansatz vor, bei dem ein neues BW nur auf einem HANA-System betrachtet wird. Selten ist tatsĂ€chlich die ÜberfĂŒhrung eines Non-SAP-Data-Warehouse (DWH) in ein BW-System, weshalb wir diesen Fall nur kurz ansprechen werden.

Das richtige Sizing des Datenbankservers ist sehr wichtig, denn bereits hier können viele Fehler gemacht werden. Um das zu vermeiden, hat Marc Bernard einen sehr guten Blog mit den hÀufigsten Fehlern beim Sizing eines Business Warehouses auf HANA geschrieben.

SAP BW/4HANA und BW auf HANA - ServergrĂ¶ĂŸen

Scale-out-Konfigurationen fĂŒr BW-Systeme haben mindestens drei Rechnerknoten. Im Minimum sind hier zwei Worker-Knoten zu einem Master dringend empfohlen. Mehr Informationen zu Scale-out finden Sie im Abschnitt 2.4.2 zur Skalierbarkeit. ZusĂ€tzliche Details zum Sizing des Master-Knotens und zur optimalen Anzahl an Scale-out-Knoten erhalten Sie auch in den SAP-Hinweisen 1855041 und 1702409.

Migrationsoptionen und unterstĂŒtzende Werkzeuge

Nachdem das Sizing fĂŒr das neue BW auf HANA abgeschlossen ist, gilt es, die optimale Migrationsoption fĂŒr Ihr bestehendes BW-System zu identifizieren. Daran anschließend möchten wir Ihnen kurz das BW Migration Cockpit vorstellen, das eine große Hilfe vor, wĂ€hrend und nach einer Migration auf HANA ist.

Housekeeping

Wie jeden ordentlichen Haushalt, sollten Sie auch Ihr Business Warehouse-System permanent pflegen. Damit halten Sie es schlank und schnell. Die Wartung Ihres Systems sollte nicht nur die Nutzerdaten betreffen, sondern auch Metadaten, Monitoring- und StatistikeintrĂ€ge. Ebenso bedĂŒrfen temporĂ€re Tabellen und andere Systemdaten der regelmĂ€ĂŸigen Pflege.

Betrieb im Rechenzentrum

Aus dem Blickwinkel eines Rechenzentrums gibt es viele wichtige Aspekte die Umstellung auf HANA betreffend. Im Rahmen dieses Buches können wir nicht auf all diese Themen eingehen und konzentrieren uns daher auf einige aus unserer Sicht wichtige Gesichtspunkte.

FĂŒr eine eingehendere BeschĂ€ftigung verweisen wir auf das Buch »The SAP HANA Deployment Guide« von Bert Stechelmann (Espresso Tutorials).

Neuerungen in der Datenbewirtschaftung

Die Datenbewirtschaftung ist ein zentrales Thema des SAP BW. Wir beschrÀnken uns in diesem Buch auf die neueren Technologien wie Operational Data Provisioning (ODP) und die neuen Quellsystemtypen »SAP HANA« und »Big Data«. In diesem Kapitel lernen Sie, wie und in welchen Situationen Sie diese Technologien einsetzen können.

Operational Data Provisioning

FĂŒr die Bereitstellung von Daten zur weiteren Verarbeitung innerhalb oder außerhalb eines Unternehmens gibt es viele Verfahren. Typischerweise werden Daten ĂŒber eng verzahnte Schnittstellen oder zusĂ€tzliche Datenintegrationswerkzeuge (sog. ETL-Werkzeuge) ausgetauscht. Operational Data Provisioning (ODP) hebt diese enge Bindung zwischen Quelle und Ziel auf und bietet mit einem generischeren Ansatz eine neue QualitĂ€t der Datenintegration.

SAP BW/4HANA und BW auf HANA - ODP

Bei den ODP-Quellstrukturen wird grundsÀtzlich in Stamm- und Transaktionsdaten unterschieden. Die Stammdaten sind weiter in Attribute, Texte und Hierarchien unterteilt, wie Sie das von den InfoObjecten im BW kennen.

Neben der Entkopplung von Quelle und Ziel bringt ODP noch einige interessante Funktionen mit:

  • ODP ermöglicht die einmalige Extraktion der Quelldaten (Provider) und stellt sie mehreren Zielsystemen (Subscriber) zur VerfĂŒgung (»extract once, deploy many«).
  • Die ODQ ist eine SchlĂŒsselkomponente von ODP. Sie vereinheitlicht den Datenaustausch, die Konfiguration und das Monitoring fĂŒr alle Quell- und Zielsystemtypen mit zeitstempelbasiertem Wiederherstellungsmechanismus fĂŒr alle Datenquellen und separat konfigurierbaren Aufbewahrungsfristen (Data Retention) fĂŒr jedes Ziel.
  • ODP ermöglicht eine weitere Reduzierung der persistenten Datenschichten im BW bei gleichzeitiger VerkĂŒrzung der Datenlatenz. Sie können bei einer ODP-DataSource einen deltafĂ€higen DTP ohne PSA und InfoPackages anlegen (siehe Abbildung 3.2) und die Daten direkt aus der ODQ in InfoProvider laden.

Das HANA-Quellsystem

FĂŒr BW-Systeme auf HANA bzw. BW/4HANA stellt HANA einen zentralen und einheitlichen Zugriff auf alle Quellen zur VerfĂŒgung, die ĂŒber SAP HANA Smart Data Integration (SDI) oder SAP HANA Smart Data Access (SDA) bereitgestellt werden (Abbildung 3.10): das HANA-Quellsystem. Dieses ermöglicht zudem den Zugriff auf Tabellen oder Views der lokalen HANA-Datenbank.

Big-Data-Quellsystem

Das Big-Data-Quellsystem ermöglicht den einheitlichen und zentralen Zugriff auf Hadoop-Quellen, die ĂŒber Smart Data Access unter Verwendung des SAP HANA Spark-Controllers und des Spark-SQL-Adapters bereitgestellt werden. Seit BW/4HANA SP4 kann auch der VORA-ODBC-Adapter ĂŒber SDA verwendet werden.

Modernes Datenmanagement

In diesem Kapitel erklĂ€ren wir die unterschiedlichen Einsatzmöglichkeiten fĂŒr das Data Lifecycle Management im BW und wie Sie die Werkzeuge der SAP Data Warehousing Foundation fĂŒr BW einsetzen können.

Data Lifecycle Management

Die Datenhistorisierung und die Verwaltung des Lebenszyklus der Daten (Data Lifecycle Management) zÀhlen zu den wichtigen Aufgaben eines Data Warehouse. Je Àlter ein Datensatz ist, desto seltener wird darauf zugegriffen.

SAP BW/4HANA und BW auf HANA - Datenverwaltung

Data Warehousing Foundation

Die Option SAP HANA Data Warehousing Foundation (DWF) ist Bestandteil der meisten SAP-HANA-Lizenzen und beinhaltet verschiedene HANA-XS-basierte Werkzeuge zum Datenmanagement, die nicht nur fĂŒr große HANA-Installationen interessant sind. Die DWF ergĂ€nzt primĂ€r native HANA-Data-Warehouse-Implementierungen auf SQL-Basis, aber auch das BW auf HANA bzw. BW/4HANA und Architekturen mit hybrider Modellierung.

Neue ModellierungsansÀtze

In SAP Business Warehouse steht fĂŒr die Aufgabe der Datenmodellierung neben der klassischen Data Warehousing Workbench (frĂŒher auch Administrator Workbench genannt) jetzt außerdem eine Eclipse-basierte BW-Modellierungsperspektive in SAP HANA Studio zur VerfĂŒgung. Dies ist nur eine von vielen Neuerungen auf die wir in diesem Kapitel eingehen werden.

Änderungen an bestehenden BW-Objekten

Seit BW 7.3 haben sich massive Neuerungen an bisherigen Datenmodellen und DatenflĂŒssen ergeben. Diese setzen mit wenigen Ausnahmen den Einsatz von HANA voraus, sodass Ihnen diese Funktionen verschlossen bleiben, wenn Sie Ihr BW-System nicht auf einer SAP-HANA-Datenbank betreiben.

SAP-BW-Modellierungstools

  • BW 7.4 SP4 mit BW-MT 1.0: CompositeProvider, Open ODS View,
  • BW 7.4 SP9 mit BW-MT 1.5: DSO (advanced),
  • BW 7.5 SP1 mit BW-MT 1.11: Query Designer,
  • BW 7.5 SP1 mit BW-MT 1.12: InfoObject,
  • BW 7.5 SP4 mit BW-MT 1.14: DataSource, InfoArea, InfoSource, OpenHubDestination, Aggregationsebene, semantische Gruppe,
  • BW/4HANA 1.0 mit BW-MT 1.15: Datenfluss-Editor,
  • geplant fĂŒr BW/4HANA: Transformation.

Neue BW-InfoProvider

Mit SAP HANA wurde das Business Warehouse um eine Vielzahl von Funktionen erweitert. Eine besondere Bedeutung kommt dabei neuen Datenmodellen zu, die dazu dienen, die bisherigen BW-Objekte aus Abschnitt 5.1 nach und nach vollstĂ€ndig zu ersetzen. WĂ€hrend Ihnen mit SAP BW auf HANA noch alle neuen und klassischen Funktionen zur VerfĂŒgung stehen, entfallen die alten Objekte beim Umstieg auf BW/4HANA in GĂ€nze.

SAP HANA reduziert die KomplexitĂ€t in der Data-Warehouse-Architektur, indem die große Anzahl existierender Modelltypen auf nur noch vier reduziert wird (siehe Abbildung 5.17): Stammdaten werden weiterhin als InfoObjects dargestellt, Bewegungsdaten verwaltet das neue DataStore-Objekt (advanced), und als virtuelle Datenmodelle stehen der neue CompositeProvider bzw. Open ODS View zur VerfĂŒgung. WĂ€hrend InfoObjects bereits in Abschnitt 5.1.2 behandelt wurden, erörtern wir im weiteren Verlauf die verbleibenden drei neuen Datenmodelle.

Beachten Sie bitte, dass die klassischen Datenmodelle aus KompatibilitĂ€tsgrĂŒnden in Version 7.4 und 7.5 noch unterstĂŒtzt werden, es besteht daher kein sofortiger Migrationszwang. Sie sollten aber keine neuen Anwendungen mit den obsoleten Objekten aufbauen, denn diese werden in BW/4HANA nicht mehr unterstĂŒtzt.

SAP-HANA-Modellierung

SAP HANA liefert als Entwicklungsplattform neben der Datenbank viele weitere funktionale Komponenten, die eng an diese Datenbank gekoppelt sind. Darauf basierend ist es möglich, vollstÀndige Anwendungen auch ohne ABAP-Applikationsschicht (wie beispielsweise SAP BW) abzubilden. In diesem Abschnitt betrachten wir diese Möglichkeiten genauer und werden als Modellierungswerkzeug auf den SAP HANA Modeler im SAP HANA Studio eingehen.

Datenmodelle, die Sie in BW als InfoObject oder DataStore-Objekt definieren, nennt man in der nativen SAP-HANA-Welt HANA Views (oder HANA Information Views), deren Daten in HANA-Tabellen abgelegt sind. HANA Views haben die Aufgabe, ZusammenhĂ€nge zwischen Tabellen aufzuzeigen und die Felder bereitzustellen, die fĂŒr ein bestimmtes Datenmodell notwendig sind.

Sie bieten somit eine Art semantische Schicht, welche beschreibt, wie einzelne EntitĂ€ten miteinander verbunden sind, in welchem mengenmĂ€ĂŸigen VerhĂ€ltnis sie zueinander stehen. Dazu kommen weitere Details, wie beispielsweise die Bedeutung und das Verhalten von Kennzahlen.

Neuer Content

Mit BW auf HANA wurde auch ein neuer und entsprechend optimierter SAP BI Content geschaffen. Im Kontext von BW/4HANA nennt sich dieser Content Add-on. Das neue Standard-Datenmodell folgt den Empfehlungen der aktuellsten Data-Warehouse-Architektur (LSA++, siehe Abschnitt 6.2) und erweitert das Analyseangebot um Echtzeitanalysen bzw. Auswertungen auf Einzelpostenebene. Die Vorlagen basieren auf den neuesten HANA-optimierten InfoProvidern und nutzen wo möglich HANA-optimierte Transformationsregeln.

Die Datenextraktion bleibt allerdings unverĂ€ndert und erfolgt ĂŒber die bekannten BW-DataSources (beispielsweise 2LIS-Objekte fĂŒr Materialmanagement aus dem Logistik-Cockpit). Außerdem enthĂ€lt der Content mittlerweile auch HANA Views und stellt somit sogar gemischte Modellierungsszenarien bereit.

Bisher werden folgende SAP-ERP-Kernbereiche abgedeckt:

  • Vertrieb: Übersicht, Lieferung, Fakturierung, Konditionen, Servicegrad und AuftragsrĂŒckstand*.
  • Finanzwesen: Hauptbuch, Anlagenbuchhaltung, Debitorenbuchhaltung* und Kreditorenbuchhaltung.
  • Controlling: Gemeinkostenrechnung, Profit-Center-Rechnung, Produktkostenprognose* und -simulation.
  • Materialwirtschaft: Beschaffung, RechnungsprĂŒfung, VertrĂ€ge und Servicegrad, Lagerbestand.

(* = Bereiche mit HANA Views)

SAP-BW-Referenzarchitektur

Dieses Kapitel beschreibt einleitend die von SAP vorgeschlagene BW-Referenzarchitektur »Layered Scalable Architecture (LSA)« und fokussiert sich im Anschluss auf die Auswirkungen, die SAP HANA auf dieses Konzept hat. Neben den Änderungen einer HANA-optimierten Architektur erlĂ€utern wir hier auch die Schritte, die man logisch gehen könnte, um eine existierende LSA auf BW auf HANA bzw. BW/4HANA anzupassen.

Layered Scalable Architecture klassisch

SAP BW/4HANA und BW auf HANA - Layered Scalable Architecture

Layered Scalable Architecture auf HANA

Wie Sie schon an vielen Beispielen in den Kapiteln zuvor sehen konnten, bietet SAP HANA als Datenbank fĂŒr Ihr BW-System ein sehr hohes Maß an FlexibilitĂ€t bei der Realisierung von Modellierungskonzepten. Dies schlĂ€gt sich auch auf die LSA-Referenzarchitektur nieder, die in ihrer bisherigen Form nur bedingt geeignet ist, BW auf HANA bzw. BW/4HANA abzubilden. Somit ist aus LSA eine HANA-optimierte Erweiterung hervorgegangen, die als LSA++ bekannt ist.

LSA++ steht fĂŒr eine ĂŒberarbeitete, ganzheitliche Schichtenarchitektur, welche auf die Besonderheiten von BW auf HANA und BW/4HANA ausgerichtet ist. Damit ist HANA aber auch zwingende Voraussetzung, um die Referenzarchitektur von LSA in LSA++ zu ĂŒberfĂŒhren. Der flexible und konsistente Kern des EDW bleibt hierbei bestehen und wird in der LSA++ mit speziellen Services fĂŒr operationale und flexible Daten angereichert.

SAP BW/4HANA und BW auf HANA - Layered Scalable Architecture ++

Umwandlung einer LSA in LSA++

In diesem Abschnitt erlĂ€utern wir Ihnen, wie Sie ein BW-System, welches nach LSA-Prinzipien strukturiert ist und betrieben wird, im Anschluss an eine erfolgreiche Migration auf SAP HANA schrittweise in eine erweiterte LSA++-Architektur ĂŒberfĂŒhren.

Die neue Rolle von SAP BW fĂŒr das operative Reporting

Berichtswesen auf den operativen GeschĂ€ftsprozessen in Echtzeit – das ist eine Anforderung, mit der sich Unternehmen hĂ€ufig schwertun. Dieses Kapitel beleuchtet die Rolle von SAP BW in diesem Kontext und zeigt die sich durch SAP HANA ergebenden neuen Alternativen auf.

Operatives Reporting reprĂ€sentiert ein Berichtswesen, das sich auf aktuelle TĂ€tigkeiten in den tĂ€glichen GeschĂ€ftsprozessen eines Unternehmens konzentriert und somit die taktische Entscheidungsfindung unterstĂŒtzt. Ein Beschaffungscontroller beispielsweise wird zunĂ€chst den Lagerbestand prĂŒfen, bevor er eine Bestellung auslöst. Weiterhin wird er zwischen verschiedenen Lieferanten, Versandwegen oder Produktvarianten entscheiden mĂŒssen.

Um diesen Prozess optimal zu steuern, benötigt er Analysen bezĂŒglich des Warenbestands, der LieferqualitĂ€t, Preisentwicklung usw. So ist heutzutage das typische Arbeitsmuster fĂŒr viele regelmĂ€ĂŸig wiederkehrende GeschĂ€ftsprozesse ein stĂ€ndiger Wechsel zwischen Einzeltransaktion und Datenanalyse

Die Entwicklung von SAP HANA bietet an dieser Stelle enormes Potenzial fĂŒr Verbesserungen. Wie Sie ebenfalls in Abbildung 7.1 erkennen, sind die SAP-ERP-Lösungen auf HANA heutzutage in der Lage, die operativen Berichtsanforderungen abzudecken. Dies vermeidet eine teure Datenredundanz sowie Zeitverzögerung und verlagert diese Aufgabe dorthin zurĂŒck, wo sie am besten umgesetzt werden kann: in das Quellsystem.

Kann man daraus folgern, dass SAP BW ĂŒberflĂŒssig wird, wie manche behaupten? Wir sind ĂŒberzeugt, dass dies nur fĂŒr ganz seltene Ausnahmen zutreffen wird: Nur wenn das BW-System ausschließlich fĂŒr operatives Reporting genutzt wird und diese Rolle vollstĂ€ndig vom SAP-ERP-System ĂŒbernommen werden kann, ist BW tatsĂ€chlich ĂŒberflĂŒssig.

In den allermeisten Organisationen ist die Hauptaufgabe des BW jedoch, Daten aus verschiedensten Quellen zu integrieren und so aufzubereiten, dass eine bestmögliche UnterstĂŒtzung fĂŒr taktische und strategische Entscheidungsfindungen gegeben ist. FĂŒr die Kernfunktion »Enterprise Data Warehousing«, bei der Daten langfristig und bewusst in vom Quellsystem abweichenden Strukturen abgelegt werden, wird BW auch in Zukunft das SAP-Werkzeug der Wahl sein.

Operatives Berichtswesen in SAP ERP

Wir haben bereits hervorgehoben, dass SAP HANA die ideale In-Memory-Plattform fĂŒr Analysen (OLAP) und tĂ€gliche GeschĂ€ftsprozesse (OLTP) bietet. Nur mit SAP HANA als Basis lassen sich Analysen direkt auf SAP-ERP-Daten erstellen und ein tieferes VerstĂ€ndnis der aktuellen GeschĂ€ftsdaten in Echtzeit erhalten.

Das operative SAP-Berichtswesen ermöglicht den hochperformanten Zugriff auf SAP-Daten in der SAP-HANA-Datenbank mithilfe von Views. So werden kurzfristige Analysen großer Datenmengen in Echtzeit angeboten, ohne die Daten in ein separates System transferieren zu mĂŒssen.

Zusammenwirken von SAP BW mit dem operativen Berichtswesen

Mit SAP HANA Live bzw. S/4HANA Embedded Analytics fĂŒllt SAP die ursprĂŒngliche HANA-Vision, transaktionale und analytische AnwendungsfĂ€lle aus einem System und aus einer Datenbasis heraus bedienen zu können, mit Leben.

Die Views des operativen Berichtswesens lassen sich ĂŒber die neuen BW-Datenmodelle Open ODS View (im Fall von HANA Live Calculation Views auch ĂŒber CompositeProvider) in die Data-Warehouse-Architektur einbinden. Dies erfolgt virtuell ohne physischen Datenfluss und gilt sowohl fĂŒr Stammdaten als auch fĂŒr Bewegungsdaten.

Zusammenfassung und Ausblick

Sie haben auf den vorangegangenen Seiten detailliert die neuen Funktionen und HANA-spezifischen Optimierungen fĂŒr BW bzw. BW/4HANA kennengelernt. Diese Vorteile möchten wir nun fĂŒr Sie noch einmal zusammenfassen und Ihnen aufzeigen, wie Sie sie nutzen können, um Kosten einzusparen und Ihren Systembetrieb effizienter zu gestalten.

Wie Sie von BW auf HANA profitieren

Performance ist hĂ€ufig die erste Eigenschaft, die mit SAP HANA in Verbindung gebracht wird – das ist auch im Zusammenhang mit BW oder BW/4HANA nicht anders. Dabei gehen die Vorteile von HANA als Plattform fĂŒr BW deutlich ĂŒber die Performance-Aspekte hinaus. Wie Hasso Plattner schon sagte, zĂ€hlt nicht die Geschwindigkeit selbst, sondern was durch die Geschwindigkeit ermöglicht wird. Deshalb sind die wesentlichen Vorteile von BW auf HANA neben der Performance: Simplifizierung und Optimierung.

29,95 €
SAP BW/4HANA und BW auf HANA

SAP BW/4HANA und BW auf HANA

  • Seiten: 296
  • Sprache: Deutsch

Das Buch bietet Ihnen den schnellen Einstieg in SAP NetWeaver Business Warehouse (BW).

  • Grundlagen von Business Intelligence (BI)
  • Die Data Warehouse Workbench
  • Die Business Explorer Suite
  • Extraktion, Transformation und Laden von Daten
Jetzt kaufen

Themen: BW, HANA

FĂŒr den Newsletter anmelden und nie mehr Neuerungen verpassen!

Über uns

In unseren PrintbĂŒchern und E-Books servieren wir SAP-Wissen wie einen Espresso: Auf das Wesentliche – angereichert mit konkreten Fallbeispielsen und Videos.

Schlagwörter

  • Analysis
  • Analysis Office
  • Analytics
  • Analyzer
  • Berechtigung
  • BEx
  • BI
  • BPC
  • BusinessObjects
  • BW
  • Cloud
  • Design Studio
  • Einstieg
  • HANA
  • Lumira
  • Performance
  • Web Intelligence

Copyright 2022 Espresso Tutorials GmbH