SAP Joule und das Travelling Salesman Problem

Königsberg und der Handlungsreisende

Das Travelling Salesman Problem (TSP) ist eine verallgemeinerte Version des Königsberger Brückenproblems. In allen Fällen geht es um das Finden eines optimalen Weges (Kanten) durch vorhandene Orte (Knoten), wobei es naturgemäß der kürzeste Weg sein soll und kein Ort mehrfach besucht werden darf. Für Königsberg gibt es leider keine Lösung.

Die Stadt Königsberg in Preußen wird in ihrem Stadtgebiet von dem Fluss Pregel sowie zwei Inseln durchzogen. Die beiden Stadthälften waren durch je drei Brücken mit den Inseln verbunden, die untereinander durch eine weitere Brücke verbunden waren (in Summe also sieben Brücken). Die Fragestellung, die es zu erörtern galt, war, ob es eine Möglichkeit gibt, alle sieben Brücken exakt einmal zu überqueren, und falls dies der Fall ist, ob auch ein Rundweg konstruiert werden kann, der die Rückkehr zum Ausgangspunkt ermöglicht. Der Mathematiker Leonhard Euler bewies im Jahr 1736, dass die Realisierung eines solchen Weges in Königsberg nicht möglich war, da zu allen vier Ufergebieten bzw. Inseln (Knoten) eine ungerade Zahl von Brücken (Kanten) führte.

Es wird angenommen, dass maximal zwei Ufer (Knoten) mit einer ungeraden Zahl von angeschlossenen Brücken (Kanten) existieren. Es besteht die Möglichkeit, dass diese beiden Ufer den Ausgangs- bzw. Endpunkt darstellen. Die übrigen Uferabschnitte sind mit einer geraden Anzahl von Brücken zu versehen, um eine erneute Passage auf dem neuen Weg zu ermöglichen. Das Brückenproblem ist kein klassisches geometrisches Problem, da die exakte Lage der Brücken nicht von Relevanz ist, sondern lediglich die Verbindung der Inseln durch die Brücken. Die vorliegende Problematik ist folglich als topologisches Problem zu klassifizieren. Euler gelang es, dieses Problem zu lösen, indem er Methoden anwendete, die gegenwärtig der Graphentheorie zugeordnet werden.

SAP Hana und die Graph Engine

Der Walldorfer Softwarekonzern SAP inszeniert seine künstliche Intelligenz derzeit als allheilendes Wundermittel für das moderne ERP, doch bei genauerer Betrachtung der technischen Plattformen wie SAP Hana und SAP BTP offenbart sich ein hochkomplexes Zusammenspiel aus alten Konzepten und neuen Heilsversprechen rund um die Hana-Datenbankplattform. Im Maschinenraum dieser Architektur verrichtet neben der klassischen SQL-Verarbeitung seit geraumer Zeit die sogenannte SAP Graph Engine ihren Dienst, die Daten nicht in starren Tabellen, sondern als vernetztes Geflecht aus Knoten und Kanten speichert und verarbeitet.

Obwohl die Graphentheorie ein etablierter Zweig der Informatik ist, führte die Hana Graph Engine in der Vergangenheit eher ein Nischendasein und konnte kaum nennenswerte praktische Anwendungsfälle in der Breite der SAP-Bestandskunden vorweisen. Dies ändert sich nun radikal mit dem Aufstieg der SAP Business AI, denn SAP reanimiert diese Technik, um ein fundamentales Problem generativer künstlicher Intelligenz zu lösen: Das gefährliche Halluzinieren von Sprachmodellen, denen schlichtweg das tiefe Verständnis für die hochkomplexen, historisch gewachsenen ERP-Datenbanken fehlt.

SAP Knowledge Graph und SAP Business AI

Als IT-Revolution und semantisches Bindeglied zwischen der Business AI Platform und den eigentlichen ERP-Applikationen wird nun der SAP Knowledge Graph positioniert, der tief in der Hana-Architektur verwurzelt ist. Technisch betrachtet modelliert dieser Wissensgraph die expliziten Beziehungen zwischen Geschäftsdaten, Metadaten und Geschäftsobjekten – wie etwa Kunden, Bestellungen und Rechnungen – und nutzt dafür sogenannte Ontologien, die eine standardisierte Verarbeitung heterogener Informationen in einem formalen Modell definieren und den inhärenten Geschäftskontext abbilden.

Vektoren versus Graphen

Im Gegensatz zu Vektordatenbanken, die primär auf mathematischen Ähnlichkeitssuchen basieren und deren Beziehungen oft implizit bleiben, liefert der Knowledge Graph transparente und interpretierbare Beziehungen, was für eine verlässliche und erklärbare KI im geschäftskritischen Umfeld unabdingbar ist. Durch die Integration von Graph Query Languages wie OpenCypher oder der RDF-Syntax SPARQL ermöglicht SAP zudem eine performante hybride Abfragelogik, bei der traditionelle relationale SQL-Daten nahtlos mit den semantischen Graphenstrukturen kombiniert werden können, ohne dass Daten aufwendig migriert oder dupliziert werden müssen.

Der Knowledge Graph wird von SAP als das semantische Bindeglied zwischen der neuen Business AI Platform und den eigentlichen SAP-Applikationen der sogenannten Autonomous Suite inszeniert. Für den kritischen SAP-Bestandskunden ist es zunächst essenziell zu verstehen, dass dieser Wissensgraph die hochkomplexen, historisch gewachsenen und oft fragmentierten ERP-Daten für künstliche Intelligenz und autonome KI-Agenten überhaupt erst strukturiert lesbar und abrufbar machen soll. Die technische Theorie hinter diesem Konzept besagt, dass der Knowledge Graph Beziehungen zwischen Daten, Metadaten und Geschäftsobjekten explizit modelliert und so eine unverzichtbare semantische Kontextschicht bildet. Ohne dieses tiefe, strukturierte Kontextwissen könnten Sprachmodelle und KI-Agenten zwar nackte Tabellendaten analysieren, aber niemals die geschäftskritische Logik und die Zusammenhänge dahinter begreifen, was im Unternehmensalltag unweigerlich zu gefährlichen und inakzeptablen KI-Halluzinationen führen würde.

Riskante KI-Wette auf die ERP-Zukunft

Betrachtet man das architektonische IT-Konstrukt jedoch durch die kritische Linse eines IT-Entscheiders, entpuppt sich das Narrativ der SAP als riskante Wette auf die Zukunft. Die Deutschsprachige SAP-Anwendergruppe (DSAG), namentlich Fachvorstand Thomas Henzler, legt den Finger präzise in die Wunde und mahnt, dass es für den KI-Assistenten Joule in der Vergangenheit aufgrund der massiv komplexen SAP-Datenbanken oftmals äußerst schwierig war, spezifische Fragen überhaupt korrekt zu beantworten.

Zwar soll der Knowledge Graph laut SAP die manuelle Datenmodellierung künftig drastisch reduzieren und den KI-Modellen den dringend benötigten Geschäftskontext für das sogenannte Grounding liefern, doch die operative Realität sieht derzeit noch völlig anders aus. Unabhängige Analysen zeigen, dass der SAP Knowledge Graph in der viel gepriesenen SAP Business Data Cloud (BDC) aktuell noch gar nicht vollumfänglich zur Verfügung steht, sondern erst für die zweite Jahreshälfte 2026 angekündigt wurde. Bis zu diesem Zeitpunkt agieren die hochgelobten autonomen KI-Agenten faktisch auf einem semantischen Blindflug, da ihnen genau jene essenzielle Kontextschicht fehlt, die Halluzinationen in der SAP-Autonomous-Suite zuverlässig verhindern soll. Zudem erfordert die fehlerfreie Modellierung solcher Graphenstrukturen ein immenses fachliches Know-how und eine makellose Datenqualität, denn ein Wissensgraph, der auf inkonsistenten Stammdaten aufbaut, wird die logischen Fehlentscheidungen der KI lediglich beschleunigen, anstatt sie zu verhindern. Für den SAP-Bestandskunden bedeutet diese Erkenntnis unmissverständlich, dass die technische ERP-Vision einer graphenbasierten KI-Architektur auf SAP Hana zwar akademisch brillant und architektonisch zwingend logisch ist, sie im harten IT-Alltag jedoch erst noch beweisen muss, dass sie mehr ist als nur ein weiteres wolkiges Versprechen auf dem Weg zum autonomen Enterprise.