Testdaten wie aus der Produktion.
Ohne den Ballast einer Komplettkopie.
Der Data Refresh Operator (DRO) erstellt zeitscheiben‑basierte Mandantenkopien: Sie wählen den Zeitraum – DRO liefert einen konsistenten, lauffähigen Datenbestand inklusive aller abhängigen Belege. Schnell, sicher, wiederholbar – und dauerhaft günstiger im Betrieb.
Für Landschaften mit mehreren S/4HANA-Systemen – remote, unverbindlich und mit konkretem Blick auf Ihre Anwendungsfälle.
Die Standard-Mandantenkopie ist eines der teuersten Werkzeuge Ihrer SAP‑Landschaft
Wer regelmäßig produktionsnahe Testdaten braucht, kennt den Preis: Klassische Komplettkopien sind langsam, teuer, risikoreich, schwer steuerbar – und fachlich zu grob. Bei jeder einzelnen Kopie.
Langsam
Komplettkopien binden Systeme, Basis-Team und Fachbereiche oft tagelang. Aus dem Refresh wird ein Projekt – statt Routine.
Teuer im Betrieb
Jede Kopie dupliziert die gesamte Historie. QS-, Test- und Sandbox-Systeme brauchen dadurch fast Produktions-Sizing: HANA‑Speicher, Storage, Backup – ein Dauerkostenblock.
Risikoreich
Lange Laufzeiten, manuelle Schritte, unklare Zwischenzustände: Bricht eine Kopie ab, beginnt das Bangen – und häufig alles von vorn.
Schwer steuerbar
Alles oder nichts: Der Umfang lässt sich fachlich kaum eingrenzen. Was Sie eigentlich brauchen, entscheidet nicht das Werkzeug – sondern der Zufall der Vollkopie.
Fachlich zu grob
Sie brauchen die letzten Monate – kopiert werden Jahrzehnte. Testdaten verstecken sich in einem Datenfriedhof, der niemanden interessiert.
Datenschutz unter Druck
Unmaskierte Produktivdaten landen in Systemen mit breiten Berechtigungen. Jede Vollkopie vervielfacht die Angriffsfläche für personenbezogene Daten.
In S/4HANA ist Hauptspeicher der größte Kostenhebel – Vollkopien bezahlen ihn mehrfach
Zu ECC-Zeiten lag Historie auf vergleichsweise günstigen Festplatten. Mit S/4HANA arbeitet Ihre Datenbank In-Memory: Die Daten liegen im Hauptspeicher – und der bestimmt Sizing, Hardware- bzw. Cloud-Instanzgrößen und häufig auch das Lizenzmodell. Speicher ist damit vom Nebenposten zum Kostentreiber Nr. 1 im Betrieb geworden.
Jede Standard-Vollkopie trägt diese komplette Historie zusätzlich in QS-, Test- und Entwicklungssysteme. Denselben teuren Speicher bezahlen Sie damit doppelt, dreifach, vierfach – Monat für Monat. Der wirksamste Hebel im Run: jedes System außerhalb der Produktion nur so groß halten, wie sein Zweck es verlangt. Genau dafür ist DRO gebaut.
Richtwerte aus unseren Referenz-Szenarien – Ihre konkreten Ergebnisse hängen von Systemgrößen, Historie und Refresh-Zyklen ab. Im kostenlosen Vorstellungstermin zeigen wir Ihnen, wo diese Hebel in Ihren Anwendungsfällen greifen.
Zeitscheiben-basierte Mandantenkopien: nur so groß wie nötig, immer konsistent
Sie geben den Zeitraum vor – etwa die letzten 90 Tage. DRO ermittelt über das Objektmodell die Geschäftsobjekte in dieser Zeitscheibe und beginnt sofort mit dem Export. Parallel läuft die Abhängigkeitsauflösung über den Objektgraphen weiter – bis zum Fixpunkt: dem nachweisbaren Punkt, an dem nichts mehr fehlt.
Denn Belegflüsse enden nicht an Datumsgrenzen: Der Auftrag aus dem März, die Lieferung aus dem Januar, die Rechnung von letzter Woche. DRO nimmt abhängige Belege auch außerhalb der Zeitscheibe mit – und exportiert sie unmittelbar nach dem Auffinden, fast zeitgleich mit ihrem Ursprungsbeleg. So bleibt dem laufenden System keine Zeit, zusammengehörige Daten auseinanderdriften zu lassen – genau das unterscheidet einen lauffähigen Mandanten von einer Datenruine.
Konsistenz – nicht versprochen, sondern nachgemessen
Behaupten kann man viel. Ob wirklich jeder abhängige Beleg den Weg in die Kopie findet, lässt sich von Hand praktisch nicht prüfen – dafür sind es schlicht zu viele. Deshalb haben wir in der Entwicklung von DRO KI-gestützte Prüfwerkzeuge eingesetzt: Eine KI analysiert das Ergebnis einer Zeitscheiben-Kopie und verifiziert, dass alle technisch relevanten Belege samt ihrer Folgebelege vollständig mitkopiert wurden – Belegkette für Belegkette, in einem Umfang, den kein Mensch manuell auswerten könnte. So messen wir bei jeder Weiterentwicklung nach, dass DRO hält, was wir hier versprechen.
So läuft ein Refresh mit DRO – in fünf Schritten
Vom gewählten Zeitraum bis zum validierten Import: Jeder Schritt ist automatisiert, nachvollziehbar und wiederaufsetzbar.
Zeitscheibe & Profil wählen
Sie definieren Zeitraum (z. B. die letzten 90 Tage) und Run-Profil: Bewegungsdaten, Stammdaten, Customizing – zentral gepflegt im Control-System, mit Ausnahmelisten und feinen Stellschrauben bis auf Tabellenebene.
Abhängigkeiten automatisch auflösen
DRO ermittelt die Geschäftsobjekte in der Zeitscheibe und verfolgt deren Abhängigkeiten iterativ über den Objektgraphen – bis zum Fixpunkt: Erst wenn keine neuen Objekte mehr dazukommen, ist der Umfang nachweislich vollständig. Gefundene Objekte warten darauf nicht – sie gehen sofort in den Export.
Sofort & parallel exportieren
Belege werden unmittelbar nach dem Auffinden von parallelen Workern exportiert – Folgebelege fast zeitgleich mit ihrem Ursprungsbeleg, damit sich zusammengehörige Daten im laufenden System nicht auseinanderentwickeln. Wiederaufsetzbar, mit SHA‑256-Prüfsummen je Datenblock und konfigurierbarer Kompression; das Manifest dokumentiert verbindlich, was im Paket steckt.
Maskieren – optional, aber integriert
Sensible Daten werden nach zentral verwalteten Regeln maskiert, wahlweise beim Export oder Import. Die Regeln selbst verlassen das Control-System nie dauerhaft – auch Maskierungslogik ist schützenswert.
Kontrolliert importieren
Konsistenzprüfung des Pakets, sichere Tabellen-Vorbereitung, paralleler Import mit überlappender Pipeline, anschließende Validierung. Im Control-System bleibt nachvollziehbar, wann welcher Lauf mit welchen Regeln eingespielt wurde.
Nicht nur die Kopie – der komplette Ablauf, automatisiert von A bis Z
Ein Mandanten-Refresh ist mehr als Export und Import: Ankündigungen, Downtime-Fenster, Ramp-Down, Benutzersperren, Nummernkreise, Nacharbeiten, Ramp-Up. DRO bildet diesen gesamten Prozess als Playbook ab – automatisiert, sauber überwacht und mit Benachrichtigungen zu jedem Schritt. Sie greifen nur ein, wenn wirklich etwas ansteht.
Gebaut für den Betrieb großer S/4HANA-Landschaften
Betriebskosten runter
In HANA ist Hauptspeicher der teuerste Posten – und Non-Prod multipliziert ihn. Mit Zeitscheiben-Kopien sind QS-, Test- und Sandbox-Systeme nur so groß wie ihr Zweck: weniger RAM, weniger Storage, kleinere Backups. Dauerhaft weniger Run-Kosten.
Schnell & wiederholbar
Parallele Worker, überlappende Verarbeitung, Pause & Wiederanlauf: Refreshes im Takt Ihrer Releases.
Konsistenz garantiert
Folgebelege werden fast zeitgleich mit ihrem Ursprungsbeleg exportiert – und die Abhängigkeitsauflösung läuft, bis nachweislich nichts mehr fehlt.
Sicherheit by Design
Systemrollen verhindern Importe in Produktivsysteme, finalisierte Pakete sind unveränderlich, jeder Block prüfsummengesichert.
Maskierung inklusive
Produktionsnahe Tests ohne Klartext-Personendaten: Regeln zentral definiert, angewendet beim Export oder Import.
Keine Blackbox
DRO erklärt, warum jede Tabelle und jeder Beleg im Paket ist. Simulation vor der Ausführung, lückenlos protokollierte Läufe im Control-System danach – Erklärbarkeit ist Architekturprinzip, kein Nachgedanke.
SAP-Standard-Mandantenkopie vs. DRO
| Standard-Mandantenkopie | DRO – Data Refresh Operator | |
|---|---|---|
| Datenumfang | Immer alles – die komplette Historie, bei jedem Lauf | Frei wählbare Zeitscheibe plus automatisch ergänzte Abhängigkeiten |
| Sizing der Zielsysteme | Nahezu Produktionsgröße nötig – dauerhaft | Deutlich kleiner dimensionierbar – Speicher folgt dem Testbedarf |
| Fachliche Konsistenz | Nur als Vollkopie gegeben – Teilmengen sind kaum machbar | Auch für Teilmengen garantiert – per Fixpunkt-Verfahren über den Objektgraphen |
| Steuerbarkeit | Alles oder nichts, wenig fachliche Stellschrauben | Zeitraum, Run-Profile, Ausnahmelisten, Blockgrößen – fein justierbar pro Lauf |
| Maskierung | Nicht integriert – separates Werkzeug und eigener Prozess nötig | Integriert und zentral verwaltet – beim Export oder Import |
| Wiederanlauf | Abbrüche bei großen Kopien sind teuer – oft heißt es: von vorn | Wiederaufsetzbar auf Ebene atomarer Arbeitspakete – inklusive Pause & Resume |
| Nachvollziehbarkeit | Technische Logs – das Warum bleibt offen | Simulation vorab, Manifest als verbindliches Inhaltsverzeichnis, jeder Lauf im Control-System nachvollziehbar |
Fünf Vorteile, die DRO im Marktvergleich auszeichnen
Viele Werkzeuge am Markt tragen ihre ECC-Vergangenheit mit in die S/4HANA-Welt. DRO ist frei davon – und spielt die Möglichkeiten der HANA-Datenbank voll aus. Der direkte Vergleich:
| Andere Tools am Markt | DRO – Data Refresh Operator | |
|---|---|---|
| Architektur | In der ECC-Ära entstanden und später auf S/4HANA übertragen – die Architektur trägt die Altlasten mit | Ohne Altlasten von Grund auf für S/4HANA entwickelt – zugeschnitten auf die einzigartigen Möglichkeiten der HANA-Datenbank |
| Export-Konsistenz | Erst wird alles selektiert, dann Tabelle für Tabelle exportiert – im laufenden System verändern sich abhängige Belege zwischen Selektion und Export | Belege werden nahezu sofort nach dem Auffinden exportiert – Folgebelege praktisch zeitgleich mit ihrem Ursprungsbeleg statt zu zufälligen Zeitpunkten |
| Nachweis der Konsistenz | Stichproben von Hand – vollständige Belegketten sind manuell kaum prüfbar | In der Entwicklung KI-gestützt nachgemessen: Die Vollständigkeit ganzer Belegketten wird maschinell verifiziert |
| Bedienung | Anwender arbeiten häufig direkt auf mehreren Systemen der Landschaft | Alles läuft zentral aus einem Control-System – Anwender brauchen keinen Zugriff auf die gesamte Landschaft |
| Objektmodell | Fester Standardumfang – kundeneigene Objekte bleiben oft außen vor | Offenes Business-Objekt-Modell: erweiterbar und für eigene Objekte nutzbar – Kundenobjekte wandern auf Wunsch mit in die Zeitscheibe und werden entsprechend geschnitten |
Gemacht für große S/4HANA-Landschaften
Bewusst S/4HANA – ohne Kompromisse
DRO ist konsequent für moderne S/4HANA-Landschaften gebaut: ABAP-nativ, HANA-optimiert, ausgerichtet auf S/4-Datenmodelle und eine Fiori-Roadmap. ECC-Kompatibilität ist bewusst kein Ziel – dafür gibt es keine Altlasten-Kompromisse bei Performance und Architektur.
Die Architektur ist auf sehr große Datenmengen ausgelegt: Massendaten werden dezentral in Ihren Systemen verarbeitet, gesteuert von einem zentralen Control‑System.
Was bringt DRO in Ihrer Landschaft?
Im kostenlosen Vorstellungstermin lernen Sie DRO im Detail kennen: Sie sehen live, wie Zeitscheiben-Kopien funktionieren – und wir besprechen an Ihren konkreten Anwendungsfällen, wo die Vorteile bei Speicher, Refresh-Dauer und Betriebskosten liegen.
Häufige Fragen
Wie kann eine Teilkopie konsistent sein?
DRO kopiert nicht stur nach Datum, sondern denkt in Geschäftsobjekten. Die Abhängigkeiten aller Objekte der Zeitscheibe werden iterativ über den Objektgraphen aufgelöst – auch über die Zeitscheibe hinaus, bis zum Fixpunkt: dem nachweisbaren Punkt, an dem keine neuen Objekte mehr hinzukommen. Exportiert wird dabei nicht erst am Ende: Gefundene Belege und ihre Folgebelege werden nahezu sofort und fast zeitgleich exportiert, damit sich zusammengehörige Daten im laufenden System nicht auseinanderentwickeln. So sind Belegflüsse wie Auftrag → Lieferung → Rechnung → FI-Beleg im Zielsystem vollständig und in sich stimmig.
Warum ist der Speicher-Hebel heute so viel größer als früher?
Weil S/4HANA In-Memory arbeitet: Die Daten liegen im Hauptspeicher, und der bestimmt Sizing, Hardware- bzw. Cloud-Instanzgrößen und häufig auch das Lizenzmodell. Früher kostete Historie vor allem günstigen Plattenplatz – heute belegt sie den teuersten Baustein der Infrastruktur, in jedem Non-Prod-System erneut. Deshalb zahlt jede vermiedene Vollkopie direkt auf Ihre laufenden Kosten ein.
Was passiert mit personenbezogenen Daten?
Maskierung ist in DRO integriert: Regeln werden zentral im Control-System gepflegt und wahlweise beim Export oder Import angewendet. Die Regeln verbleiben dauerhaft nur im Control-System. So kommen produktionsnahe Testdaten in Non-Prod an – ohne Klartext-Personendaten.
Brauchen wir zusätzliche Infrastruktur?
DRO ist S/4HANA-nativ in ABAP implementiert und läuft in Ihrer bestehenden Landschaft. Ein zentrales Control-System steuert alle Läufe; die Massendaten fließen direkt zwischen Quell- und Zielsystemen – das Control-System wird bewusst kein Daten-Nadelöhr.
Was passiert, wenn ein Lauf abbricht?
Export und Import sind in kleine, atomare Arbeitspakete zerlegt, deren Status persistent verwaltet wird. Läufe lassen sich pausieren und wiederaufsetzen; verwaiste Arbeitspakete werden erkannt und neu vergeben. Prüfsummen (SHA-256) und das Manifest stellen sicher, dass nur Vollständiges und Unverändertes verarbeitet wird.
Unterstützt DRO auch SAP ECC?
Nein – bewusst nicht. DRO setzt konsequent auf moderne S/4HANA-Landschaften: HANA-Performance, moderne ABAP-Patterns und S/4-Datenmodelle ohne Altlasten-Kompromisse. Wenn Sie auf S/4HANA sind oder migrieren, ist DRO für Sie gebaut.
Wie läuft der kostenlose Vorstellungstermin ab?
Remote und unverbindlich: Wir stellen DRO und das Zeitscheiben-Prinzip vor, beantworten Ihre Fragen und zeigen an Ihren konkreten Anwendungsfällen, welche Vorteile sich für Ihre Landschaft ergeben. Danach entscheiden Sie in Ruhe, ob ein tieferer Termin mit Ihrem Team sinnvoll ist.