Strategie für historische Daten
Stand 2026-09-03
Den Umgang mit der Historie nach Zugriffsebene entscheiden (heiß 2-3 Jahre volle Granularität · warm 3-7 Jahre aggregiert · kalt nur gesetzlich Pflichtiges archiviert) — vor dem Cutover, nicht durch Migration von allem in voller Granularität. Vier Optionen: Vollmigration (nur heiß), Aggregieren-und-Migrieren (warm, 80/20), Archivierung nach NLS/Objektspeicher (kalt), Read-only-Legacy-Abschaltung mit festem Datum. Aufbewahrung ist ein rechtlicher Input (deutsche Steuer-AO 10 Jahre; DSGVO verbietet Überaufbewahrung) — die Matrix zuerst von der Rechtsabteilung unterzeichnen lassen. „Brauchen wir 12 Jahre tägliche Granularität?" ist die entscheidende Frage — Aggregation auf Monatsebene senkt den warmen Speicherbedarf um das ~10-Fache. Dem Kunden Geld zu sparen ist die nachhaltige Tagessatz-Rechtfertigung.
Was Sie lernen
- BW/4HANA-Historiendaten in heiße / warme / kalte Zugriffsebenen klassifizieren und für jede Ebene die richtige Disposition wählen (Vollmigration · Aggregieren-und-migrieren · Archivierung nach NLS/Objektspeicher · Read-only-Legacy-Abschaltung)
- Eine Aufbewahrungsmatrix erstellen, die die gesetzliche Aufbewahrung (z. B. deutsche Steuerunterlagen 10 Jahre nach §147 AO, Handelsunterlagen nach §257 HGB) mit der DSGVO-Zweckbindung in Einklang bringt und von Rechtsabteilung/Finanzwesen unterzeichnet wird, bevor archiviert oder gelöscht wird
- Unnötige Aufbewahrung in voller Granularität (z. B. 12 Jahre Historie in Tagesgranularität) mit einer Alternative der monatlichen Aggregation infrage stellen und die resultierende Speicherersparnis quantifizieren
- Ein hartes Abschaltdatum für ein Read-only-Legacy-Fallback-System setzen und es in den Decommission-Wellenplan integrieren (Begleitmodul M068)
Modulüberblick
Die Strategie für historische Daten beantwortet die Frage, auf die jede BW-Migration irgendwann stößt: Was tun wir mit 8-15 Jahren Historie, die im System liegt, das wir gerade stilllegen? Die falsche Antwort (alles migrieren, in voller Granularität, in die teure neue Plattform) verdoppelt still und leise die Speicherrechnung und verlangsamt jede Abfrage. Die Senior-Antwort ist eine bewusste, aufbewahrungsbewusste Tiering-Entscheidung, die vor dem Cutover getroffen wird.
Starten Sie beim Zugriffsmuster, nicht beim Datenvolumen. Historie gliedert sich in drei Zugriffsebenen: (1) heiß — die letzten 2-3 Geschäftsjahre, ständig abgefragt, benötigt volle Granularität in der aktiven Plattform; (2) warm — 3-7 Jahre zurückliegend, gelegentlich abgefragt (Audit, Jahresvergleichstrend), tolerierbar bei aggregierter Granularität oder höherer Latenz; (3) kalt — jenseits der gesetzlichen Mindestnutzung, fast nie abgefragt, muss aber rechtlich aufbewahrt werden. Die meisten Organisationen führen alle drei Ebenen zu Heiß-Kosten mit, weil niemand die Tiering-Entscheidung getroffen hat.
Voraussetzungen
- Fortgeschrittene praktische Erfahrung mit SAP-Analytics-Projekten
- Zunächst die Kernkonzepte durchgehen: C035, C033, C032
Lernergebnisse
- Historische Datenobjekte anhand von Query-Häufigkeits-Evidenz in heiße/warme/kalte Zugriffsebenen klassifizieren.
- Eine rechtlich unterzeichnete Aufbewahrungsmatrix erstellen, die die gesetzliche Aufbewahrung mit der DSGVO-Zweckbindung in Einklang bringt.
- Die Auswirkung auf Speicher und Kosten quantifizieren, wenn warme Daten von täglicher auf monatliche Granularität aggregiert werden.
- Ein Read-only-Legacy-Abschaltfenster mit einem harten, an die Decommission-Welle gebundenen Stilllegungsdatum entwerfen.
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.