Clean Core beginnt im Code: Wo KI bei der SAP-Modernisierung an Grenzen stößt

Historisch gewachsener Custom Code stellt viele Unternehmen bei ihrer SAP-Transformation vor große Herausforderungen. smartShift-Gründer Stefan Hetges erklärt im Interview, warum KI alleine nicht „einfach so“ den Custom Code automatisiert umschreiben kann – und weshalb das im Code enthaltene Design der eigentliche Schatz eines Unternehmens ist.

Redaktion: Stefan, derzeit gibt es einen enormen Hype um KI in der Softwareentwicklung. Viele Anbieter versprechen SAP-Kunden, dass KI ihren gesamten Custom Code einfach neu schreiben könne. Wie bewertest du diese Entwicklung?

Stefan Hetges: Auf dem Papier klingt dieses Versprechen natürlich sehr elegant. Für CIOs, die unter Budget- und Zeitdruck stehen, ist der Reiz offensichtlich. Aber für alle, die schon früher erlebt haben, wie Code-Neuschreibungen scheitern können, ist das eine bekannte Szene. Vor über zwanzig Jahren entschied Netscape, den bestehenden Code vollständig zu verwerfen und von Grund auf neu zu schreiben. Das Ergebnis: Während der jahrelangen Neuentwicklung verlor Netscape entscheidende Marktanteile an die Konkurrenz.

Die bittere Erkenntnis daraus lautet: Auch scheinbar veralteter Code enthält hart erarbeitetes Wissen über Sonderfälle und Ausnahmen. Dieses Wissen geht verloren, wenn man komplett neu beginnt. Wenn wir Jahrzehnte an getestetem, praxiserprobtem SAP-Code einfach neu schreiben lassen, ist das meist der teuerste Weg – nur als Abkürzung getarnt. KI ist ein brillanter Baumeister, aber sie braucht nach wie vor einen Architekten.

KI erkennt nicht das „Warum“ hinter Custom Code

Redaktion: Das Argument vieler KI-Anbieter lautet: Die KI kann doch einfach den Quellcode lesen, daraus das Design ableiten und anschließend eine moderne Implementierung erzeugen, die sich genauso verhält. Warum funktioniert das in der Praxis nicht?

Stefan Hetges: Weil Quellcode nur die Implementierung zeigt, nicht aber die Absicht dahinter. Eine Codezeile, die nach einem bestimmten Regionscode filtert, kann eine bewusste regulatorische Anforderung abbilden – oder ein Workaround für einen längst behobenen Fehler sein.

Für die KI sieht beides zunächst gleich aus, weil ihr der Kontext fehlt. Das Design eines Geschäftsprozesses entsteht in Abwägungen und Kompromissen, die Menschen gemeinsam durchdacht haben. Wenn KI versucht, das Design allein aus dem Code abzuleiten, rekonstruiert sie lediglich das Ergebnis, ohne das „Warum“ dahinter zu kennen.

Redaktion: Was passiert, wenn man eine KI trotzdem auf Millionen Zeilen SAP-Code loslässt, ohne ihr diesen Kontext zu geben?

Stefan Hetges: Dann beginnt sie, unter Unsicherheit plausibel zu spekulieren – oder zu halluzinieren. KI ist im Kern eine hochentwickelte Mustererkennungsmaschine mit beeindruckender Sprachfähigkeit, der es aber an echtem Urteilsvermögen fehlt. Allgemeine Studien zeigen bei kommerziellen Sprachmodellen Halluzinationsraten von 15 bis 52 Prozent.

Selbst wenn man durch den Einsatz der besten Tools und guter Prompts eine Best-in-Class-Fehlerquote von nur 15 Prozent annimmt und diese auf eine SAP-Codebasis mit Millionen von Zeilen skaliert, entstehen daraus Tausende falscher Annahmen, die unbemerkt in den neuen Code einfließen können. Solche Fehler fallen nicht in der Demo auf, sondern erst beim Abschluss. Blindes KI-Vertrauen lässt sich in der komplexen SAP-Entwicklung schlicht nicht sauber skalieren.

Die Prozesslogik bewahren, die den Wettbewerbsvorteil bringt

Redaktion: Wie lässt sich dieses Problem umgehen?

Stefan Hetges: Wir verfolgen hierzu einen Ansatz, der aus zwei aufeinander aufbauenden Schritten besteht. Zunächst analysiert eine regelbasierte Engine die gesamte Custom-Codebasis. Um es für Nicht-Techniker zu umschreiben: Wir digitalisieren den Code, damit wir maschinell damit arbeiten können. Wir nennen das Metamodell. Das ist präzise Ingenieursarbeit. Bei der technischen Modernisierung sind Regeln jedem Sprachmodell überlegen. Sie erledigen diese Aufgaben mit 99,99 Prozent Präzision.

Erst im zweiten Schritt kommt KI dort zum Einsatz, wo sie tatsächlich Mehrwert schafft: bei funktionalen Neugestaltungen. Dabei lassen wir die KI nicht rohen Code zurückentwickeln, sondern geben ihr genau den relevanten Ausschnitt des Metamodells. Das ist der Unterschied zwischen einem Modell, das sich seinen Kontext zusammenhalluziniert, und einem Modell, das auf Basis eines strukturierten Kontexts logisch schlussfolgert.

Redaktion: Welche Fragen sollten Unternehmen Deiner Meinung nach stellen, bevor sie ihre Codebasis einem „KI-gestützten“ Transformationsangebot anvertrauen?

Stefan Hetges: Aus meiner Sicht gibt es drei zentrale Fragen. Erstens: Welches Design erhält die KI als Arbeitsgrundlage – oder wird erwartet, dass sie dieses Design selbst erfindet? Zweitens: Was passiert, wenn die KI falsch liegt? Und drittens: Besitzen wir am Ende dieses Prozesses noch die Logik, die unser Unternehmen wettbewerbsfähig gemacht hat? Das Ziel muss sein, bei SAP S/4HANA anzukommen, ohne den eigenen Wettbewerbsvorteil auf dem Weg dorthin zu verlieren.

Anzeige

Whitepaper: Clean Core beginnt im Code

Historisch gewachsener Custom Code gehört zu fast jeder SAP-Landschaft – bleibt in vielen Transformationsprojekten jedoch ein blinder Fleck. Ein gemeinsames Whitepaper von smartShift und dem IT-OnlineMagazin zeigt auf, wie Unternehmen ihre Codebasis analysieren, technische Schulden reduzieren und eine langfristig upgradefähige SAP-Architektur schaffen können.

Jetzt anfordern