Die Aktualisierung von Entwicklungssystemen kommt bei SAP Kunden häufig zu kurz. Der Aufwand ist einfach zu hoch und lohnt sich für die meisten Unternehmen nicht. Also werden andere Wege gesucht, indem Entwickler zum Beispiel eigene Daten generieren oder im Qualitätssicherungssystem testen. Doch ist das wirklich zufriedenstellend für Entwicklerteams?
Pascal Kaldenbach hat mit Tobias Kutnjak, SAP Anwendungsentwickler bei Pneuhage Management GmbH & Co. KG, über dieses Problem gesprochen:
Wie ist die SAP Systemlandschaft bei Pneuhage aufgebaut?
Tobias Kutnjak: Die Pneuhage Unternehmensgruppe zählt 166 eigene Filialen in ganz Deutschland (Pneuhage Reifendienste, Ehrhardt Reifen + Autoservice, First Stop), einen international tätigen Großhandel (Interpneu), 3 Runderneuerungsbetriebe und eine Partnerorganisation (Reifen 1 Plus) mit mehr als 500 angeschlossenen, eigenständigen Reifenfachhandelsbetrieben.
Diese werden über eine zentrale SAP Instanz in einem ERP System auf einer HANA-Datenbank abgebildet. Dort setzen wir eine klassische, dreistufige Landschaft mit Entwicklung, Test und Produktion ein. Eine Besonderheit ist vielleicht, dass wir das HCM Modul bereits früh in einem eigenen Mandanten abgebildet haben, das heißt, unsere Produktion und Test bestehen jeweils aus zwei Mandanten.
Vor welchen Herausforderungen standen Sie beim Aktualisieren Ihrer Test- und Entwicklungssysteme?
Tobias Kutnjak: Wir haben die Testsysteme und den Testmandanten auf unserem Entwicklungssystem über einen klassischen Backup & Restore wiederhergestellt. Das hat uns aber, vor allem durch die Nacharbeiten, viel Aufwand gekostet, sodass eine Kopie bis zu einer Woche gedauert hat. Außerdem war dieses Vorgehen nicht sehr vorteilhaft für unseren Speicherbedarf, da wir alle Daten 1:1 aus der Produktion kopiert haben. Das ist mit einer HANA Datenbank dann auch entsprechend kostspielig.
Die Daten in unserem Entwicklungssystem wurden eigentlich nie aktualisiert, da das immer ein Projekt nach sich gezogen hätte, was den Aufwand nicht wert gewesen wäre.
Wie sind Ihre Entwickler damit umgegangen keine aktuellen Testdaten zur Verfügung zu haben?
Tobias Kutnjak: Wir haben uns auf dem Entwicklungssystem aufgrund der veralteten und teils obsoleten Testdaten im Wesentlichen auf Komponententests fokussiert. Um vollständige Integrationstests sowie alle abschließenden Tests durchzuführen, wurden die Projekte auf unser Testsystem transportiert.
Das Testsytem entspricht im Bezug auf die Stamm- und Bewegungsdaten und den Schnittstellenverbindungen unserem Produktivsystem. Für kleinere Entwicklungen oder Erweiterungen bestehender Programme haben wir auch oft eigene Testdaten generiert, was teils viel Zeit gekostet hat.
Durch das Aufteilen der Tests auf mehrere Systeme wurde auch ein größerer Aufwand verursacht, da im Korrekturfall neue Transportaufträge angelegt und transportiert werden mussten, bevor weitere Tests durchgeführt werden konnten.
Wie haben Sie diese Themen in Ihrem Testdatenmanagement gelöst?
Tobias Kutnjak: Das Ziel für unser Testdatenmanagement war es, aktuelle Daten in unser Test- und Entwicklungssystem zu bringen. Diese Daten sollten mit schnelleren Laufzeiten, weniger Nacharbeiten und mit weniger Speicherplatzbedarf von unserem Produktivsystem kopiert werden.
Mit der Lösung Client Sync aus der Data Sync Manager Suite von EPI-USE Labs konnten wir das umsetzen.
Vor der Kopie läuft mit Client Sync ein Export File, der bereits die reduzierten Daten in eine Datei lädt. Dieses Export File wird dann in das Testsystem oder den Testmandanten importiert, welcher für die Dauer der Kopie nicht zur Verfügung steht. Der Vorgang dauert etwa 10 Stunden, anfallende Nacharbeiten, bis wir das System wieder freigeben können, schon mit eingerechnet.
Und wie hat sich dadurch die Situation in Ihrem Entwicklungssystem verändert?
Tobias Kutnja: Für das Entwicklungssystem empfiehlt EPI-USE Labs, nicht den Entwicklungsmandant zu aktualisieren, sondern einen zweiten Mandanten mit Customizing- und Stammdaten, stark reduziert zur Verfügung zu stellen. In unserem Entwicklungssystem arbeiten wir schon lange mit dem zweiten Mandanten für Customizing- und Stammdaten, weswegen wir diesen nicht neu aufbauen, sondern ihn lediglich aktualisieren mussten. Da es bei uns zwei produktive Mandanten, also ERP und HCM gibt, haben wir somit 3 Mandanten in unserem Entwicklungssystem.
Die Datenaktualisierung durch eine Mandantenkopie haben wir erst vor Kurzem durchgeführt, um den Entwicklern bessere Optionen zum Testen zu geben. Da wir keinen neuen Mandanten aufbauen mussten, war der Zeitaufwand mit etwa 12 Stunden gering genug, um die Mandantenkopie auch unter der Woche durchführen zu können.
Wir haben den Import Abends eingeplant, damit dieser über Nacht läuft und morgens dann die anfallenden Nacharbeiten erledigt. Da der Customizing- und Stammdaten Mandant getrennt von unserem Entwicklungsmandanten ist, konnten unsere Entwickler ohne Probleme weiter arbeiten, während die Nacharbeiten durchgeführt wurden.
Durch die Mandantenkopie können wir nun auf unserem Entwicklungssystem nicht nur Komponententests durchführen, sondern auch Integrationstests, ohne hierfür eigene Testfälle zu bauen. Dadurch sparen wir Zeit und es ist angenehmer zu entwickeln. Es liegen genug Testfälle vor, um Programme und Projekte ausgiebig zu testen, bevor wir auf unserem Testsystem einen letzten System- und Abnahmetest mit Key-Usern der jeweiligen Abteilungen durchführen.
Vielen lieben Dank für das Interview!
Einen Kommentar schreiben