Lange wurden DWH-Lösungen – insbesondere im SAPDie SAP SE mit Sitz im baden-württembergischen Walldorf ist ein… Kosmos – als Single-Point-of-Truth für das Berichtswesen zu den operativen Systemen eines Unternehmens gesehen. Oberstes Ziel war es, eine hohe Stabilität und Qualität sicherzustellen.
Die strukturierten Daten aus den operativen ERP Systemen wurden schichtenweise aufbereitet und redundant gespeichert als Grundlage für die Konsumierung durch BI Frontend-Werkzeuge. Ein in der SAP BW Welt weit verbreiteter Architekturansatz für die systemische Abbildung ist das Schichtenmodell LSA (layered scalable architecture).
Durch die schichtenweise Aufbereitung von Daten im Rahmen des LSA Konzepts kann eine hohe Stabilität und Qualität sichergestellt werden. Gleichzeitig werden operative Systeme von Reportinganfragen entlastet. Auf der anderen Seite entstehen jedoch durch Persistierung der Daten in mehreren Schichten zahlreiche Redundanzen. Dies, und der (in alten SAP BW Systemen verbreitete) sehr wissenschaftliche Ansatz einer vollständigen Top-Modellierung, führen zu einer monolitischen Architektur. Anpassungswünsche führen schnell zu hohen Entwicklungsaufwänden. Das System ist damit weder flexibel gegenüber Datenmodellanpassungen, noch unterstützt es inkrementelle Weiterentwicklungen.
Die Anforderungen haben sich verändert
Statt der Fokussierung auf Qualität und Stabilität sowie die Integration operativer strukturierter Daten in einen “Single-Point-of-Truth”, gibt es neue bzw. veränderte Anforderungen an BI Landschaften und das Data WarehouseEin Data Warehouse ist für die Ausführung, Überwachung und Steuerung…. Wir möchten im Folgenden gerne ein paar dieser neuen und veränderten Anforderungen an Data Warehouse hervorheben:
Bedarfsgerechte Qualität
Hohe Datenqualität und Verlässlichkeit der Daten haben weiterhin einen hohen Stellenwert – beispielsweise bei Finanzauswertungen, Erstellung von Jahresabschlüssen oder auch bei Prognosen von Kündigungswahrscheinlichkeiten der Kunden zu Steuerung von zielgerichteten Marketingmaßnahmen. Es wäre ungünstig, wenn die Kündigungswahrscheinlichkeit eines Kunden aufgrund fehlerhafter Daten systematisch falsch eingeschätzt wird. Es wird viele solcher Fälle geben, bei denen es absolut wichtig ist, 100% korrekte Daten zu haben.Ungeachtet dessen können auch Daten mit hinreichender Qualität (bspw. 3% Fehlerquote) einen analytischen Mehrwert bedeuten und sollten nicht von vorhinein verworfen werden. Je nach Zweck und statistischen Verfahren kann mit einer eingeschränkten Datenqualität “gelebt” werden. So ist bei Social Media Daten nicht damit zu rechnen, dass bei jedem Datensatz vollständige Daten vorliegen. Trotzdem würde dadurch niemand auf diesen Daten komplett verzichten.
- Integration neuer Daten
Neben kaufmännischen Prozessen in ERP Systemen gibt es neue Prozesse und Datenquellen (Maschinendaten, Social Media, etc.). Diese Daten liegen nicht immer strukturiert vor. Das klassische Data Warehouse bietet hier keine Lösung für die Ablage von Big Data. In vielen Firmen gibt es bereits heute eigene (Big) Data Lakes zur Sicherung und Strukturierung von Big Data. Häufig bringen diese Data Lakes eigene analytische Funktionen mit (z.B. Spark) um Abfragen zu erstellen oder mehrschichtige Architekturen abzubilden. Benötigt wird eine Integration zwischen dem Data Warehouse und Data Lake. - Flexibilität
Datenmodelle werden nicht (mehr) für die Ewigkeit konzipiert und entwickelt. Die Erwartung von Nutzern ist, dass sich bestehende Datenstrukturen flexibel erweitern lassen um neue Inhalte – durch die IT oder Fachbereiche in eigens dafür bereitgestellten Lösungen. Das Data Warehouse Design muss diese Flexibilität und kontinuierliche Veränderungen von Anfang an einplanen. - Agilität und die Reduktion von Time-to-Value / Analytics
Die Welt, in der BI Systeme in einem Business Blueprint exakt vorab beschrieben worden sind, um diese dann über mehrere Monate hinweg zu entwickeln, ist vorbei. Im Zweifel hat sich die Anforderung seit Erstellung des Blueprints schon wieder verändert und die Anwender erhalten ein Feature, welches nicht benötigt wird – dann gilt der Satz “works as designed”. Dies hilft aber weder der IT noch den Fachbereichen weiter. Mag es in sehr reglementierten Märkten, wie bei Banken, erforderlich sein, durch umfangreiche Konzepte die Einhaltung von Regularien nachzuweisen, dürfte dies für viele Firmen nicht notwendig sein. Anforderungen sind einfach zu kurzlebig und ständigen Änderungen unterworfen. Features müssen schneller, d.h. nach Tagen bzw. wenigen Wochen, ausgeliefert werden. Dies kennen wir – auch im Privatleben – aus der Softwareentwicklung und prägt unsere Erwartungshaltung an IT-Systeme. Amazon & Co machen es vor. Data Warehouse Systeme müssen agile MethodenWas sind agile Methoden?Agile Methoden kommen aus dem Bereich der… unterstützen um die Erwartung der Anwender zu treffen.
Die Welt hat sich veränderT
Früher war das Data Warehouse als Single Point of Truth für BI Werkzeuge meistens die einzige Quelle. Heute ist die Sichtweise auf BI Landschaften differenzierter. S/4 HANA ermöglicht operatives Reporting direkt im operativen System. Aus analytischer Sicht wird das System damit gleichwertiger zu einem Data Warehouse. Neue Datenformate und hohe Mengen an Daten mit analytischem Potential werden zudem in Data Lakes gespeichert. Eine “analytische Plattform” besteht also nicht nur aus dem Data Warehouse, sondern ebenfalls aus entsprechenden operativen Systemen genauso wie Data Lakes. Wichtig ist eine gute Integration dieser Komponenten. Dabei kann Data Warehouse eine Schlüsselrolle sein als Bindeglied zwischen kfm. Informationen und aggregierten Daten aus dem Data Lake. Eine solche abgestimmte Datenmenge bietet Potentiale im Bereich Advanced Analytics. Einen guten Überblick zur Positionierung von SAP HANA und dem Weg zu einer solchen analytischen Plattform gibt das folgende ISR Whitepaper, welches bei der TDWI veröffentlicht worden ist.
Auf diese Anforderungen ausgerichtete Architekturkonzepte und Entwicklungsmethoden sind notwendig. Für historisch gewachsene Systeme besteht in jedem Fall ein hoher Veränderungsdruck. Ob sich Ihre bestehenden Systeme so verändern lassen, dass die veränderten Anforderungen und Rahmenbedingungen abbildbar sind oder ganz neue technische Lösungen gefunden werden müssen. Wir beraten Sie gerne.
Christopher Kampmann
Senior Manager
SAP Information Management
christopher.kampmann@isr.de
+49 (0) 151 422 05 448
