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

Mit dem Wechsel auf SAP HANA und der Migration in die Cloud ist SAP Data Volume Management vom reinen Basis-Thema zur Kostenfrage geworden. Jedes Gigabyte unnötiger Daten in der aktiven SAP HANA-Datenbank kostet ab Tag eins der Cloud-Migration jeden Monat Geld. Ein praxisorientierter Blick auf fünf Fehler, die wir in DVM-Projekten regelmäßig sehen.

Data Volume Management (DVM) im SAP-Umfeld umfasst die kontinuierliche Reduktion und Steuerung des aktiven Datenbestands in SAP HANA und SAP S/4HANA. Mit der Migration auf hyperscale Cloud-Plattformen (RISE with SAP, AWS, Azure, Google Cloud) wird die Datenmenge zum direkten Kostentreiber: SAP HANA-zertifizierte Cloud-Instanzen werden nach Memory abgerechnet, eine zu große Datenbank verursacht jeden Monat höhere Lizenz-, Backup- und Infrastrukturkosten. Fünf typische Fehler in DVM-Projekten lassen sich vermeiden: Archivieren ohne Root-Cause, DVM als Einmal-Projekt, Retention-Delegation an die SAP-Basis, Tooling vor Standard-Housekeeping und Entkopplung von der Cloud-Roadmap.

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

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

Beide Entwicklungen verändern die Frage. 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, oft zu signifikanten Anteilen am gesamten Cloud-Migrations-Business-Case.

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 Cloud-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. Die Kosten für Cloud-Datentransfer addieren sich.

Hinzu kommt die ESG-Dimension. Modellierungen zeigen, dass eine strukturierte SAP DVM-Bereinigung die jährlichen CO2-Äquivalent-Emissionen einer SAP HANA-Plattform um etwa 40 Prozent reduzieren kann. Daten, die nicht aktiv genutzt werden und trotzdem in der In-Memory-Datenbank gehalten werden, verbrauchen Energie ohne Geschäftsnutzen.

Fehler 1: Archivieren 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 für HR- und Geschäftspartner-Daten bei jedem Lauf einen vollständigen Datenrebuild ausführt anstatt einer inkrementellen Delta-Logik. Millionen von Änderungsbelegen werden bei jeder Ausführung erzeugt, ohne dass ein Geschäftsbezug dahintersteht. Der falsche Job-Modus muss korrigiert werden, bevor die Archivierung sinnvoll ansetzen kann.

Die Lehre ist klar: Vor jedem Archivierungsplan sollte eine explizite Root-Cause-Analyse stehen. Wenn die Ursache an der Quelle behebbar ist, wird sie zuerst korrigiert. Erst dann beginnt die Archivierung. Vermeidung statt Behandlung.

Fehler 2: DVM als einmaliges Projekt behandeln

DVM ist kein Projekt mit einem Endpunkt. Es ist 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 einem dokumentierten Housekeeping-Baseline ab. Geplante Hintergrundjobs für Anwendungslogs, IDoc-Archivierung, Workflow-Bereinigung und Änderungsdokumente, jeweils mit definierten Aufbewahrungsfristen und einer benannten Verantwortung. Die Kosten dafür sind moderat. Die Kosten, das nicht zu tun, sind die gleichen DVM-Maßnahmen in zwei Jahren erneut zu beauftragen, plus die in der Zwischenzeit aufgelaufenen Infrastruktur-Mehrkosten.

Fehler 3: Archivierungs-Tooling vor Standard-Housekeeping

Nicht jedes Volumen-Problem 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 für genau dieses Thema mitgeliefert wird, oder ein einzelner SAP-Hinweis, der einen Software-Bug korrigiert.

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

SAP-Standard liefert für die meisten technischen Tabellen das Housekeeping-Werkzeug bereits mit. Die Disziplin ist, diese Werkzeuge zu nutzen, bevor zu schwererem Tooling gegriffen wird.

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

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

Ohne dokumentierte Vorgabe aus dem Fachbereich entscheidet die SAP-Basis nach eigenem Ermessen. Das bedeutet entweder zu großzügige Aufbewahrungsfristen, die unnötige Kosten produzieren, oder zu kurze Fristen, die ein Compliance-Risiko erzeugen. Beide Varianten sind vermeidbar, wenn die Business-Owner eine dokumentierte Position einnehmen und die SAP-Basis sie konsistent über die SAP-Landschaft hinweg umsetzt.

Fehler 5: DVM von der Cloud- und SAP 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 und produziert monatlich Kosten für Memory und Storage, die fachlich nicht erforderlich wären. Backup-Kosten, Datentransfer-Kosten und CO2-Emissionen skalieren proportional mit.

DVM vor der Migration anzugehen, nicht erst danach, 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. Die Antwort verändert den Migrations-Business-Case unmittelbar.

Wie sieht ein gut geführtes SAP DVM-Programm aus

Vier Eigenschaften zeichnen ein nachhaltiges DVM-Programm aus:

• 1. grundlegene Analyse vor der SAP-Archivierung. Jede Archivierungs-Initiative beginnt mit der Frage, warum die Datenmenge entstanden ist. Wenn die Ursache an der Quelle behebbar ist, wird sie zuerst korrigiert.

• 2. SAP-Standard-Housekeeping vor Sondermaßnahmen. Die SAP-Standardwerkzeuge werden ausgeschöpft, bevor zu komplexerer Tooling gegriffen wird. Das spart Zeit, Geld und Komplexität.

• 3. Business-Owner für Retention-Policies. Aufbewahrungsfristen sind dokumentiert, von Fachbereichs-Verantwortlichen freigegeben und konsistent über die SAP-Landschaft hinweg umgesetzt.

• 4. Geplanter Housekeeping-Baseline am Programm-Ende. Hintergrundjobs sind eingerichtet, ein benannter Verantwortlicher überwacht den Lauf, eine messbare Zielgröße ist definiert.

Das Ergebnis eines DVM-Programms ist nicht eine einmalige Reduktion der Datenbankgröße. Es ist eine operative Disziplin, die das Wiederwachsen verhindert.

Sechs Fragen für SAP-Veranwtortliche

Wer als CIO oder Head of SAP testen möchte, ob DVM im eigenen Unternehmen als Disziplin oder als gelegentliche Aufräum-Aktion betrieben wird, kann diese sechs Fragen ans Team stellen:

• 1. Wann wurde zuletzt eine Root-Cause-Analyse für eine wachsende Tabelle durchgeführt? Welches Ergebnis hatte sie?

• 2. Welche Hintergrundjobs für Standard-Housekeeping laufen aktuell, und wer überwacht sie? Wann hat zuletzt eine erfolgreiche Ausführung stattgefunden?

• 3. Wo sind die Aufbewahrungsfristen für Anwendungslogs, IDocs, Workflow-Items und Änderungsdokumente dokumentiert? Wer hat sie freigegeben?

• 4. Wie ist DVM in der Migrations-Roadmap zur SAP S/4HANA oder RISE with SAP verankert? Vor, während oder nach der Migration?

• 5. Welchen CO2-Effekt hat unsere SAP-Plattform aktuell, und welcher Anteil davon stammt aus inaktiven Daten? Gibt es eine Messung?

• 6. Welche Cloud-Kosten haben wir durch eine zu groß migrierte Datenbank vermeidbar verursacht? Was würde eine Tier-Reduktion bringen?

SAP Archive Managed Service: DVM und SAP-Archivierung als Disziplin

Bei entplexit verstehen wir DVM als integralen Bestandteil eines geregelten SAP-Archivbetriebs. Mit dem SAP Archive Managed Service unterstützen wir Kunden operativ in beiden Disziplinen: Bestandsaufnahme der Datenbestände, Root-Cause-Analyse für stark wachsende Tabellen, Customizing der Archivierungsobjekte, Aufbau eines Housekeeping-Baseline mit überwachten Hintergrundjobs, laufende SAP-Archivierung und SAP ILM-konforme Sperr- und Löschprozesse.

Konkret bedeutet das: Single Point of Contact für alle Archiv- und DVM-Themen, definierte SLAs, monatliches Monitoring-Reporting, eine laufend gepflegte Verfahrensdokumentation, planbare monatliche Kosten. Der Service ist ergänzend zu RISE with SAP, AWS, Azure oder Google Cloud aufgestellt und entlastet das interne SAP-Team operativ.

Unsere Empfehlung

Wer SAP S/4HANA oder RISE with SAP plant oder bereits eingeführt hat, sollte DVM als eigenständigen Workstream 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. Aus den Antworten ergibt sich der Handlungsbedarf, und es zeigt sich schnell, ob das eigene SAP-Team das Thema operativ stemmen kann oder ob ein erfahrener Partner sinnvoll ist.

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. Die hier dargestellten Fehlermuster und Empfehlungen entsprechen unseren Erfahrungen aus SAP-Archivierungsprojekten der letzten Jahre.

Häufig gestellte Fragen

Was ist SAP Data Volume Management (SAP DVM)?

DVM umfasst die kontinuierliche Reduktion und Steuerung des aktiven Datenbestands in SAP HANA und SAP S/4HANA. Ziel ist es, die produktive Datenbank schlank, performant und wirtschaftlich zu halten. Bestandteile: Root-Cause-Analyse stark wachsender Tabellen, Standard-Housekeeping über Hintergrundjobs, geregelte Archivierung über SAP ILM, dokumentierte Aufbewahrungsfristen und laufendes Monitoring.

Warum ist SAP DVM bei einer Cloud-Migration besonders wichtig?

SAP HANA-zertifizierte Cloud-Instanzen werden nach allokierter Memory-Kapazität abgerechnet. Eine zu große Datenbank erzwingt eine höhere VM-Klasse, die für die gesamte Cloud-Vertragslaufzeit Kosten verursacht. Backup-, Storage- und Datentransfer-Kosten skalieren proportional mit. DVM vor der Migration anzugehen reduziert diese laufenden Kosten substanziell.

Was ist der häufigste SAP DVM-Fehler in SAP-Projekten?

Mit der Archivierung zu beginnen, bevor die Ursache des Tabellenwachstums verstanden ist. Wenn ein Hintergrundjob unnötige Datenmengen erzeugt, hilft Archivierung nur kurzfristig, das Volumen baut sich innerhalb weniger Monate wieder auf. Erst Root-Cause beheben, dann archivieren.

Wer entscheidet über Aufbewahrungsfristen in SAP-Landschaften?

Aufbewahrungsfristen sind eine Business-Frage. Sie gehören zu Finance, Audit, Compliance und den fachlichen Process-Ownern, nicht zur SAP-Basis. Ohne dokumentierte Vorgabe aus dem Fachbereich entscheidet die Basis nach Ermessen, was zu kostspieligen oder compliance-kritischen Defaults führt.

Wie kann der SAP Archive Managed Service bei SAP DVM unterstützen?

Der Service bündelt Bestandsaufnahme, Analyse, Customizing der Archivierungsobjekte, Aufbau eines Housekeeping-Baseline, laufende SAP Archivierung und SAP ILM-konforme Sperr- und Löschprozesse in einem Servicevertrag. Definierte SLAs, monatliches Monitoring-Reporting, gepflegte Verfahrensdokumentation, planbare monatliche Kosten.

Über entplexit

Die entplexit GmbH ist SAP Partner mit Schwerpunkt auf SAP-Archivierung, SAP Information Lifecycle Management (ILM) und SAP Archive Managed Services. Mit dem SAP Archive Managed Service übernehmen wir den vollständigen Archivbetrieb für mittelständische und große SAP-Anwender, On-Premise, in der Hyperscaler-Cloud und ergänzend zu RISE with SAP.

Kontakt: information@entplexit.com | +49 (0) 6196 97344 - 00 | www.entplexit.com

Quellen und Inspiration

Gary Jackson, "DVM Mistakes That Quietly Erode SAP Value", LinkedIn Pulse, 30. April 2026. Verfügbar unter:

https://www.linkedin.com/pulse/dvm-mistakes-quietly-erode-sap-value-gary-jackson-lvhme/

Wenn diese Themen für Sie aktuell sind: Sprechen Sie uns an, wir unterstützen Sie gerne.