Bei Carve-Out Projekten, bei denen das bestehende SAP-System weiter genutzt werden soll, ist in der Regel die Bereinigung der Stamm- und Bewegungsdaten der verbleibenden Einheiten erforderlich. Wenn sich die Trennung eindeutig entlang von SAP-Organisationseinheiten vornehmen lässt (d.h. es besteht bereits für das herauszulösende Unternehmen ein eigener Buchungskreis und es wird z.B. kein gemeinsamer Kostenrechnungskreis verwendet), bieten sich einige Werkzeuge aus dem SAP-Standard als kostengünstige Option an, um für die Bereinigung der Stamm- und Bewegungsdaten ohne den Einsatz von speziellen Werkzeugen externer Anbieter auszukommen.
Dazu zählen unter anderem:
- SAP-Belegarchivierung
- Nutzung von SAP-Löschprogrammen, insbesondere im Finanzwesen
- Massenänderungstransaktionen
- eCATT
- Eigenentwickelte Löschprogramme für kundeneigene Tabellen
Hinsichtlich der Belegarchivierung ist anzumerken, dass in diesem Fall die Daten nicht in ein Archiv-System, sondern nur temporär in Dateiform in ein Verzeichnis auf dem SAP-Applikationsserver geschrieben werden, von wo sie später endgültig gelöscht werden können.
Die Umsetzung des Carve-Out-Projekts hat in den von uns auf diese Weise umgesetzten Projekten zunächst mit der Erstellung einer Sandbox (Systemkopie vom Produktivsystem) begonnen. In einem ersten Schritt werden in diesem System die zu löschenden Datenobjekte und die Anzahl der Belege ermittelt. Dabei werden die SAP-Organisationseinheiten ermittelt und dokumentiert, entlang derer später die Bereinigung erfolgen soll.
Den ermittelten SAP-Datenobjekten und -tabellen werden anschließend die dazugehörigen Archivierungsobjekte gegenübergestellt und anhand der betroffenen Organisationseinheiten die Selektionskriterien festgelegt. Dies beinhaltet auch die Prüfung, welche Vorbedingungen das jeweilige Archivierungsobjekt erfordert (z.B. Reihenfolge der Löschung abhängiger Objekte oder auch verfügbare Selektionskriterien). Da Prüfungen in den Standardarchivierungsläufen teilweise aus technischen Gründen und historisch gewachsenen Datenstrukturen nicht zu erfüllen waren, wurden die betroffenen SAP-Archivierungsreports angepasst. In Fällen, in denen sich zu einzelnen Datenobjekten kein geeignetes Archivierungsobjekt finden ließ, sowie für kundeneigene Tabellen („Y- bzw. Z-Tabellen“) wurden zudem Eigenentwicklungen vorgenommen. Teilweise konnten auch eCATT oder verschiedene Massenpflege-Transaktionen eingesetzt werden. Alle diese Schritte werden in einem Löschkonzept festgehalten, für das zusätzlich bei Projekten im validierten Umfeld Design- und Configuration Specifications erstellt werden.
Ein testweises Löschen in einer Sandbox-Umgebung dient anschließend dazu, die Auswahl der Archivierungsobjekte und der Selektionskriterien zu überprüfen sowie eine erste Version des detaillierten Cutover-Plans inklusive erster Laufzeiten zu erhalten. Die Betrachtung der Laufzeiten für die Datenlöschung ist deshalb wichtig, da für das Löschen in produktiver Umgebung von den Kunden häufig nur begrenzte Zeitfenster gewährt werden können. Da die Sandbox üblicherweise nicht über die Ressourcenausstattung des Produktivsystems verfügt, dient die Laufzeit dort jedoch nur als Anhaltspunkt. Unsere Erfahrung hat gezeigt, dass die Sandbox trotzdem mehr CPU, RAM und Batch-Prozesse als üblich erhalten sollte, da ein sinnvolles Arbeiten sonst nicht möglich ist. Eine konkrete Empfehlung kann hier nicht gegeben werden, da es von der Auswahl der Archivierungsobjekte sowie der zu löschenden Datenmenge abhängt.
Auf Grundlage der ersten Version des Cutover-Plans wird anschließend die Löschung auf dem späteren Testsystem durchgeführt und die Erkenntnisse z.B. hinsichtlich Laufzeiten und Reihenfolgen fließen darin ein. Als Ausgangsbasis für das System dient üblicherweise eine Kopie des Produktivsystems. Ob eine Bereinigung des Entwicklungssystems durchgeführt wird, muss individuell betrachtet werden. Oft haben sich in einem solchen System über längere Zeiträume hinweg Testdaten angesammelt, die nicht mehr konsistent sind und nicht oder nur mit großem Aufwand zu bereinigen sind. Hier kann es ggf. sinnvoller sein, den Entwicklungs-/Customizing-Mandanten über eine Mandantenkopie ohne Stamm- und Bewegungsdaten zu kopieren und anschließend den ursprünglichen Mandanten zu löschen.
Bei der Löschung des Testsystems ist es wichtig, die abgebende IT einzubeziehen und Prüfschritte zur Verifikation der vereinbarten Löschung im Cutover-Plan vorzusehen. Aufgrund des engen Zeitrahmens bei der späteren Umstellung des Produktivsystems können dann in der Regel nur noch stichprobenartige Kontrollen stattfinden. Daher ist es erforderlich, bereits im Rahmen der Testlöschung für Transparenz bezüglich des Vorgehens zu sorgen und die frühere IT sowie ihre Dienstleister frühzeitig einzubinden.
Da für die Bereinigung des Produktivsystems oft nur ein (ggf. verlängertes) Wochenende zur Verfügung steht, sollte die Löschung der einzelnen Datenobjekte gut durchgetaktet und über den Cutover-Plan entsprechend geplant sein, damit es nicht zu Leerlauf kommt und die Langläufer soweit möglich gleich zu Beginn abgearbeitet werden können. Hilfreich ist eine temporäre Verstärkung der Ressourcen des Produktivsystems (vor allem hinsichtlich der Ausstattung mit RAM, CPU und Batch-Prozessen) sowie eine Deaktivierung des Transaction-Logs der Datenbank. Dabei müssen jedoch auch Überlegungen zur Durchführung eines oder mehrerer Offline-Backups und der Wiederherstellungsstrategie für den Notfall getroffen werden.
Insgesamt konnte der beschriebene Ansatz in Carve-Out-Projekten verschiedener Kunden erfolgreich eingesetzt werden, darunter sind auch Unternehmen aus dem GxP-regulierten Umfeld (Pharmahersteller).
