5 SAP DVM-Fehler, die den Mehrwert von Cloud leise auffressen

Warum DVM nicht mehr nur ein SAP-Basis-Thema ist

In klassischen SAP-Landschaften war Data Volume Management ein Basis-Thema. Es tauchte gelegentlich in Archivierungsdiskussionen auf und erreichte selten den Blick der Geschäftsleitung. Mit zwei Entwicklungen hat sich das grundlegend geändert: der Wechsel auf In-Memory-Plattformen mit SAP HANA und die Migration der SAP-Landschaften in die Hyperscaler-Cloud.

Die Größe der aktiven SAP HANA-Datenbank ist nicht mehr nur eine Performance-Kennzahl, sondern direkter Kostentreiber. SAP HANA-zertifizierte Virtual Machines auf AWS, Microsoft Azure und Google Cloud werden nach allokierter Memory-Kapazität abgerechnet. Backup-Kosten, Datentransferkosten und Disaster-Recovery-Infrastruktur skalieren proportional zur Datenmenge. Hinzu kommt die ESG-Dimension: Die Energieaufnahme einer SAP HANA-Plattform hängt direkt von ihrer aktiven Größe ab.

Wer in dieser Konstellation eine zu große Datenbank in die Cloud migriert, zahlt von Tag eins an mehr als nötig. Der Effekt summiert sich über die typische Cloud-Vertragslaufzeit zu erheblichen Beträgen.

Was Untätigkeit konkret kostet

Drei Kostenebenen werden direkt durch die Datenbankgröße getrieben:

• Cloud-VM-Tier. SAP HANA-zertifizierte Cloud-Instanzen sind in Memory-Klassen gegliedert. Eine 2-Terabyte-Datenbank erfordert eine andere Instanzgröße als eine 1-Terabyte-Datenbank, mit deutlich anderen monatlichen Kosten. Der Unterschied bleibt über die gesamte Vertragslaufzeit erhalten.
• Backup und Storage. Backup-Volumen, Snapshot-Storage und Disaster-Recovery-Infrastruktur skalieren proportional. Eine zu große Datenbank produziert auch zu große Backups.
• Datentransfer. Bei jedem System-Refresh, jedem Test-Restore und jeder Migration zwischen Stages werden volle Datenbankvolumina übertragen.

Hinzu kommt die ESG-Dimension. Modellierungen zeigen, dass eine strukturierte DVM-Bereinigung die jährlichen CO2-Äquivalent-Emissionen einer SAP HANA-Plattform um etwa 40 Prozent reduzieren kann.

Fehler 1: Archivieren ohne vorherige Analyse

Der häufigste und teuerste DVM-Fehler ist es, mit der Archivierung zu beginnen, bevor verstanden wurde, warum eine bestimmte Tabelle so groß geworden ist. Archivierung behandelt das Symptom, nicht die Ursache. Das Volumen kommt zurück, oft schneller als erwartet.

Ein typisches Beispiel: Die Änderungsbeleg-Tabelle CDPOS wächst auf mehrere Milliarden Einträge. Eine genauere Analyse zeigt, dass ein Hintergrund-Synchronisationsprozess bei jedem Lauf einen vollständigen Datenrebuild ausführt statt einer inkrementellen Delta-Logik. Millionen von Änderungsbelegen entstehen bei jeder Ausführung, ohne dass ein Geschäftsbezug dahintersteht. Der falsche Job-Modus muss korrigiert werden, bevor die Archivierung sinnvoll ansetzen kann.

Vor jedem Archivierungsplan sollte deshalb eine explizite Ursachenanalyse stehen. Vermeidung statt Behandlung.

Fehler 2: DVM als einmaliges Projekt behandeln

DVM ist kein Projekt mit einem Endpunkt, sondern eine operative Disziplin. Eine bereinigte SAP HANA-Datenbank ist in unter einem Jahr wieder voll, wenn die zugrundeliegenden Hintergrundjobs nicht laufen und nicht überwacht werden.

Eine nachhaltige DVM-Implementierung schließt mit einer dokumentierten Housekeeping-Baseline ab: geplante Hintergrundjobs für Anwendungslogs, IDoc-Archivierung, Workflow-Bereinigung und Änderungsbelege, jeweils mit definierten Aufbewahrungsfristen und einer benannten Verantwortung. Die Kosten dafür sind moderat. Die Kosten, das nicht zu tun, sind dieselben Maßnahmen in zwei Jahren erneut, plus die zwischenzeitlich aufgelaufenen Infrastruktur-Mehrkosten.

Fehler 3: Archivierungs-Tooling vor Standard-Housekeeping

Nicht jedes Volumenproblem braucht eine vollständige Archivierungs-Initiative. Manche Probleme lassen sich mit Bordmitteln lösen: ein abgeschaltetes Tabellen-Logging, das nie gebraucht wurde, ein geplanter SAP-Standard-Report, der genau dafür mitgeliefert wird, oder ein einzelner SAP-Hinweis, der einen Fehler korrigiert.

Ein Beispiel aus der Praxis: Eine einzelne HR-Tabelle erzeugt überproportional viele Audit-Log-Einträge, ohne dass ein Compliance-Anspruch dahintersteht. Die Lösung ist das Abschalten des Loggings auf dieser Tabelle. Kein Archivobjekt, kein Projektplan, sondern ein einzelner Customizing-Eintrag.

Fehler 4: Retention-Entscheidungen an die SAP-Basis delegieren

Aufbewahrungsfristen sind eine Business-Frage, keine technische Entscheidung. Wie lange soll ein Änderungsbeleg gespeichert werden? Wie lange muss ein IDoc online verfügbar bleiben? Diese Fragen gehören zu Finance, Audit, Compliance und den Fachbereichs-Verantwortlichen, nicht zur Plattform-Technik.

Ohne dokumentierte Vorgabe entscheidet die SAP-Basis nach eigenem Ermessen. Das bedeutet entweder zu großzügige Fristen, die unnötige Kosten produzieren, oder zu kurze Fristen, die ein Compliance-Risiko erzeugen.

Fehler 5: DVM von der Cloud- und S/4HANA-Roadmap entkoppeln

Viele Unternehmen ordnen ihre Transformation als “erst migrieren, dann optimieren” an. Die Wirtschaftlichkeit spricht in den meisten Fällen dagegen.

Die Migration einer überdimensionierten SAP HANA-Datenbank erzwingt von Tag eins eine höhere Cloud-VM-Klasse. Diese bleibt für die gesamte Vertragslaufzeit aktiv. Backup-Kosten, Datentransfer-Kosten und CO2-Emissionen skalieren proportional mit.

DVM vor der Migration anzugehen ist in fast allen Fällen der wirtschaftlichere Weg. Wer eine Migration auf SAP S/4HANA, RISE with SAP, AWS, Azure oder Google Cloud plant, sollte explizit prüfen, ob DVM abgeschlossen, gestartet oder verschoben ist.

Wie ein gut geführtes SAP DVM-Programm aussieht

1. Ursachenanalyse vor der Archivierung. Jede Initiative beginnt mit der Frage, warum die Datenmenge entstanden ist.
2. SAP-Standard-Housekeeping vor Sondermaßnahmen. Die Standardwerkzeuge werden ausgeschöpft, bevor zu komplexerem Tooling gegriffen wird.
3. Business-Owner für Retention-Policies. Aufbewahrungsfristen sind dokumentiert, freigegeben und konsistent umgesetzt.
4. Geplante Housekeeping-Baseline am Programmende. Hintergrundjobs sind eingerichtet, ein benannter Verantwortlicher überwacht den Lauf, eine messbare Zielgröße ist definiert.

Sechs Fragen für SAP-Verantwortliche

1. Wann wurde zuletzt eine Ursachenanalyse für eine wachsende Tabelle durchgeführt, und mit welchem Ergebnis?
2. Welche Hintergrundjobs für Standard-Housekeeping laufen aktuell, und wer überwacht sie?
3. Wo sind die Aufbewahrungsfristen für Anwendungslogs, IDocs, Workflow-Items und Änderungsbelege dokumentiert, und wer hat sie freigegeben?
4. Wie ist DVM in der Migrations-Roadmap zu SAP S/4HANA oder RISE with SAP verankert, davor, dabei oder danach?
5. Welchen CO2-Effekt hat unsere SAP-Plattform aktuell, und welcher Anteil stammt aus inaktiven Daten?
6. Welche Cloud-Kosten haben wir durch eine zu groß migrierte Datenbank vermeidbar verursacht?

Unsere Empfehlung

Wer SAP S/4HANA oder RISE with SAP plant oder bereits eingeführt hat, sollte DVM als eigenständigen Arbeitsstrang behandeln, nicht als Anhängsel. Die Frage ist nicht, ob die Daten irgendwann reduziert werden, sondern wann und unter welchen Konditionen das den wirtschaftlichen Effekt erzielt, der heute möglich wäre.

Der pragmatische erste Schritt ist eine ehrliche Bestandsaufnahme: Welche Tabellen sind die Treiber, welche Hintergrundjobs laufen, wo sind Aufbewahrungsfristen dokumentiert, wer überwacht den Lauf.

Inspiriert wurde dieser Beitrag durch einen lesenswerten LinkedIn-Artikel von Gary Jackson, “DVM Mistakes That Quietly Erode SAP Value”, den wir aus eigener Praxis bestätigen können.

← Zurück