SIB

• Data Warehouse: (Möglichst…) Unternehmensweit vereinheitlichte, konsistente, zeitbezogene Sammlung von Daten als Grundlage für die Entscheidungen und die Deckung des InformaƟonsbedarfs der Mitarbeiter mit Führungsaufgaben. (= Datenbasis für analyƟsche InformaƟonssysteme)

• Zweck: Der Grundgedanke des Data Warehouses ist es, dass ich eine Datensammlung schaffe, welche in der Lage ist, das Berichtswesen des Unternehmens zu unterstützen, und zwar muss sie dafür vereinheitliche Daten beinhalten. Eine Historie von Daten und auch vereinheitliche Daten, die längerfrisƟg gespeichert werden.

• Hintergrund: Wenn ich eine heterogene SystemlandschaŌ habe, wo Daten in verschiedener Form herumschwirren, brauchen wir eine Stelle in der Firma, in welcher Daten vernünŌig

• Begriff „Staging“ ist nicht SAP spezifisch, sondern Data Warehouse spezifisch.

• Das ist die Ebene, in der im Prinzip die Daten auf die Bühne des Data Warehouses gehoben werden

• Der schwerwichƟgste Prozess in der Staging-Ebene ist ETL (ExtrakƟon – TransformaƟon – Laden (ETL)

o Den zu designen ist die Kunst des Data Warehouse

o Der ETL-Prozess hat nicht unbedingt damit etwas zu tun, dass es immer ein physisches Daten weg speichernder Prozess ist, sondern es kann auch ein virtueller Prozess sein. Ich kann auch sagen, wenn der Bericht läuŌ, dann hole ich mir die Daten zur Laufzeit irgendwo her (virtuelles Data Warehouse: LSA++, usw.)

o Früher tradiƟonell und heute auch bei vielen Unternehmen im Einsatz: Ein Prozess der Daten extrahiert, transformiert, also umwandelt und dann in ein Data Warehouse lädt

o Die Aufgaben der Staging-Ebene ist es, diesen ETL-Prozess durchzuführen  Da wird die Datenebene erstmal harmonisiert, sie werden angereichert, sie werden manchmal gefiltert und an manchen Stellen auch angepasst oder kumuliert

 Beispiel 1: Manchmal muss es schnell gehen und der Manager will einen Bericht sehen und dann baut man sich einen kleinen Data Mart und zieht sich die Daten in diesen Data Mart. Das heißt man baut jetzt nicht diese kompleƩe Strecke, den Datenfluss kompleƩ aus, sondern man kürzt ab. Dann fällt das zentrale Data Warehouse da raus und man macht quasi einen kleinen Short Cut. Kann man machen, wird teilweise auch bewusst gemacht, aber man muss in Sorge tragen, dass das auch später wieder bereinigt werden, wenn der Bericht sich als gut rausstellt und man ihn behalten möchte, dann muss man ihn in die normale Data Warehouse Architektur überführen

Beispiel 2: Es werden die Data Mart Schicht weggelassen

• Das sind die unterschiedlichen Philosophien wie mit Daten umgegangen wird

• OLTP (TransacƟonal Processing: Es gibt SoŌware-Systeme, die sind für TransakƟonsverarbeitung geeignet (vgl. Modul FCS), da hämmert die Buchhaltung jeden Tag Daten rein)

• OLAP(AnalyƟcal Processing: Das, was Controlling vor allem macht, dass man die Daten analysiert, auswertet und aggregiert. Das ist technisch eine andere Anforderung an die Systeme, deswegen sind die Systeme früher auch anders aufgebaut worden. Mit S/4 HANA hat sich das ein bisschen relaƟviert, aber früher war es so (in vielen Unternehmen ist es auch heute noch so), dass man Systeme hat, die für diese)

MaßendatentransakƟonen im Sinne von SchreibtransakƟonen gemacht sind (OLTP) und die anderen, die für flexible Analysen usw. gemacht sind (OLAP)

• Drill-down ist im Endeffekt, dass ich von einer aggregierten Sicht in eine detaillierte Sicht runtergehe, dass ich z.B. von einer Jahressumme auf die Monate runtergehe oder von einem Unternehmensgesamtwert auf die Umsätze pro Produkt

• Roll-up ist die Gegenteilige Richtung, dass ich von detaillierter Datensicht anfange und schriƩweise Details rauslasse und das System aggregieren lasse.

• Für die Gestaltung von einem Data Warehouse ist der Aspekt Roll-up am schwierigsten und kann auch zu Problem führen. Die Begründung dafür ist, dass nicht jede Zahl nach Dimensionen aggregierbar ist. Manche Sachen kann ich über die Zeitschiene nicht aggregieren, manche darf ich über die Zeitschiene aggregieren und manche darf ich gar nicht aggregieren, also weder über die Zeitschiene noch über eine andere Dimensio

Man analysiert Kennzahlen, wenn man in einem BI-Projekt ist, detaillierter als wenn man sie nur in der BWL anschaut. Wenn wir es technisch umsetzen wollen, dann müssen wir verstehen, wie diese Kennzahlen Ɵcken.

Zusammengefasst ist der InformaƟonsstand die Infos, die geliefert werden, also das Angebot, dass wir zur Verfügung stellen. Die werden vom Leser tatsächlich gelesen und konsumiert (die InformaƟonsnachfrage, die sich mit dem Angebot überlappt). Der Teil dieser InformaƟonen, der einen objekƟven Nutzen hat, der also wirklich für eine bessere Entscheidung notwendig ist, weil man sie tatsächlich braucht, das ist der InformaƟonsstand.

• Zuerst kommt normalerweise immer die technische Harmonisierung

• In der klassischen LSA im Prinzip immer in den unteren Schichten, also insbesondere Quality & HarmonizaƟon-Ebene und die betriebswirtschaŌliche kommt dann später auĩauend auf den gespeicherten harmonisierten Daten auf diesen Data Propergator.

• Grund: Das, wenn ich die betriebswirtschaŌliche zu früh mache, ich die bereits betriebswirtschaŌlichen auĩereiteten Daten in meinem zentralen Data Warehouse ablege und das hat das Problem, dass es mir die Historie kaputt macht, weil die BWL ändert sich mal wie z.B. Rechenformel oder welche Konten einbezogen werden. Wenn ich das auf den höheren Ebenen mache, dann ruiniere ich mir meine Historie nicht und kann quasi die Daten, die schon da sind, neu durchrechnen zum Bericht.

• WichƟg ist zu wissen auf welchen Schichten, welche der TransformaƟonen staƪinden, also wo ist die BWL und wo ist die Technik

• Die Datenpunkte sind immer die Stapeldiagramme bzw. Säulengraphik

• Besonders geeignet für den Verlauf der Werte sind Kurven oder Linien. Das ist eine der Aussagen aus dem IBCs.

• Die Extraktoren bereiten die Daten in den Vorsystem so auf, dass das BI System sie entgegennehmen kann, sie holen quasi innerhalb des ERP-Systems Daten, suchen sie zusammen und stellen sie für Berichtssysteme bereit

• Es ist quasi der Andockpunkt, wo das BI-System dran geht und sich die Daten abholt

• Das BI-System geht nicht unbedingt direkt auf die Tabelle, sondern es holt sich von einem Extraktor die Daten und der Extraktor kann dann die Daten aus den Tabellen lesen

• Warum macht man das? Weil es viel flexibler ist. Wenn sich die Tabellenstruktur in ERP jetzt ändert, dann muss ich nur den Extraktor ändern und das alles oben drüber bleibt gleich. Wenn ich das nicht habe und ich habe auf die einzelnen Tabellen zugegriffen, dann purzeln alle möglichen Berichte und das wollen wir nicht. Deshalb ist das wieder eine Schicht im ERP-System, um später die AdministraƟon zu erleichtern