ASUG Research und smartShift: Ausgleich zwischen Custom Code-Grundlagen und Clean Core-Bestrebungen

Ich bin Marissa Gilbert, Forschungsleiterin hier bei ASUG. Willkommen zum heutigen Webcast, in dem es darum geht, die Grundlagen des benutzerdefinierten Codes mit dem sauberer Kern Verfolgung. Bevor wir loslegen, möchte ich Sie an einige Webcasts erinnern. Wie immer wird der heutige Webcast aufgezeichnet, und Sie alle erhalten eine E-Mail mit einem Link zur Aufzeichnung, wenn wir heute fertig sind. Wenn Sie während des Webcasts Fragen haben, geben Sie diese bitte in das Frage-und-Antwort-Feld ein, und Arndt und ich werden sie gegen Ende der Sitzung beantworten. Und wenn es die Zeit erlaubt, werden wir natürlich auf so viele Fragen wie möglich eingehen. Und natürlich muss ich Sie als Forschungsleiter fragen, ob Sie an unserer Umfrage nach der Veranstaltung teilnehmen werden, wenn wir hier fertig sind. Wir würden gerne Ihr Feedback zur heutigen Sitzung hören.

Nun gut. Ich freue mich sehr, hier mit Arndt Hoffman, Chief Customer Officer bei smartShift, zu sprechen. Herzlich willkommen, Arndt. Würdest du unseren Zuhörern heute etwas über dich erzählen?

Treffen Sie unseren Experten: Arndt Hoffmann von smartShift

Ich bin Chief Customer Officer von smartShiftIch bin seit 2002 Teil des smartShift-Teams und seither in verschiedenen Rollen im Unternehmen und insgesamt im SAP-Bereich tätig, und zwar seit fast 29 Jahren. Das SAP-Mutterschiff lässt einen also nicht mehr los, wenn man einmal drin ist. 

Seit 2002 helfen wir unseren Kunden, ihre SAP-Systeme zu transformieren und zu modernisieren. Wir haben einen starken Fokus auf benutzerdefinierte SAP-Anwendungen und benutzerdefinierten Code und im Vergleich zu anderen sprechen wir auch, wenn wir über die Modernisierung und Optimierung von Code sprechen, nicht über manuelle Arbeit, sondern wir nutzen unsere eigene intelligente Automatisierungsplattform, patentiert, die wir in den letzten 20 Jahren aufgebaut haben. 

Wir haben also in den letzten Jahren vor allem Kunden bei der HANA- und S/4HANA-Transformation unterstützt und ihnen geholfen, diesen neuen digitalen Kern zu erreichen, aber auch einen Schritt weiter zu gehen, ihre Systeme zu optimieren, sie leistungsfähiger und sicherer zu machen und sie näher an den so genannten SAP Clean Core heranzuführen.

Die Nutzung der Automatisierung bringt unseren Kunden tatsächlich einen Geschwindigkeitsvorteil. Normalerweise transformieren wir SAP-Systeme in einem sehr kurzen Zeitrahmen von drei bis fünf Wochen. Wir nehmen eine Menge Risiko aus diesen SAP-Transformationsprogrammen. Außerdem geben wir unseren Kunden die Möglichkeit, ihre Investitionen, die sie in Anpassungen getätigt haben, zu nutzen und in ihr zukünftiges SAP-System einfließen zu lassen. 

Wir befinden uns nun im zweiten Jahr dieser Untersuchung, die wir gemeinsam durchführen. Unser Interesse bei smartShift besteht definitiv darin, zu verstehen, was Kunden über benutzerdefinierten Code denken, wie sie über die Umwandlung dieses benutzerdefinierten Codes in eine modernere Plattform denken, und vor allem auch, welche Hindernisse und Herausforderungen sie bei der Übertragung ihrer Anpassungen haben. Aus diesem Grund führen wir diese Untersuchung durch, und ich denke, wir können heute und in den nächsten Webinaren einige interessante Ergebnisse präsentieren.

Die wichtigsten Ergebnisse der Forschungsstudie

Wir haben diese Studie im Januar und Februar dieses Jahres unter 174 ASUG-Mitgliedern durchgeführt, deren Unternehmen benutzerdefinierten ABAP-Code erstellen und ausführen oder in benutzerdefinierte Code-Prozesse involviert sind oder ihren Wechsel zu SAP S/4HANA planen. Alle sind also in dieser Denkweise und in diesem Bereich, den wir in Bezug auf benutzerdefinierten Code und Migration untersucht haben. Aber es ist auch wirklich spannend, weil wir jetzt einige dieser Trenddaten haben, und wie Arndt angedeutet hat, werden wir tatsächlich in drei separate Webcasts gehen.

Das Gleichgewicht herstellen: Custom Code vs. Clean Core

Benutzerdefinierter Code ist für fast alle SAP-Kunden eine geschäftliche Notwendigkeit. Die Abhängigkeit und die Herausforderungen bei der Migration von benutzerdefiniertem Code auf SAP S/4HANA nehmen zu, und der Ausgleich zwischen sauberen Kernidealen und geschäftlichen Realitäten hat höchste Priorität. Zukünftige Umsteiger auf SAP S/4HANA planen die Nutzung von Automatisierung, unterschätzen aber die Herausforderungen der Code-Migration. Unsere letzte Erkenntnis aus der Studie ist, dass der Schlüssel zur Optimierung der Migration von benutzerdefiniertem Code darin liegt, sich die Zeit zu nehmen, um Wissenslücken zu schließen, sich auf das Änderungsmanagement zu konzentrieren und mit den richtigen Leuten zusammenzuarbeiten. 

Aber lassen Sie uns heute in unser Gespräch einsteigen. Ich werde die Forschungsergebnisse weitergeben, und Arndt wird seine wichtigsten Erkenntnisse und Expertenmeinungen darlegen. NUN GUT. Ich glaube, wir wollten hier ein wenig die Bühne bereiten. Wir haben viel darüber gesprochen, die ASUG, wo jeder seinen S/4HANA-Status hat, und wir haben dieses Jahr 20 S/4 genannt, richtig. 

Jeder hat irgendwie S/4 im Kopf. 42% unserer Umfrageteilnehmer sind vollständig oder teilweise migriert, obwohl 57% in den nächsten sieben Monaten bis zu mehr als zwei Jahren umziehen werden. Wir wissen also aus früheren Untersuchungen der ASUG, dass SAP-Kunden den Wechsel zu S/4HANA vor allem wegen des Endes der Mainstream-Wartung vornehmen - das ist unsere Frist bis 2027. Aber auch wegen der verbesserten Funktionalität, der Leistung von S/4HANA, die zu erhöhter Produktivität und Prozessstandardisierung führt, was Konsistenz, Qualität und Vorhersagbarkeit verbessern kann. Arndt, was denkst du über diese Zahlen? Scheinen sie für Sie im richtigen Tempo zu sein oder geben sie Anlass zur Sorge? Was ist Ihre Meinung?

Arndt Hoffmanns Einblicke in die Migration

Man kann sie so oder so lesen, denn wenn ich rechne, sind 73 bis 77% noch nicht zu S/4 übergegangen, richtig. Wenn Sie diese Zahl nehmen, sind wir im Jahr 2024, richtig. S/4HANA ist seit 2015 verfügbar. Wir sind also seit neun Jahren auf dem Markt, und das ist ziemlich erstaunlich. Ich erinnere mich noch an unser erstes S/4HANA-Projekt im Jahr 2015 mit der ersten Version für einen deutschen Kunden namens Doehler. Das Unternehmen stellt Zutaten für Säfte und Ähnliches her. Und sie wollten S/4HANA im Jahr 2015 implementieren. Ich erinnere mich, dass es für ein Unternehmen, das auch Logistikfunktionen hat, eine ziemlich große Herausforderung war, weil S/4HANA zu diesem Zeitpunkt noch nicht sehr ausgereift war. 

Seitdem hat sich eine Menge geändert. Wir sind jetzt bei der Version 2023 von S/4. Es wurden viele Funktionen hinzugefügt, das System wurde stabiler und auch bei unserem Thema, dem benutzerdefinierten Code, haben sich viele Dinge geändert. 

BTP ist da, sie haben die ABAP-Cloud-Plattformen, Steampunk, Embedded Steampunk und ähnliche Dinge eingeführt. Dieses ganze Konzept der Erweiterbarkeit für Clean Core. SAP hat also seine Arbeit getan und eine gute Grundlage für eine Technologiearchitektur geschaffen. Auch wenn es darum geht, wie man Anpassungen im System auf eine moderne und, wie sie es nennen, saubere Art und Weise vornehmen kann. Es ist also noch ein weiter Weg zu gehen, richtig. Das sind noch nicht viele. Aus der Plattformperspektive würde ich sagen, dass das System absolut einsatzbereit ist.

Herausforderungen bei der S/4HANA-Migration

Wenn wir uns ein wenig mit dem Thema S/4 befassen, dann ist kein größeres technologisches Upgrade ohne seine Herausforderungen. Natürlich, wie du gesagt hast, Arndt, weißt du, dass es sich im Laufe der Zeit definitiv verbessert hat und besser geworden ist, da wir alle in diesem Prozess lernen. Aber die größte Herausforderung bei der Migration zu S/4 sind die Anpassungen innerhalb der alten Instanzen. Dies ist das größte Risiko, dem die befragten Unternehmen bei der Migration ausgesetzt sind, gefolgt von einer unklaren Prozessdokumentation, dem Zeitaufwand für die Durchführung des Projekts und der erforderlichen Unterstützung, wenn das Team von seinen Hauptaufgaben abgelenkt wird. 

Arndt, überrascht es Sie, dass zu viele Anpassungen die größte Herausforderung für die Unternehmen darstellen? Nun, wir haben, glaube ich, mehr als 3300 SAP-Transformationsprojekte durchgeführt. Wir haben also Tausende von SAP-Systemen weltweit gesehen und Kunden in vielen, vielen Projekten geholfen. Es ist also nicht überraschend, denn wenn man sich ansieht, wie ein Standard- oder normales SAP-System aussieht, dann wurden all diese Systeme über viele Jahre hinweg entwickelt. Wir haben also schon Systeme aus den 1990er Jahren gesehen. Ich glaube, das durchschnittliche Systemalter liegt bei 15 Jahren. 

Für ein ECC-System haben sie auch alle diese Projekte durchgeführt, wir haben schöne Benchmarks. Ein durchschnittliches SAP-System enthält 23.000 kundenspezifische Objekte, mehr als 3 Millionen Codezeilen mit Anpassungen. Die Auswirkungen der Umstellung auf HANA und S/4HANA sind enorm. Sie müssen Tausende von Problemen korrigieren, damit Ihr Code funktioniert und mit HANA und S/4HANA konform ist. 

Es gibt Sicherheitsprobleme, Leistungsprobleme, fehlende Standardisierungen, Benennungskonventionen usw. im Code. All das trägt zu dieser Herausforderung des benutzerdefinierten Codes bei, und dazu kommt noch das, was oben drauf kommt. SAP hat sich gegenüber der Entwicklergemeinde immer sehr großzügig gezeigt. Es gibt also keine andere Standardsoftwarelösung, bei der man so ziemlich alle Kerntabellen und den Kerncode so nutzen kann, wie man es möchte. 

Das führt zu diesen monolithischen SAP-Systemen mit benutzerdefiniertem Code, der mit Standardcode vermischt ist, so dass diese Systeme nur schwer richtig zu betreiben sind. Und wir alle wissen, dass viele SAP-Systeme den Release-Zyklen weit hinterherhinken. Sie sind immer noch auf ECC und nicht auf S/4 umgestellt. Und das aus gutem Grund, denn die Anpassungen wurden so geschrieben, wie sie zu dem Zeitpunkt geschrieben wurden. Und ja, kundenspezifischer Code ist der kritische Pfad bei allen Transformationen, und Sie sollten wirklich darüber nachdenken und planen, wie Sie das angehen, wenn Sie auf S/4 umsteigen. Das ist kritisch. Ja, absolut. Und ich denke auch, dass es viele Herausforderungen gibt, das ist klar. Aber ich denke, die Tatsache, dass der benutzerdefinierte Code wirklich hervorsticht, zeigt, wie wichtig er für Unternehmen ist. Es ist eine so große Herausforderung, weil es für sie so wichtig ist.

Custom Code: Eine geschäftliche Notwendigkeit

Obwohl kundenspezifischer Code viele Herausforderungen mit sich bringt, haben wir bereits gesagt, dass 95% der befragten Unternehmen ABAP-Code erstellen und ausführen, um ihre SAP-Softwareanwendung zu erweitern. Sie haben es also schon von Ihren Kunden gehört, Sie haben es gesehen, es ist wahr. Hier sind die Daten, die dies belegen, und unsere Untersuchungen zeigen, dass SAP-Kunden nicht von ihrem benutzerdefinierten Code lassen können. Er ist von zentraler Bedeutung für die Unterstützung ihres Geschäfts. Sie wissen, dass es hier nicht nur um "nice to have" geht. Er ist ein wesentlicher Bestandteil, damit die Systeme für ihr Unternehmen funktionieren. Arndt, Sie wissen, wie Sie die Antworten darauf sehen, warum kundenspezifischer Code in ihrem Unternehmen erforderlich ist. Ich denke, das sind ziemlich interessante Ergebnisse, auch wenn man sich die Trends hier ansieht. Es sieht so aus, als ob die Bedeutung hier sogar noch zunimmt. Sie müssen sich jede Kategorie ansehen und sich selbst fragen. Brauche ich wirklich benutzerdefinierten Code und Anpassungen für diese Kategorie? So würde ich zum Beispiel fragen, hier ist eine Menge, 48% sagen, sie brauchen es für Berichte und Analysen und wie man Systeme verbindet. 

Man könnte sich fragen, ob es dafür nicht bessere Technologien gibt. Es gibt eine Menge Dinge, die mit BTP kommen, die man nutzen könnte, aber dann gibt es noch die anderen wichtigen Kategorien. Es ist immer noch so, dass SAP eine Standardsoftware ist und nicht alle branchenspezifischen Anforderungen abdeckt, richtig. Daher gibt es hier 64%, die branchenspezifischen Anforderungen steigen ab 2023 um 8%. Das ist ein wichtiger Faktor, warum man kundenspezifischen Code braucht, andere Dinge, die hier herausstechen, auch wenn es nicht die höchste Zahl ist, aber Sie sehen hier immer noch 28%, um in der Lage zu sein, innovativ zu sein, 22%, um einen Wettbewerbsvorteil zu haben, der ebenfalls steigt, richtig. In diesem benutzerdefinierten Code stecken also wichtige Dinge, und ich denke, das ist der Zauber. Der benutzerdefinierte Code bringt viele Herausforderungen mit sich, aber die Magie liegt auch darin, dass es gute Dinge gibt, in die ich Millionen von Dollar investiert habe, um diese Anwendungen zu entwickeln. Man sollte sich also besser um sie kümmern und sie modernisieren. Ja, absolut. Und ich denke, Sie haben Recht. Man muss, wissen Sie, es ist genau wie mit den Herausforderungen. Wo braucht man es? Man muss es wirklich identifizieren. Und gibt es derzeit bessere Tools, um einige dieser anderen Herausforderungen, mit denen Unternehmen konfrontiert werden können, wirklich zu entschärfen?

Die Zukunft von Custom Code bei S/4HANA-Migrationen

Natürlich kann es das Ziel sein, den benutzerdefinierten Code einzuschränken, aber in manchen Fällen ist dies nicht möglich. Aber je weiter Organisationen in ihren S/4HANA-ReisenDie Begrenzung des benutzerdefinierten Codes ist eine anerkannte Best Practice. Die Realität ist, dass Anpassungen und nicht unterstützte Geschäftsanforderungen hier sicherlich bestehen bleiben werden. Was ist Ihre Meinung dazu, Arndt? Glauben Sie, dass sie ihren Zielen näher kommen oder wird es immer schwieriger? Nun, ich denke, das ist genau das Dilemma, über das wir gesprochen haben. Einerseits stellen sie eine Belastung für Sie dar. Sie schränken die Flexibilität des Systems und die Verfügbarkeit von Upgrades in Systemen ein. Sie möchten also den Umfang des benutzerdefinierten Codes reduzieren. Auf der anderen Seite wollen Sie sie aber auch beibehalten. Die Frage ist, dass wir heute nicht zu sehr darauf eingehen werden. Aber es geht auch nicht immer um weniger benutzerdefinierten Code. Es geht nur darum, benutzerdefinierten Code und benutzerdefinierte Prozesse auf eine bessere Weise zu haben. Und dann kommen wir zu diesen neuen Konzepten, die Teil dieses Projekts sind sauberer Kern Die Idee, ein Cloud-fähiges System mit Erweiterungen und Anpassungen im System zu haben, das upgradefähig und upgradefest ist, ist richtig. Das ist hier das größte Problem. Man kann Anpassungen vornehmen, wenn sie nicht all diese Herausforderungen mit sich bringen, und das bedeutet, dass man sie auf eine angemessene Weise schreibt. Man befolgt bestimmte Cloud-Praktiken in der Cloud-Syntax, kodiert sie, nutzt nur verfügbare APIs von SAP, APIs auf der Whitelist, die keine direkten Tabellenaufrufe machen, und solche Dinge. Also, ja, Begrenzung, aber auch Anpassungen auf die richtige Art und Weise. Und ja, darauf konzentrieren wir uns. Wir helfen den Kunden, alte Anpassungen zu übernehmen und sie nach diesen neuen Prinzipien zu modernisieren, indem wir die Automatisierung und nicht die manuelle Anpassung nutzen. Das ist unser Part.

Fragen und Antworten

Perfekt. Hier ist also unsere letzte Folie mit Daten, und dann haben wir Zeit für einige Fragen. Wenn Sie also Fragen haben, stellen Sie sicher, dass Sie diese in die Q&A-Box auf Ihrem Bildschirm eingeben. Hier geht es also wieder um die Frage, wie Unternehmen bei ihren S/4HANA-Migrationen vorankommen, und der Großteil der Befragten wird weiterhin benutzerdefinierten Code verwenden. Das wird sich nicht ändern. Wir haben darüber gesprochen, aber sie werden ihn in geringerem Umfang nutzen, und das überwiegt auch die Umstellung auf moderne Erweiterungskonzepte. Stimmt das mit dem überein, was Sie auch bei vielen Ihrer Kunden beobachten? Auf jeden Fall. Im Rahmen meiner Tätigkeit habe ich in letzter Zeit an vielen Benutzergruppentreffen teilgenommen. Letztes Jahr war es, glaube ich, um das Jahr 2020 oder so. Und ich stelle fest, dass sich das Bewusstsein für diese modernen Prinzipien, für Clean Core und Erweiterungskonzepte stark verändert hat. Und ich komme auch dem Jahr 2027, dem Clean Core, immer näher. Diese Greenfield-Idee ist aus meiner Sicht ein wenig verschwunden, richtig, weil es jetzt näher an 2027 mal nicht da ist, um große wissenschaftliche Projekte zu machen und so Kunden wirklich darüber nachdenken. Ja, ich brauche die Prozesse, wie ich sie vorher aufgebaut und angepasst habe. Aber sie denken auch darüber nach, wie ich sie modernisieren kann, so dass sie mir diese Herausforderungen in Zukunft nicht mehr aufbürden. Und so steigt das Bewusstsein für saubere Kerne. Die Kunden beschäftigen sich mit diesen neuen Prinzipien. Wie ich schon sagte, werden sie auch von SAP durchdacht, und das spiegelt so ziemlich auch meine Diskussionen wider, die ich auf dem Markt führe. Ja, absolut.

Clean Core Konzept

Wir haben also ein paar Fragen, aber ich möchte nur die nächste Folie vorführen. Dies ist eine schnelle Code-Analyse von smartShift. Wenn Sie also den QR-Code oder die URL eintippen oder den QR-Code scannen, werden Sie ebenfalls zu diesem Ergebnis geführt. Und dies ist ein Gesundheitscheck, der von smartShift angeboten wird. Probieren Sie das aus. Dann haben wir noch ein paar Fragen, die eingegangen sind. Wenn smartShift den benutzerdefinierten Code eines Kunden analysiert, erhält der Kunde dann nur eine riesige Liste, die er durchgehen und erneut analysieren muss?

smartShift ist definitiv kein weiteres Analysetool. Bei smartShift dreht sich alles um automatisierte Transformation. Wir ändern also wirklich benutzerdefinierte Codes, nutzen unsere Plattform und setzen Transformationsalgorithmen in großem Maßstab ein. Ich will Ihnen nur ein Beispiel geben. Wir arbeiten für Procter & Gamble und helfen ihnen dabei, ihr Lieferkettensystem auf S/4 umzustellen. Mit Hilfe dieser Plattform haben wir 1,3 Millionen Änderungen vorgenommen oder 1,3 Millionen Probleme in ihrer Codierung automatisch behoben. Es handelt sich also um echte Automatisierung auf höchstem Niveau. Wir haben das in drei bis fünf Wochen geschafft, bei einer Fehlerquote von etwa 20 Tickets und Tests für 1,3 Millionen Änderungen. Und als Teil dieser 1,3 Millionen Änderungen haben wir die gesamte HANA-Konformität, die S/4 HANA-Konformität, korrigiert. Wir haben den Code leistungsfähiger und sicherer gemacht, ihn an die neuesten ABAP-Standards angepasst und dergleichen mehr. Bei smartShift geht es also definitiv um Transformation, Automatisierung und nicht darum, Ihnen einen weiteren riesigen Satz von Excel-Dateien zu liefern, die Sie dann selbst in Ordnung bringen müssen.

Unterschiedliche Analyseansätze

Matt hatte eine weitere Frage. Er sagte, dass wir im ECC bereits den Prozess der Identifizierung unserer benutzerdefinierten Code-Analysten anhand von SAP CCLM-Prozess- und Nutzungsdaten durchlaufen haben. Wir haben festgestellt, dass dieser Prozess nicht immer alles findet, was tief im Code steckt. Wie unterscheidet sich smartShift bei der Analyse von kundenspezifischem Code? 

Nun, zum einen sind CCLM, die Standard-Analysewerkzeuge von SAP, gut. Es geht also nicht darum, in der Analyse besser oder schlechter zu sein. Die smartShift-Analyse ist immer transformationsorientiert. Daher ist unsere Analyse sehr tiefgehend. Wenn wir 1,3 Millionen Codezeilen oder Probleme in einem Supply-Chain-System von Procter & Gamble ändern wollen, sollten wir besser wissen, was wir tun. Unsere Analyse ist ebenfalls sehr gründlich. Wir verstehen Abhängigkeiten, Datenfluss, CRUD-Vorgänge usw. Unsere Analyse zielt immer darauf ab, was man mit Automatisierung erreichen kann, wie man eine Transformations-Roadmap auf der Grundlage von Automatisierung erstellt. CCLM ist gut. Wir nutzen auch viel von dem SAP-Input. Wir müssen die Vereinfachungselemente und die Nutzungsdaten aus dem SAP-System verstehen, aber wir versuchen immer, diese zu verbessern. Wenn wir Nutzungsdaten verwenden, um Code aus dem Verkehr zu ziehen, berücksichtigen wir auch all dieses Wissen über Abhängigkeiten, um sicherzustellen, dass wir nichts aus dem System löschen, was wir nicht sollten. Nichts ist also gut oder schlecht, es ist nur anders und immer transformationsorientiert.

Schlussfolgerung

Vielen Dank, Arndt, für die aufschlussreiche Diskussion. Wir werden am 28. Mai und am 18. Juni zwei weitere Webcasts in dieser Reihe veranstalten, in denen wir uns mit Erfolgsgeschichten und strategischen Rollen bei SAP-Migrationshindernissen befassen werden. Wir freuen uns darauf, Sie alle wiederzusehen.