DSAG Handlungsempfehlung zur Weiterbildung von SAP Entwicklern

DSAG Handlungsempfehlung zur Weiterbildung von SAP Entwicklern

Veröffentlicht am 21. Juli 2026

Gestern hat die DSAG eine Handlungsempfehlung zur Weiterbildung von SAP Entwicklern veröffentlicht. Das könnt Ihr hier direkt runterladen: https://impulsant.dsag.de/wp-content/uploads/2026/07/CIO-Upskilling.pdf

SAP-Entwickler schulen: Warum das Management handeln muss

Wir erleben als Trainer jeden Tag, dass es umfangreichen Schulungsbedarf bei SAP Kunden gibt. Darum begrüssen wir, dass auch die DSAG dazu Position bezogen hat. Damit sollen die Mitarbeiter von SAP Entwicklungsabteilungen Argumente an in die Hand bekommen und vor allem auch eine externe, offizielle Empfehlung zu dem Thema.

Wie dieses Paper entstand

Beim Präsenztreffen des Arbeitskreises Development im Februar, direkt nach dem DSAG Zukunftstag Development, haben wir uns in kleinen Gruppen mit verschiedenen Themen beschäftigt. Ich war in der Gruppe, die sich um Fortbildung für Entwickler gekümmert hat. Und ziemlich schnell waren wir uns einig, wo das Problem wirklich liegt: nämlich selten in der Entwicklungsabteilung selbst. Die Entwickler wissen meistens ganz genau, was sie lernen müssten. Nur entscheiden sie das nicht.

Aus dieser Runde entstand die Idee für ein DSAG CIO Paper zum Thema Upskilling. Ein kurzes Dokument, das CIOs und IT-Leitern erklärt, warum Fortbildung für SAP-Entwickler eine strategische Investition ist und kein Nice-to-have. Acht Autoren aus dem Kreis der DSAG-Mitglieder haben daran mitgeschrieben. Einen Entwurf hatten wir bei den ABAP Development Days ausgehängt und dort noch einiges an Feedback eingesammelt.

In einem CIO Paper muss man sich kurz fassen. Deshalb möchte ich hier einige Punkte etwas ausführlicher besprechen, als es dort möglich war.

Migration gemacht, Potenziale liegen gelassen

Viele Unternehmen sind inzwischen auf S/4HANA oder mittendrin in der Migration. Das System läuft, die alten Programme funktionieren. Genau das verdeckt aber das eigentliche Problem: Eine technische Migration bringt die Eigenentwicklungen nicht auf einen neuen Stand. Alte Prozesse, alte Technik, überflüssige Eigenentwicklungen bleiben, wie sie sind. Man nutzt die neue Plattform auf dem Niveau der alten. Ungefähr so, als hätte man in seinen VW Golf einen Porsche-Motor eingebaut, führe damit aber weiterhin wie eh und je zum Bäcker.

Mit Clean Core, CDS, RAP und Fiori Elements hat SAP komplett neue Paradigmen eingeführt. SAP setzt diesen Stack auch für die eigenen Produkte ein, und das ist ein ziemlich verlässlicher Hinweis darauf, dass es sich um keine Übergangslösung handelt. Wer das ignoriert, programmiert an der Plattform vorbei. Technisch läuft trotzdem alles. Die technischen Schulden wachsen still im Hintergrund und fordern irgendwann Zinseszins.

Veraltete Kenntnisse fallen eben nicht sofort auf. Alte SAP-Technologien laufen noch jahrelang. Die Defizite zeigen sich erst später: in schwachen Architekturentscheidungen, in Workarounds, die Migrationsprojekte ausbremsen, in Eigenentwicklungen, die bei jedem Release nachgepflegt werden müssen.

Clean Core geht auch On-Stack

Ein Missverständnis begegnet mir immer wieder: Viele glauben, Clean Core bedeute zwingend, dass Erweiterungen auf die BTP ausgelagert werden müssen. Das hat die SAP früher tatsächlich mal so kommuniziert, und diese Aussage geistert bis heute durch die Köpfe. Sie stimmt aber so nicht mehr. Mit der On-Stack Extensibility über ABAP Cloud gibt es inzwischen eine ausgereifte Möglichkeit, Erweiterungen direkt im S/4HANA-System umzusetzen, sogar in der Public Cloud. Upgradesicher bleiben sie, weil sie ausschließlich stabile, freigegebene APIs der SAP verwenden. Damit verschiebt sich die Fragestellung: Es geht darum, welche Erweiterungstechnologie zum konkreten Anwendungsfall passt. Und um das entscheiden zu können, braucht es Kenntnisse in beiden Ansätzen.

Management Attention: das eigentliche Problem

In der Arbeitsgruppe war das schnell Konsens. Die Entwickler kennen den Handlungsbedarf. Es hakt bei denen, die über Schulungsbudgets und Kapazitätsplanung entscheiden.

In vielen Unternehmen wird Entwicklerfortbildung als operatives Randthema behandelt: ein Kurs aus dem Katalog, genehmigt, wenn gerade kein Projekt drückt. Das hat lange funktioniert, weil sich über die Jahre wenig geändert hat. Mit S/4HANA, Clean Core und BTP funktioniert diese Logik aber nicht mehr. Die technischen Grundlagen haben sich in den letzten 15 Jahren grundlegend gewandelt, und die Komplexität hat erheblich zugenommen.

Deshalb richtet sich das DSAG CIO Paper auch nicht an Entwickler, sondern an CIOs, IT-Leiter und alle, die über Investitionen in Ausbildung entscheiden. Entwickler brauchen eine Argumentationshilfe, die auf Managementebene funktioniert. Genau dafür haben wir es geschrieben.

Wer noch mitgedacht werden muss

Unsere Arbeitsgruppe kam überwiegend aus dem ABAP-Umfeld, entsprechend liegt dort auch der Fokus des Papers. Der Schulungsbedarf hört aber nicht bei den ABAP-Entwicklern auf.

Business Consultants sind in SAP-Projekten die Schnittstelle zwischen Fachbereich und Entwicklung. Wenn sie Anforderungen weiterhin auf GUI-Transaktionen und klassisches Customizing zuschneiden, weil sie Fiori Apps und das dahinterliegende Technologiemodell nicht kennen, dann entstehen Spezifikationen, die an der aktuellen Plattform vorbeigehen. Am Ende werden Dinge eigenentwickelt, für die der SAP-Standard mit Fiori längst eine Antwort hätte. Oder es kommen Anforderungen auf den Tisch, die sich mit RAP gar nicht umsetzen lassen, weil sie auf einer ganz anderen Architekturlogik aufbauen.

Basis-Administratoren rutschen beim Thema BTP und Side-by-Side-Entwicklung schnell in eine Rolle, auf die sie niemand vorbereitet hat. CAP-Anwendungen auf der BTP verlangen Know-how zu BTP-Struktur, Authentifizierung, Security und CI/CD-Pipelines. Wer die Basis nicht schult, steht am Ende mit einer Plattform da, die keiner administrieren kann.

Und dann sind da noch die externen Dienstleister. Viele Unternehmen lassen Eigenentwicklungen ganz oder teilweise von Externen umsetzen. Das geht gut, solange das interne Team die Qualität beurteilen kann. Fehlt dieses Know-how auf Kundenseite, prüft niemand, ob die Architektur stimmt, ob Clean Core eingehalten wird oder ob die Testabdeckung ausreicht. Was bei der Abnahme durchrutscht, taucht später als Wartungsproblem wieder auf.

Auch umgekehrt gilt: Ein Berater, der selbst keinen Überblick über die aktuellen SAP-Technologien hat, wird keine Anforderungen stellen, die zu Fiori First und Clean Core passen. Wer dieses Risiko klein halten will, braucht eigenes Know-how. Um zu erkennen, was gut ist, und um es einfordern zu können.

KI beschleunigt – in beide Richtungen

KI-gestützte Entwicklungswerkzeuge sind im Alltag angekommen. SAP Joule, GitHub Copilot und ähnliche Tools schlagen Code vor, erklären Codeabschnitte, generieren Testfälle. Für Entwickler, die den aktuellen Technologiestack beherrschen, sind das echte Beschleuniger.

Für Entwickler ohne solide Grundlage gilt leider das Gegenteil. Sie produzieren schneller Code, aber die Qualität wird davon nicht besser. Wer nicht beurteilen kann, ob ein CDS-View korrekt modelliert ist, ob eine RAP-Implementierung sauber aufgebaut ist oder was ein Unit-Test eigentlich leisten soll, bekommt mit KI-Unterstützung vor allem eines: mehr potenzielle technische Schulden in kürzerer Zeit.

Dazu kommt, dass sich KI-Modelle am vorhandenen Code orientieren. Eine schlechte Codebasis führt zu schlechteren Vorschlägen. Clean Code und Unit Testing sind deshalb keine akademischen Konzepte, sondern die Voraussetzung dafür, dass KI-gestützte Entwicklung überhaupt kontrollierbar bleibt. Wer KI als Beschleuniger einsetzen will, braucht gut ausgebildete Entwickler. Anders funktioniert es schlicht nicht.

Was konkret zu tun ist

Das DSAG CIO Paper empfiehlt unter anderem:

  • Rollenspezifische Curricula definieren, denn ABAP-Entwickler, CAP-Entwickler, Integrationsexperten und Business Consultants haben unterschiedliche Lernbedarfe
  • Lernumgebungen bereitstellen, wo keine vorhanden sind – SAP CAL, ABAP Trial und der ABAP Platform Docker Container bieten dafür kostengünstige Optionen
  • Fortbildungszeit verbindlich in die Kapazitätsplanung aufnehmen und nicht als Lückenfüller zwischen Projekten behandeln
  • Schulungen zeitlich an laufende Migrations- oder Modernisierungsprojekte koppeln, damit die Inhalte direkt angewendet werden können

Gerade der letzte Punkt ist mir wichtig. Lernen ohne direkten Anwendungsbezug verblasst schnell. Entwickler müssen das Gelernte sofort einsetzen können. Dafür muss die Schulung stattfinden, bevor die Architekturentscheidungen fallen. Nicht währenddessen und schon gar nicht danach.

Die DSAG-Academy, die SAP und einzelne DSAG-Mitgliedsunternehmen bieten Schulungen und Webinare rund um aktuelle SAP-Entwicklungstechnologie an. Einen guten Referenzrahmen liefern außerdem die DSAG-Leitfäden, etwa der ADT-Leitfaden und der ABAP-Leitfaden.

Das Paper als Werkzeug

Wer im eigenen Unternehmen für Fortbildung kämpft und damit auf taube Ohren stößt, braucht Argumente, die auf Managementebene ankommen. Genau dafür haben wir das DSAG CIO Paper geschrieben: kompakt, belastbar und in der Sprache der Zielgruppe. Es ist über die DSAG verfügbar. Und wem das zu knapp ist, der findet in diesem Artikel die ausführlichere Begründung.

Weitere Artikel