AI in der SAP-Entwicklung: Warum die Toolwahl nicht am Anfang stehen sollte

Blogartikel | GenAI mit SAP

GenAI kann SAP-Entwicklung und Migration bereits heute beschleunigen. Der Nutzen entsteht jedoch nicht durch die Festlegung auf ein einzelnes Tool. Entscheidend sind eine klar abgegrenzte Aufgabe, kontrollierter Projektkontext und ein Ergebnis, das Entwickler prüfen können.

Welcher KI-Assistent ist der richtige für die SAP-Entwicklung? Diese Frage bindet in vielen Teams viel Aufmerksamkeit, führt aber selten zur besten Projektentscheidung. SAP Joule, Microsoft Copilot, Claude Code und Genie Code haben unterschiedliche Stärken. Entscheidend ist, welche konkrete Aufgabe schneller, nachvollziehbarer oder mit weniger Fehlern erledigt werden soll.

Der Beitrag zeigt, warum Projektkontext wichtiger ist als pauschale Produkturteile, wie GenAI bei Analysen und Migrationen nach SAP Datasphere unterstützt und welche Leitplanken vor einem Pilot geklärt sein müssen.

SAPs GenAI-Angebot wächst – die Projektwirklichkeit bleibt breiter

SAP baut sein GenAI-Angebot rund um Joule, Joule for Developers, Joule Agents und die Business Data Cloud aus. Für definierte Entwicklungsumgebungen entstehen damit konkrete Funktionen, etwa für Codeverständnis, Generierung, Tests und Automatisierung. Die Projektwirklichkeit reicht jedoch meist weiter. Bestehende Repositories, individuelle Namenskonventionen, hybride Landschaften, gewachsene Modellbestände und kundenspezifische Architekturvorgaben passen selten vollständig in den Funktionsumfang eines einzelnen Produkts.

Wer deshalb auf die eine vollständige Lösung wartet, verschiebt nutzbare Produktivitätsgewinne. Wer umgekehrt jedes Problem mit einem neuen Agenten oder einer umfassenden Integration beantworten will, erhöht Kosten, Abstimmungsbedarf und technische Abhängigkeiten. Die bessere Leitfrage lautet: Welches Werkzeug bearbeitet diese Aufgabe mit dem geringsten sinnvollen Integrationsaufwand?

Projektwissen macht aus einem Sprachmodell einen Entwicklungsassistenten

Ein Sprachmodell kennt Syntax und typische Entwicklungsmuster. Es kennt aber nicht automatisch die Domänenlogik eines Datenmodells, die fachliche Bedeutung einer Kennzahl oder die Regeln eines konkreten Projekts. Ohne diesen Kontext kann dieselbe KPI-Frage unterschiedliche Antworten liefern. Auch technisch korrekter Code kann an internen Standards, Architekturvorgaben oder fachlichen Abhängigkeiten vorbeigehen.

Der eigentliche Hebel liegt deshalb in den Informationen, die das Modell kontrolliert nutzen darf: Unternehmenswissen, Projekterfahrung, Beispiele, Dokumentation, Namenskonventionen, Tests und Freigaberegeln. Der Entwickler bleibt im Prozess. Er präzisiert den Auftrag, grenzt Dateien und Systeme ein, prüft Vorschläge und entscheidet über die Übernahme. Das Arbeitsmodell ändert sich – nicht die Verantwortung.

Die BW-zu-Datasphere-Demo zeigt den Nutzen an einem konkreten Modell

Ein Beispiel aus dem entsprechenden Webinar zu dem Thema, welches wir im September 2026 veranstaltet haben, zeigt den Ansatz an einem SAP-BW/4HANA-Datenmodell. Claude Code analysiert das aDSO ZPCS_001, liest dessen Struktur mit 17 Feldern aus und stellt den Datenfluss von der DataSource bis zum aDSO dar. Zusätzlich ermittelt der Assistent 299.236 Zeilen und technische Details. In der vertieften Analyse identifiziert er neun inaktive nachgelagerte Transformationen, keine Process Chain und inaktive ML-Modelle. Solche Abhängigkeiten und „toten Winkel“ kosten bei einer manuellen Bestandsaufnahme viel Zeit.

Im nächsten Schritt werden Beispieldaten exportiert und als Grundlage für Zielobjekte in SAP Datasphere genutzt. Die Demo verbindet damit drei Aufgaben, die sonst häufig getrennt bearbeitet werden: Metadaten analysieren, Zielobjekte vorbereiten und Testdaten erzeugen. Sie zeigt keine autonome Migration. Architekturentscheidungen, fachliche Prüfung und Freigabe bleiben beim Entwickler.

Genau diese Trennung ist für Entscheider relevant: AI beschleunigt klar umrissene Arbeitsschritte. Sie übernimmt nicht die Verantwortung für das Zielbild. Damit lässt sich der Nutzen messen, ohne ein Migrationsprojekt von einer noch unreifen Vollautomatisierung abhängig zu machen.

Vier Aufgaben in SAP Datasphere profitieren schon heute von GenAI

Aus den bisherigen Projekten ergeben sich vier Einsatzfelder, bei denen der Nutzen nicht von einer vollständigen Agentenlandschaft abhängt:

Impact-Analysen: Der Assistent untersucht Abhängigkeiten und macht sichtbar, welche Modelle und nachgelagerten Objekte von einer Änderung betroffen sind.
Massenanlage und Massenänderung: Wiederkehrende Anpassungen an Entwicklungsobjekten lassen sich nach definierten Regeln vorbereiten und anschließend gesammelt prüfen.
Migrationsunterstützung: Metadaten, Datenflüsse und bestehende Artefakte werden analysiert; Zielobjekte, Dokumentation und Tests lassen sich daraus ableiten.
Analyse großer Modellbestände: Der Assistent strukturiert umfangreiche Artefaktbestände und weist auf inaktive, undokumentierte oder unerwartet verknüpfte Objekte hin.

Gemeinsam ist diesen Aufgaben ein klar prüfbares Ergebnis. Genau das macht sie für einen Pilot geeignet. Der Entwickler kann Vorschläge mit dem Bestand vergleichen, Abweichungen erkennen und die Qualität vor der Übernahme bewerten.

MCP ist eine Option – kein Pflichtbaustein für jeden Use Case

MCP kann Sprachmodelle mit Systemen und Werkzeugen verbinden. Das ist sinnvoll, wenn ein wiederkehrender Ablauf direkten, kontrollierten Zugriff benötigt. Es ist aber kein Pflichtbaustein für jede Analyse. Häufig reichen ein leistungsfähiges Sprachmodell und die relevanten Projektinformationen aus, um Abhängigkeiten zu untersuchen, Änderungen vorzubereiten oder Dokumentation zu erzeugen.

Weniger Integration bedeutet in solchen Fällen weniger Betriebsaufwand, geringeren Verbrauch und klarere Datenflüsse. Für eine wiederkehrende Impact-Analyse kann ein definierter Skill genügen. Für den Zugriff auf aktuelle BW-Metadaten kann eine kontrollierte Verbindung sinnvoll sein. Die Architektur folgt der Aufgabe – nicht umgekehrt.

Fünf Fragen, die vor dem Pilot beantwortet sein müssen

Welche Inhalte darf das Modell verarbeiten? Legen Sie fest, ob Quellcode, Metadaten, Dokumente und Beispieldaten genutzt werden dürfen.
Wie eng ist der erlaubte Scope? Begrenzen Sie Systeme, Dateien und Entwicklungsobjekte für jede Aufgabe.
Wer prüft und entscheidet? Änderungen dürfen erst nach fachlicher und technischer Kontrolle übernommen werden.
Wie bleiben Ergebnisse nachvollziehbar? Auftrag, verwendeter Kontext, Vorschläge und Freigaben müssen prüfbar bleiben.
Wie werden Nutzen und Kosten gemessen? Vergleichen Sie Zeit, Fehler, Nacharbeit und Verbrauch mit dem bisherigen Vorgehen.

Eine Demo kann zeigen, dass Projektkontext in die Bearbeitung einfließt, bestehende Beispiele als Orientierung dienen und Änderungen schrittweise geprüft werden. Sie belegt keine automatische fachliche Richtigkeit, keine generelle Freigabe für jeden Quellcode und keinen Ersatz für Architektur, Reviews oder Tests. Diese Grenze sollte Teil des Designs sein – nicht nur ein Hinweis am Ende.

Ein tragfähiger Einstieg beginnt bei der Aufgabe, nicht beim Produkt

Ein sinnvoller Startpunkt ist keine unternehmensweite GenAI-Einführung. Wählen Sie eine Aufgabe, die häufig anfällt, ausreichend dokumentiert ist, ein klar überprüfbares Ergebnis liefert, ein begrenztes Risiko hat und heute messbaren Aufwand verursacht.

Führen Sie diese Aufgabe parallel mit und ohne AI-Unterstützung aus. Erfassen Sie die Zeit für Datenmodellierung, Analyse und Review. Messen Sie außerdem Fehler, Rückfragen und Nacharbeit. Erst wenn der Pilot einen nachweisbaren Zeit- oder Qualitätsgewinn liefert, lohnt sich die Skalierung.

Für die Auswahl genügen drei Schritte:

Den konkreten Zeitfresser und das erwartete Ergebnis benennen.
Projektkontext, Zugriffsrechte und menschliche Kontrollpunkte festlegen.
Nutzen, Verbrauch und Qualität im Vorher-Nachher-Vergleich messen.

Fazit: Pragmatismus beginnt bei der Aufgabe

SAP Joule, Microsoft Copilot, Claude Code und Genie Code haben unterschiedliche Stärken. Keine pauschale Rangfolge ersetzt die Bewertung des konkreten Anwendungsfalls. In einem Projekt kann ein SAP-nahes Feature die schnellste Lösung sein. In einem anderen liefert ein externer Assistent mit kontrolliertem Projektkontext den größeren Nutzen.

GenAI ersetzt keine Data-&-Analytics-Teams. Sie kann diese Teams spürbar entlasten, wenn Aufgabe, Kontext und Kontrolle zusammenpassen. Wer so startet, muss weder auf die perfekte Lösung warten noch eine komplexe Agentenarchitektur vorfinanzieren. Er gewinnt belastbare Erfahrungen – und eine bessere Grundlage für die nächste Investitionsentscheidung.