Praxishandbuch SAP Business Warehouse mit BW/4HANA. Jürgen Noe
Чтение книги онлайн.

Читать онлайн книгу Praxishandbuch SAP Business Warehouse mit BW/4HANA - Jürgen Noe страница 4

Название: Praxishandbuch SAP Business Warehouse mit BW/4HANA

Автор: Jürgen Noe

Издательство: Автор

Жанр: Программы

Серия:

isbn: 9783960120278

isbn:

СКАЧАТЬ unterstützt habe. Technisch ermöglicht haben dies sogenannte Data Warehouses, die in der Lage sind, sehr große Datenmengen in einer Datenbank zu speichern und die die Möglichkeit bieten, Daten gezielt zu filtern sowie mit statistischen Verfahren der Varianzanalyse oder Stichprobentheorie auf Zusammenhänge zu prüfen. Außerdem lassen sich in kurzer Zeit Rechenoperationen oder Abfragen performant ausführen. 1988 stellte IBM als erstes Unternehmen ein Data Warehouse vor.

      1.2.1 Definition Data Warehouse

      Das Gabler Wirtschaftslexikon definiert den Begriff »Data Warehouse« als

      »… eine von den operativen Datenverarbeitungssystemen separierte Datenbank, auf die nur Lesezugriff besteht. In regelmäßigen Abständen werden aus den operativen DV-Systemen unternehmensspezifische, historische und daher unveränderliche Daten zusammengetragen, vereinheitlicht, nach Nutzungszusammenhängen geordnet, verdichtet und dauerhaft in der Datenbasis des Data Warehouse archiviert. Ziel ist die Verbesserung der unternehmensinternen Informationsversorgung (Wissensmanagement) und damit der Unterstützung strategischer Entscheidungen. Als analytisches System liefert es Informationen zur Problemanalyse – Online Analytical Processing (OLAP) –, die durch die Anwendung von Methoden (z.B. des Data Mining) generiert werden.« [3]

      Berichtswesen im Data Warehouse

      Im Vordergrund eines Data Warehouse steht weniger das operative als vielmehr das taktische oder strategische Berichtswesen zur optimierten Entscheidungsfindung für das Unternehmensmanagement.

      Die Daten aus den operativen Systemen werden in mehreren Schritten verdichtet, vereinheitlicht und geordnet, bis sie für das Berichtswesen im Management den geforderten Aggregierungsgrad aufweisen. Viele Unternehmen betreiben daher in der Praxis ein mehrschichtiges Data Warehouse, wie in Abbildung 1.1 dargestellt.

      Abbildung 1.1: Data-Warehouse-Schichten

       Die unterste Ebene enthält sehr detailliert operative Daten aus den angeschlossenen Vorsystemen, wie beispielsweise einem ERP- oder CRM-System. Meist finden sich hier die einzelnen Belege wie Bestellungen, Kundenaufträge oder Buchungsbelege aus der Finanzbuchhaltung.

       In der Ebene Business Transformation (Umwandlung in Fachbereichsdaten) werden die operativen Daten interpretiert, harmonisiert und meist auch auf weniger Details verdichtet. In der Folge könnte das etwa bedeuten, dass nicht mehr der einzelne Buchhaltungsbeleg betrachtet, sondern z.B. ein Kontensaldo ermittelt wird. Auf dieser Ebene sind darüber hinaus zusätzliche Ableitungs- oder Zuordnungsregeln definiert, nach denen die Daten gegliedert werden. Hier kann man hinterlegen, welche Konten einer Tochtergesellschaft welchen Konten des Gesamtkonzerns zugeordnet sind.

       Nach der Business Transformation werden die Daten an die Reporting-Ebene weitergeleitet. Dort stehen sie für das Berichtswesen zur Verfügung. Meist werden die Daten auf der obersten Ebene noch weiter verdichtet, um ein leistungsstarkes Berichtswesen zu ermöglichen. Hier lassen sich letztlich die konsolidierte Bilanz des Konzerns sowie, bei Bedarf, die Bilanzen der Tochtergesellschaft abrufen.

      Aus dieser Übersicht wird zum einen deutlich, dass die Daten in einem klassischen Data Warehouse oft redundant gespeichert werden, was viel Speicherplatz erfordert. Zum anderen bietet sich durch den Einsatz eines Data Warehouse die Möglichkeit, auf der Basis von vereinheitlichten und hoch aggregierten Daten zu berichten. Dies entlastet die operativen Systeme.

      Basierend auf diesen Annahmen sowie mit zunehmendem Praxiseinsatz wuchs die Erkenntnis, dass Data Warehouses eine spezielle Architektur erfordern, um Insellösungen und Datensilos zu vermeiden.

      Im Jahr 1996 war es Bill Inmon vorbehalten, die Idee einer Corporate Information Factory (CIF) zu veröffentlichen. Sie ist in der vereinfachten Abbildung 1.2 dargestellt.

      Abbildung 1.2: Corporate Information Factory

      Die Kernidee einer CIF ist, dass Daten aus dem gesamten Unternehmen in einem von Bill Inmon skizzierten Enterprise Data Warehouse (EDW) abgelegt werden und dort nachgelagerten Systemen für Auswertungen zur Verfügung stehen. Im ersten Schritt werden die Daten aus verschiedensten Vorsystemen oder Applikationen extrahiert und in einem Staging-Bereich gespeichert. Hier können sie im nächsten Schritt per Extraktion, Transformation und Laden (ETL) homogenisiert und verdichtet werden, damit sich anschließend weitere Zusammenhänge zwischen ihnen ableiten lassen.

      Staging

      Die Prozessierung der Daten über Extraktion aus den angeschlossenen Quellsystemen bis hin zur Bereitstellung in Data Marts heißt Staging.

      Im Anschluss an das ETL werden die Daten meist in verschiedenen Data Marts des Enterprise Data Warehouse gespeichert. Ein Data Mart kann in diesem Kontext einerseits eine persistente anwendungsspezifische Sicht, andererseits eine für einen bestimmten Organisationsbereich erstellte persistente Sicht auf die Daten sein.

      Im Zentrum der CIF steht das Enterprise Data Warehouse, das die Daten an nachgelagerte Systeme liefert. Dies können Decision-Support-Systeme oder sogenannte Departmental Data Marts sein, also abteilungs- oder fachspezifische Data Marts. Die Daten im EDW erfüllen folgende Eigenschaften:

       granular

       integriert

       historisch

      1.2.3 Die Referenzarchitektur LSA

      Parallel zur Entwicklung der ersten Data Warehouses wuchsen, bedingt durch den Aufstieg von SAP R/3 zum Werkzeug für die unternehmensweite Ressourcenplanung, die Anforderungen an das unternehmensinterne Berichtswesen. Mithilfe des herkömmlichen ERP-Systems waren diese Anforderungen nur noch schwer zu erfüllen.

      In der ersten Hälfte des Jahres 1997 ging SAP Business Information Warehouse 1.2A für wenige ausgewählte Kunden an den Start. Bill Inmon hatte dazu mit seiner CIF-Idee architektonisch die Vorarbeit geleistet. Die SAP griff seine Idee auf und nutzte sie für die generelle Strukturierung und Modellierung des eigenen Business Warehouse. Architektonisch war das SAP Business Warehouse bis zur Version 7.5 in die Infrastruktur von SAP NetWeaver integriert. Im Laufe der Zeit entwickelte sich SAP Business Warehouse durch den sogenannten Business Content kontinuierlich weiter, mit dem schnell und einfach betriebliche Prozesse verschiedener Branchen abgebildet werden konnten. Mit der zunehmenden Anzahl an Funktionalitäten und neuen Einsatzgebieten stieg jedoch auch die Komplexität und warf bei den Anwendern Fragen bezüglich der Data-Warehouse-Architektur auf. Die klassische Schichtenarchitektur erwies sich in vielen Belangen als zu starr und wenig flexibel bezüglich Anpassungen und Erweiterungen. Den Fachabteilungen dauerte es oft zu lange, bis eine angeforderte Änderung produktiv gehen konnte.

      Mit den Jahren und mit zunehmender Erfahrung im dauerhaften Betrieb eines Warehouse setzte sich die Erkenntnis durch, dass ein Business Warehouse eine zukunftsfähige Architektur benötigt, die mit dem Unternehmen mitwachsen kann. 2009 entwarf SAP eine skalierbare Architektur unter dem Namen Layered Scalable Architecture (LSA), also skalierbare Schichtenarchitektur.

      Zentraler Ansatzpunkt war, dass man auch zukünftig in der Lage sein wollte, schnell sowie mit nur wenigen Eingriffen in die existierenden СКАЧАТЬ