Häufig gestellte Fragen
Was ist der Unterschied zwischen einer Sandbox und einem Test- oder Entwicklungssystem?
In einer typischen ERP-Systemlandschaft mit den Stufen Entwicklung (DEV), Qualitätssicherung/Test (QAS) und Produktion (PRD) ist die Sandbox die experimentierfreudigste, freigabefreie Stufe für freies Ausprobieren, Prototyping und Schulungen. Ein Entwicklungssystem fokussiert dagegen auf strukturierte Programmierung und Customizing, dessen Ergebnisse über einen kontrollierten Transportweg in die nächste Stufe wandern. Das Test- bzw. QAS-System dient der Integrations- und Abnahmeprüfung (User Acceptance Testing) möglichst nah am Produktivstand, bevor Änderungen freigegeben werden. Die Begriffe überschneiden sich in der Praxis je nach Hersteller, technisch eint sie aber die Isolation vom Echtbetrieb.
Müssen personenbezogene Daten in einer ERP-Sandbox anonymisiert werden?
Sobald eine Sandbox eine Kopie echter Produktivdaten mit Personenbezug enthält – etwa Namen, Adressen, IBAN oder Gehaltsdaten von Beschäftigten, Kund:innen oder Lieferanten – gilt dies nach DSGVO als Verarbeitung personenbezogener Daten und unterliegt den Grundsätzen der Datenminimierung und Zweckbindung. Deshalb werden Produktivdaten vor der Übernahme in Testumgebungen üblicherweise maskiert, pseudonymisiert oder anonymisiert, wobei die referenzielle Integrität (gleiche Maskierung über alle Tabellen hinweg) erhalten bleiben sollte. Für diese Aufgabe existieren spezialisierte Werkzeuge wie SAP TDMS, Oracle Data Masking and Subsetting, Libelle DataMasking oder EPI-USE Labs Data Secure. Alternativ lassen sich synthetische Testdaten erzeugen, die den Datenschutzaufwand weitgehend vermeiden.
Wie oft sollte eine Sandbox aus dem Produktivsystem aktualisiert werden?
Ein fester Refresh-Zyklus stellt sicher, dass die Sandbox dem aktuellen Stand des Produktivsystems entspricht und Testergebnisse aussagekräftig bleiben. Verbreitete Empfehlungen sehen ein monatliches Neu-Aufsetzen von Entwicklungs- und Sandbox-Umgebungen vor, während Test-/QAS-Systeme oft monatlich oder je Release-Zyklus aktualisiert werden – in intensiven Release-Phasen auch wöchentlich. Reine Sandbox-Umgebungen für freies Experimentieren werden in der Praxis häufig auch bedarfsweise (on demand) zurückgesetzt. Der konkrete Rhythmus hängt von Datenvolumen, Änderungsfrequenz und dem jeweiligen Datenschutz- und Maskierungsaufwand ab.
Kosten Sandbox-Umgebungen extra oder sind sie in der ERP-Lizenz enthalten?
Das hängt stark vom Anbieter und Lizenzmodell ab. Bei Microsoft Dynamics 365 Finance and Operations ist beispielsweise neben dem Produktivsystem genau ein Tier-2-Standard-Acceptance-Testing-Mandant enthalten; weitere Sandbox- bzw. Staging-Instanzen (Tier 2 bis Tier 5) lassen sich als kostenpflichtige Add-ons hinzubuchen. Bei SAP S/4HANA Cloud Public Edition ist die dreistufige Systemlandschaft aus Entwicklung, Test und Produktion Standard, ein zusätzliches optionales Sandbox-System ist jedoch gegen Aufpreis erhältlich. Konkrete Konditionen sollten direkt mit dem Anbieter oder Account-Management geklärt werden, da Bezeichnung, Umfang und Preis je nach Vertrag variieren.
Wozu wird eine Sandbox bei ERP-Updates und Migrationen genutzt?
Vor einem Releasewechsel oder einer ERP-Migration dient die Sandbox als Probebühne, auf der Update-Effekte, Datenkonsistenz und das Zusammenspiel von Erweiterungen und Schnittstellen vorab geprüft werden, ohne den Echtbetrieb zu gefährden. In der SAP-Praxis ist es übliche Vorgehensweise, einen geplanten System-Upgrade zunächst in einer Sandbox durchzuspielen, bevor er auf die produktive Landschaft ausgerollt wird. So lassen sich Fehler, Inkompatibilitäten und Performance-Probleme erkennen und beheben, solange sie folgenlos bleiben. Dokumentierte Testfälle aus der Sandbox sind zugleich eine wertvolle Grundlage für die spätere Freigabeentscheidung.
Wie viele Sandbox- bzw. Nicht-Produktivumgebungen braucht ein ERP-Projekt?
Während einer ERP-Einführung wird häufig mit drei Nicht-Produktivumgebungen geplant – Entwicklung, Test/QAS und eine Schulungs-Sandbox –, sodass Entwicklung, Abnahme und Training sauber getrennt ablaufen. Nach dem Go-live lässt sich die Landschaft oft auf Entwicklung und Test konsolidieren, wenn der laufende Änderungsbedarf sinkt. Wie viele Umgebungen sinnvoll sind, hängt von Projektgröße, Parallelität der Arbeiten, regulatorischen Anforderungen und den Lizenz- bzw. Infrastrukturkosten ab. Wichtig ist neben der Anzahl auch, klar zu definieren, wer die Umgebungen pflegt und über welches Rollenkonzept Testberechtigungen vom Produktivsystem getrennt bleiben.