SAP-Wiki

Der Weg der Daten folgt dem ETL-Prinzip: extrahieren, transformieren, laden. Ladeprozesse holen Daten periodisch oder in Echtzeit aus ERP, CRM oder Produktionssystemen. Transformationen vereinheitlichen Formate, Währungen und Schlüssel, ein Kunde bekommt über alle Systeme hinweg dieselbe Nummer. Anschließend liegen die Daten historisiert in Schichten: ein Eingangsbereich für Rohdaten, ein harmonisierter Kern, darauf fachbezogene Data Marts für Vertrieb, Einkauf oder Finanzen. Berichte und Dashboards greifen auf diese obersten Schichten zu.

Vom Data Lake unterscheidet sich das Warehouse durch Struktur: Daten werden schon beim Beladen modelliert und geprüft, Auswertungen liefern deshalb verlässliche, wiederholbare Ergebnisse. Der Lake speichert Rohdaten günstig und flexibel, verlangt die Strukturierung aber erst bei der Analyse. Moderne Plattformen kombinieren beides, SAP etwa mit Datasphere und der Business Data Cloud. Ein eigenes Warehouse braucht, wer Kennzahlen über Systemgrenzen konsistent halten will oder Berichtslasten von den operativen Systemen fernhalten muss.

Die Projekterfahrung: Technik ist selten der Engpass, Datenqualität fast immer. Fehlende Pflege in den Quellsystemen wird im Warehouse sichtbar, beheben lässt sie sich nur an der Quelle. Ebenso wichtig ist die Historisierung, also die Frage, welche Änderungen wie lange nachvollziehbar bleiben. Nachträglich lässt sich Historie kaum rekonstruieren. Und ohne klare Verantwortliche je Datendomäne verwildert jedes Warehouse. Ein tragfähiges Betriebsmodell gehört deshalb von Anfang an ins Projekt, gleichrangig mit der Architektur.