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.
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.
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 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.
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.
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.
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,
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
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.
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
Seiten: 296
Sprache: Deutsch
Das Buch bietet Ihnen den schnellen Einstieg in SAP NetWeaver Business Warehouse (BW).
