SAP-Projektwissen on demand: KI-Nutzungsversprechen für SAP-Landschaften

Deutschland steht vor einem erheblichen Know-how-Verlust. Nach Berechnungen des Statistischen Bundesamts werden bis 2040 rund 13 Millionen Erwerbspersonen das gesetzliche Rentenalter überschritten haben. Das entspricht 30 Prozent der heutigen Erwerbspersonen. Damit geht auch ein über Jahrzehnte aufgebautes Erfahrungswissen verloren. Deloitte spricht bereits von einem „Knowledge Exodus“.

Einer eigenen Erhebung zufolge erfassen und dokumentieren 92 Prozent der befragten Unternehmen das Wissen ihrer kurz vor dem Ruhestand stehenden Mitarbeiter nicht konsequent. Kritisches Wissen verbleibt deshalb häufig weiterhin in den Köpfen einzelner Experten statt in den Systemen. Gartner sieht ebenfalls ein wachsendes „Expertise Gap“ durch Ruhestände und technologischen Wandel und empfiehlt den Unternehmen, dringend ihren Wissenstransfer als kontinuierlichen Prozess zu organisieren.

Auch für viele über Jahre aufgebaute SAP-Landschaften ist das kritisch, denn auch hier steckt ein Großteil des Know-hows in den Köpfen erfahrener Entwickler und Berater. Zumeist wird diesem Problem mit umfangreichen Dokumentationen und Personalredundanz begegnet, doch das Problem dabei ist der Informationsabruf: Sich erst durch einen Berg an Unterlagen zu kämpfen, nur um ein kleines Programm zu verstehen, ist nicht nur mühsam, sondern auch zeit- und kostenintensiv. Generative KI eröffnet nun die Möglichkeit, einen Teil dieses Erfahrungswissens nicht nur zu dokumentieren, sondern unmittelbar im Entwicklungsprozess verfügbar zu machen.

Wissen hat mehrere Ebenen

Bei KI-gestützter Softwareentwicklung im SAP-Umfeld greifen drei Ebenen ineinander:

Allgemeines Wissen des KI-Modells: Ein Sprachmodell kennt Programmiersprachen, typische Softwarearchitekturen und viele verbreitete Entwicklungsmethoden. Es kann Code erzeugen, erklären oder prüfen und kennt zahlreiche öffentlich dokumentierte Vorgehensweisen. Dieses Wissen ist jedoch allgemein. Das Modell weiß zunächst weder, welche Software ein bestimmtes Unternehmen einsetzt, noch wie dort Prozesse organisiert oder Anwendungen individuell angepasst wurden.

SAP-spezifisches Wissen: Darüber liegt das Wissen über die SAP-Welt. SAP ergänzt generative KI deshalb um eigene Informationen und Funktionen, beispielsweise in Joule for Developers. Damit kann die KI SAP-spezifische Entwicklungsregeln berücksichtigen oder bei einer S/4-Transformation bestehende Eigenentwicklungen analysieren und anpassen. Diese Schicht kennt also die technischen Regeln und Besonderheiten von SAP – aber noch nicht die Besonderheiten einer bestimmten SAP-Installation bei einem Kunden.

Kunden- und Projektwissen: Diese dritte Schicht entsteht erst im jeweiligen Unternehmen. Dazu gehören eigene Definitionen, individuelle Erweiterungen, Schnittstellen, Entwicklungsstandards und Entscheidungen, die in früheren Projekten getroffen wurden. Auch die Frage, warum ein bestimmter Prozess vor Jahren genau so umgesetzt wurde, gehört dazu. Dieses Wissen kann weder SAP noch ein neues, leistungsfähigeres Sprachmodell automatisch kennen, denn es entstammt der konkreten Kunden- und Projekthistorie.

Die dritte Ebene ist für SAP-Anwender besonders bedeutend. Während SAP das allgemeine technologische und fachliche Fundament liefert, erweitern Beratungshäuser wie Abat diese Basis um das Wissen, wie die jeweilige SAP-Landschaft bei einem Kunden konkret eingerichtet ist.

Projektwissen in maschinenlesbarer Form

Der SAP-Dienstleister Abat hat dafür einen eigenen Ansatz entwickelt, bei dem ein Großteil des Entwickler- und Beratungswissens in einer maschinenlesbaren Form abgelegt wird. Das erfolgt mit zwei Wissensebenen: Die erste besteht aus den sogenannten Skills. Dahinter stehen Markdown-Dateien, in denen Entwickler Regeln und Erfahrungen so beschreiben, dass sie vom Development Assistant automatisch berücksichtigt werden können. Dazu gehört fachliches Entwicklungswissen ebenso wie das KI-Verhalten: Fehlen Informationen, soll der Assistent nachfragen, statt eine vermeintlich plausible Antwort zu erfinden. Wissen, das früher über Schulungen, Wikis oder persönliche Weitergabe verbreitet wurde, fließt jetzt unmittelbar in die Entwicklung ein. Neue Erkenntnisse aus den Projekten wiederum werden in die Skills zurückgeführt.

Die zweite Ebene ist eine von Abat selbst betriebene Embedding- bzw. Vektordatenbank. Dort lässt sich umfangreicheres Unternehmens- und Kundenwissen hinterlegen: Dokumentationen, Begriffe, projektspezifische Besonderheiten oder Informationen darüber, wie bestimmte Prozesse konkret ablaufen. Diese Datenbank kann mit unterschiedlichen Sprachmodellen verbunden werden. Damit entsteht eine strategisch wichtige Trennung: Das über viele Jahre aufgebaute Entwicklungs- und Kundenwissen – also eines der wichtigsten Unternehmens-Assets – verbleibt weiterhin im Unternehmen. Trotzdem kann man an der technologischen KI-Entwicklung teilnehmen, denn das darunter befindliche Sprachmodell ist jederzeit austauschbar.

Entwicklungsleitplanken

Besonders greifbar wird der Ansatz bei SAP-spezifischen Regeln. Abat hinterlegt beispielsweise Skills für RAP-Entwicklung, Clean Core oder Hana-kompatibles Coding. Hinzu kommen eigene Standards zu Modularität, Schnittstellen oder Wartbarkeit. Damit verändert sich die Funktion dieser Informationen.

Eine Clean-Core-Vorgabe steht nicht mehr nur in einem Architekturpapier, das ein Entwickler kennen muss. Sie kann als maschinenlesbare Leitplanke unmittelbar in die Code-Erzeugung einfließen. Bei S/4-Conversions können Regeln beispielsweise berücksichtigen, welche älteren Abap-Konstrukte unter Hana problematisch sind. Auch SAP verfolgt diese Richtung weiter. Die Roadmap sieht unter anderem KI-Unterstützung bei Clean-Core-relevanten ATC-Findings sowie agentische Funktionen für Abap vor.

Für die SAP-Anwender ist das besonders interessant, weil neue Entwicklungen fast immer auf bestehende Erweiterungen und kundenspezifische Regeln treffen. Je mehr davon maschinenlesbar vorliegt, desto weniger hängt die Qualität vom spezifischen Wissen des Entwicklers ab.

Maschinenlesbares Wissen ist allerdings nicht automatisch richtiges Wissen. Auch hier gilt: „Garbage in, garbage out.“ Eine veraltete Dokumentation wird vielleicht gelegentlich falsch interpretiert. Eine fehlerhafte maschinenlesbare Regel kommt dagegen bei jeder passenden Aufgabe erneut zur Anwendung und kann schwerwiegende Folgen verursachen.

Umgekehrt muss der Wissensstand auch kontinuierlich erweitert werden. Bei Abat wird Neues von den Entwicklern zunächst ausprobiert, bevor daraus eine allgemeine Regel wird. Erst wenn eine Idee ausgiebig getestet und vom verantwortlichen „Gatekeeper“ freigegeben wurde, erfolgt der zentrale Roll-out. Je stärker also die Entwicklung automatisiert wird, desto wichtiger werden klare Zuständigkeiten und Kompetenzen für Pflege und Freigabe.

Transition zum Wissensproblem

Für die CIOs der SAP-Anwender liegt der Nutzen vor allem in der Kontinuität. Kommen neue Entwickler in ein Projekt, steht ihnen ein Teil dieses Projektwissens über den Development Assistant unmittelbar zur Verfügung. Hinzu kommt ein Unterschied zum klassischen Wissenstransfer: Maschinenlesbares Wissen lässt sich vervielfältigen. Wird eine Regel verbessert oder ein Fehler einmal in der Wissensbasis korrigiert, steht die Änderung allen damit arbeitenden Instanzen zur Verfügung. Ein neuer Mitarbeiter muss dagegen erst eingearbeitet und geschult werden. Gerade in großen SAP-Projekten mit wechselnden Teams kann aus dieser Kopierbarkeit ein erheblicher Vorteil entstehen.

Aber nicht nur Menschen bauen das Wissen über eine vorgegebene SAP-Installation aus, sondern auch die Entwicklungsumgebung selbst. Das erleichtert Übergaben, reduziert die Abhängigkeit von einzelnen Experten und macht einen Teil des bislang personengebundenen Projektwissens dauerhaft verfügbar.

Härtetest im SAP-Bestand

Wie relevant das werden kann, zeigt ein aktuelles Abat-Projekt. Ausgangspunkt ist eine bestehende SAP-Landschaft mit sehr viel Code, den das neue Team nicht selbst geschrieben hat – also eine Situation, wie sie bei vielen SAP-Anwendern Alltag ist. Beim ersten von sieben Arbeitspaketen lag der Aufwand mehr als 50 Prozent unter der ursprünglichen Schätzung.

Während der Arbeit sammelt der Development Assistant zunehmend Kontext über das vorhandene System und verbessert damit das eigene Wissen. Später wurde von diesem System ein Fehler gemeldet. Daraufhin bekam der Entwickler vom Assistenten einen Hinweis, wo er ansetzen soll, und der Fehler konnte schnell behoben werden.

Wissen als strategisches Asset

Mit wachsendem KI-Einsatz wird neben dem Modell der Kontext immer bedeutender. Für die CIOs wird strategisches Wissensmanagement wichtiger: Erfahrungswissen muss so erfasst und gepflegt werden, dass es auch nach Personalwechseln oder Provider-Transitions verfügbar bleibt. Für die SAP-Anwender entsteht damit ein neues Asset. Nicht nur der Code zählt, sondern auch die maschinenlesbare Repräsentation dessen, warum Prozesse, Code und Architektur so aussehen, wie sie aussehen. Aus einer gewachsenen SAP-Landschaft wird ein maschinenlesbares Gedächtnis. Perspektivisch geht der Ansatz weit über Coding hinaus. Abat experimentiert derzeit damit, auch Spezifikationen, Entscheidungen, Protokolle und Glossare einzubinden. Neue Teammitglieder könnten sich den bisherigen Projektverlauf dann gezielt über Fragen erschließen, statt große Mengen historischer Dokumentation zu lesen.

Zum Partnereintrag: