Cookie

Zuverlässige SAP-Migration durch Testautomatisierung

"Was wir mit dem Projekt geschafft haben, ist ein Win-Win für alle."

Interview mit Stephan Oswald & Christian Mauth, Test Experts, Telekom MMS

 

Alle Unternehmen, die Anwendungen von SAP nutzen, müssen bis 2027 zur SAP eigenen Datenbanktechnologie HANA migrieren. Was sind die Herausforderungen dabei?

Oswald: SAP bringt mit dem Technologiewechsel zu S/4 oder für Cloud Anwendungen von SAP C/4 die vierte Überarbeitung ihrer ERP- bzw. CRM und Industrieanwendungen für Unternehmen. Dabei bietet der Wechsel den größten technologischen Sprung in der Unternehmensgeschichte, bringt aber in dem Bereich auch Wandel mit sich, da die Produkte nun ausschließlich in Verbindung mit der SAP eigenen Datenbanktechnologie HANA verwendet werden können. Die Migration hin zu S/4, C/4 und HANA bringt erhebliche Aufwände bei der Migration mit sich, da die meisten Unternehmen nicht den Standard von SAP verwenden, sondern die Software auf ihre Bedürfnisse angepasst haben. Mit den technologischen Veränderungen gab SAP ebenfalls bekannt, mehr Innovationen in schnelleren Zyklen veröffentlichen zu wollen. Anwendergruppen und Analysten gehen davon aus, dass dies bis 2027 bis zu acht Release Neuerungen pro Jahr sein können. Mit jedem Release müssen die persönlichen Änderungen eines Unternehmens migriert und anschließend, vor Inbetriebnahme, getestet werden. Doch bevor es soweit ist, muss die Migration gemeistert werden. Über 50.000 SAP S/4HANA-Umstellungsprojekte könnten in den kommenden sieben Jahren in Deutschland anstehen, bei denen Altsysteme stillgelegt, alte Datenbestände gerettet und ausgewählte Daten überführt werden. Wie viele Migrationsprojekte im Rahmen der SAP-HANA-Thematik anstehen, lässt sich anhand offizieller SAP-Zahlen abschätzen: Global betrifft der Wechsel circa 200.000 Unternehmen, wobei etwa 25.000 den Umstieg bereits hinter sich haben. 44 Prozent der SAP-Umsätze kommen aus dem Raum EMEA und 35 Prozent davon aus Deutschland. Es ist also mit zigtausend Projekten in den nächsten Jahren zu rechnen.

Über 50.000 SAP S/4HANA-Umstellungsprojekte könnten in den kommenden sieben Jahren in Deutschland anstehen, bei denen Altsysteme stillgelegt, alte Datenbestände gerettet und ausgewählte Daten überführt werden.

Stephan Oswald, PreSales Spezialist der Telekom MMS

Mauth: Im Grunde genommen besteht so ein Wechsel aber aus zwei Migrationsprojekten: Erstens dem Datenbankaustausch, wenn das Unternehmen beispielsweise seine Oracle-Datenbank oder sein IBM DB2 gegen die SAP-Hana- In-Memory-Datenbank tauscht. Danach gilt es, zweitens, die „alten“ SAP-Applikationen – sei es die Finanzanwendung FI CO, das Materialmanagement-Modul MM oder die Personal-Lösung HR – mit Anwendungen aus der neuen S/4HANAApplication-Suite zu tauschen. Bezüglich Punkt 2 kann dies durchaus schwierig für Unternehmen werden, da viele Prozesse im alten Umfeld auf das Unternehmen abgestimmt sind. Jede Menge Custom Code, der beispielsweise in ABAP oder Java geschrieben wurde, muss geprüft und gegebenenfalls migriert werden. Die Herausforderung stellt dabei der Custom Code dar. Unternehmen müssen zunächst ermitteln, welcher Teil des Custom Codes vom neuen Standardumfang in S/4HANA abgedeckt ist, was noch angepasst werden muss und inwieweit sich dadurch Schnittstellenproblematiken ergeben. Expertenschätzungen gehen davon aus, dass rund 70% der angepassten Code-Zeilen aufgrund der neuen Funktionalitäten in SAP S/4 gar nicht mehr benötigt werden.

 

Wer in Unternehmen testet SAP-Anwendungsfälle?

Mauth: Im Umkehrschluss bedeutet das, dass alle Prozesse und Transaktionen aus Prozesssicht des Unternehmens getestet werden müssen, sowohl in Schritt 1 bei der Migration in Richtung HANA, als auch in Schritt 2 bei der Überführung hin zu S/4. In allen Fachbereichen entstehen erhebliche Aufwände, welche durch die IT-Unternehmen, die mit der Migration beauftragt sind, nicht erbracht werden, da sie die detaillierten Kundenkenntnisse nicht besitzen.

Was ist das Besondere am Testen im SAP-Umfeld?

Oswald: Durch die angepassten Prozesse und die neuen Funktionen auf den S/4 Plattformen müssen die Fachbereiche nun ganz besonders gut planen, damit ausreichend Ressourcen zur Verfügung stehen. Das ist aber leichter gesagt als getan. Die meisten Fachbereiche leiden durch die aktuellen Marktsituationen und den Fachkräftemangel unter einer derart hohen Last, dass diese Aufwände das Tagesgeschäft erheblich beeinflussen.



Und wie kann nun hier automatisiert werden?

Oswald: Um nun langfristig für solche Anforderungen gewappnet zu sein, sollten Unternehmen diese Migrationsszenarien nutzen, um Automatisierungstechnologien einzuführen. Hierbei sollten in Schritt 1, Analysewerkzeuge und Prozessdesign genutzt und projektiert werden, die SAP mit dem Solution Manager 7.2 mitbringt oder auch Anbieter aufnehmen, die sich auf die Migration und Releaseanalyse spezialisiert haben und von SAP empfohlen werden. Die Prozesse sollten detailliert und genau im Solution Manager hinterlegt sein, Testfälle von den Fachtest-Probanden mit Test-Spezialisten aufgebaut werden z.B. mit qTest von Tricentis und anschließend mit Testautomationswerkzeugen designt werden. Hierbei ist darauf zu achten, dass die Entwicklungs- und Testkette integriert ist und ggfs. Fehler direkt an die Entwickler und IT-Spezialisten zugeführt werden. Hier können Continous Delivery Ketten, wie z.B. JIRA genutzt werden. Leider hat auch der SAP Solution Manager 7.2 nur eine skriptbasierte Testautomatisierung an Bord, sodass hier wieder Testentwickler mit in Projekte integriert werden müssten, was die Aufwände um ca. 25% des Migrationsaufwandes anschwellen lassen würde. Es gibt am Markt mittlerweile von SAP zertifizierte Werkzeuge wie Tosca von Tricentis und Testimony von Basis Technologies, die Kunden diese Aufwände ersparen und auch nach einer Migration bei jedem Testszenario eingesetzt werden können. Bringt man noch Analysewerkzeuge, Release und Deployment, sowie Testwerkzeuge zusammen, können Automatisierungsraten von nahezu 90% erreicht und langfristig im Releaseprozess verankert werden.

Welche Vorteile bringt die Testautomatisierung in diesem Anwendungsfall?

Mauth: Unsere Erfahrungen zeigen, dass Fachbereiche zu 70% entlastet werden, Entwicklungs- und Migrationsprojekte durch 90% Automatisierungsgrad Sicherheiten bekommen, dass Planungen eingehalten werden. Klassische Testautomatisierungen, die skriptbasiert sind, können schnell abgelöst werden. Hierdurch erlangen Kunden nochmal 75% Wartungsreduzierung. In einem beispielhaften Kundenprojekt, bei welchem bereits auf S/4HANA und C/4HANA migriert wurde, konnten mit den gleichen Ressourcen bis zu sechs Releases pro Jahr realisiert werden, wo vorher nur zwei möglich waren. Das Beispielunternehmen hatte pro Release früher 110 Tage Testaufwand in den Fachbereichen, heute lediglich noch 27 Tage in den Fachbereichen, im nächsten Schritt möchte der Kunde alle End2End Szenarien betrachten und auch hier noch einmal Einsparpotentiale heben.

Dies war nun speziell für SAP. Ab wann lohnt sich allgemein die Testautomatisierung?

Oswald: Unternehmen können entweder vertikal ihre IT-Architektur automatisieren und gehen von den Kernprozessen nach außen. Letztlich gilt es, die größten Showstopper und Bottlenecks in Projekten oder Releasezyklen zu identifizieren, um effizienter zu werden. Kunden, die ein breites Kundenangebot online adressieren, sollten eher aus dieser Sicht anfangen zu automatisieren und als Zielsetzung haben, Kernprozesse wie Vertriebsszenarien, mit z.B. Salesforce einem hohen Automatisierungsgrad zu unterwerfen. Grundsätzlich sollten die zentralen Testinstanzen eine End2End Automatisierung im Fokus haben, da sich durch neue Technologien erhebliche Reduktionen an Geld und Personal erreichen lassen.

 

Über unsere Speaker

Stephan Oswald ist seit 2015 als PreSales Spezialist bei der Telekom MMS und Ansprechpartner für Themen rund um Software-Qualität und Testautomatisierung. Zudem ist er Mitglied in der ASQF-Fachgruppe "Testdaten" und Autor diverser Fachartikel zum Thema.

Christian Mauth ist seit 2019 als Project Manager bei der Telekom MMS und Ansprechpartner für Themen rund um Testautomatisierung und Agile Testing. Er ist seit über 10 Jahren in der Softwareentwicklung sowohl auf der Entwickler als auch auf der Testseite tätig und verfügt daher über eine Vielzahl an Projekterfahrungen.