Cloud RAG & Wissensmanagement

Retrieval-Augmented Generation für SAP: Unternehmenssuche der nächsten Generation

SAP RAG verbindet die strukturierten Daten aus SAP mit den Dokumenten rund um Ihre Geschäftsprozesse und macht beides in natürlicher Sprache abfragbar. Statt Berichte zu bauen oder Transaktionen zu kennen, fragen Mitarbeitende etwa „Welche offenen Bestellungen beim Lieferanten X sind überfällig?“ und erhalten eine Antwort mit Verweis auf die zugrunde liegenden Belege.

Daniel Gnann · 13. März 2026 · aktualisiert 30. September 2026 · 5 Min. Lesezeit

Warum SAP-Wissen so schwer zu finden ist

SAP-Systeme bilden die Kernprozesse vieler Unternehmen ab – Einkauf, Vertrieb, Materialwirtschaft, Finanzen, Instandhaltung. Das Wissen darin ist jedoch schwer zugänglich:

Verteilte Datenmodelle: Informationen zu einem Vorgang liegen in vielen Tabellen, verknüpft über Schlüssel, die nur Fachleute kennen.
Transaktionen und Berichte: Wer nicht weiß, welche Transaktion oder welcher Bericht die Antwort liefert, fragt die Key-User oder das Controlling.
Kontext außerhalb von SAP: Verträge, Lieferantenkorrespondenz, Prüfberichte oder Wartungsanleitungen liegen im DMS, in SharePoint oder in E-Mails – die Verbindung zum SAP-Beleg fehlt.

Eine Unternehmenssuche der nächsten Generation führt beides zusammen: strukturierte SAP-Daten und unstrukturierte Dokumente.

SAP RAG: Wie die Architektur aufgebaut ist

Ein SAP-RAG-System besteht typischerweise aus vier Schichten:

Datenanbindung an SAP und Dokumentquellen
Aufbereitung in suchbare Einheiten mit Metadaten
Retrieval über Vektor-, Keyword- und strukturierte Abfragen
Generierung der Antwort durch ein Sprachmodell mit Quellenangabe

Schicht 1: SAP-Daten anbinden – OData statt Direktzugriff

Für die Anbindung an S/4HANA setzt SAP heute klar auf OData-Services und API-Zugriff auf CDS-Views. Diese Schnittstellen sind dokumentiert, berücksichtigen das SAP-Berechtigungskonzept und sind zukunftssicher.

Ältere Wege sollten Sie kritisch prüfen (Stand: September 2026):

SAP schränkt die RFC-basierte Nutzung der ODP-Replikationsschnittstelle durch Drittanwendungen ein (SAP-Hinweis 3255746). Als Alternativen nennt SAP unter anderem ODP über OData und die SAP Business Data Cloud.
Die bislang verbreitete Python-Bibliothek PyRFC wird von SAP nicht mehr gepflegt; das Repository wurde archiviert.

Für Änderungen genügt meist ein inkrementeller Abgleich (Delta), etwa über Änderungszeitstempel oder Delta-fähige CDS-Views. So bleibt die Last auf dem SAP-System gering.

Schicht 2: Daten in sprechende Einheiten übersetzen

Rohe Tabellenzeilen eignen sich schlecht für die semantische Suche. Besser ist es, aus den Daten sprechende Textbausteine zu erzeugen, zum Beispiel pro Bestellung:

„Bestellung 4500012345 vom 03.02.2026 an Lieferant Muster GmbH, Material Dichtungssatz DN50, 200 Stück, Liefertermin 28.02.2026, Wareneingang offen, Einkäufergruppe 010.“

Solche Einheiten tragen Metadaten wie Buchungskreis, Werk, Einkaufsorganisation und Belegart. Die Metadaten dienen später als Filter und für die Rechteprüfung. Mehr zur Aufbereitung im Beitrag Chunking-Strategien für RAG.

Schicht 3: Hybrides Retrieval für SAP-Daten

SAP-Fragen sind häufig eine Mischung aus Semantik und Präzision. Daher braucht es mehrere Suchwege:

Fragetyp	Beispiel	Geeignetes Verfahren
Semantisch	„Welche Lieferanten hatten zuletzt Qualitätsprobleme?“	Vektorsuche über Prüfberichte und Reklamationen
Exakt	„Status von Bestellung 4500012345?“	Keyword- oder direkte API-Abfrage
Aggregiert	„Top-5-Kostenstellen nach Ausgaben im Quartal“	Strukturierte Abfrage über freigegebene CDS-Views
Kombiniert	„Welche Verträge laufen aus und wie hoch war das Volumen?“	Dokumentsuche plus strukturierte Abfrage

Für Kennzahlen sollte das System nicht aus Textfragmenten rechnen. Aggregationen gehören in eine strukturierte Abfrage, deren Ergebnis das Sprachmodell nur noch formuliert. Das reduziert Fehler erheblich – siehe auch Halluzinationen in Enterprise-RAG vermeiden.

Schicht 4: Antwort mit Quelle und Belegnummer

Jede Antwort verweist auf Belegnummern, Dokumente oder Berichte. Nutzer können so direkt in SAP oder im DMS nachprüfen.

Berechtigungen: die wichtigste Designentscheidung

Ein SAP-RAG-System darf niemandem mehr zeigen, als er in SAP selbst sehen dürfte. Praktikable Ansätze:

Zugriff im Benutzerkontext: Abfragen laufen über OData mit der Identität des Nutzers (Single Sign-on). Das SAP-Berechtigungskonzept greift automatisch.
Rechte als Metadaten: Für vorindizierte Inhalte werden Organisationseinheiten wie Buchungskreis oder Werk gespeichert und bei jeder Suche gegen die Rollen des Nutzers gefiltert.
Sensible Bereiche ausklammern: Personaldaten oder Konditionen werden nur einbezogen, wenn Fachbereich und Datenschutz das ausdrücklich freigeben.

SAP-eigene KI oder unabhängiger RAG-Stack?

SAP bietet mit Joule, dem Generative AI Hub auf SAP BTP und der Vektor-Engine in SAP HANA Cloud eigene Bausteine für KI auf SAP-Daten. Das ist naheliegend, wenn Sie ohnehin stark auf BTP setzen und überwiegend SAP-Daten erschließen wollen.

Ein unabhängiger RAG-Stack ist sinnvoll, wenn:

SAP-Daten mit vielen Nicht-SAP-Quellen (DMS, SharePoint, Fileserver) zusammengeführt werden sollen,
das Sprachmodell unter eigener Kontrolle in Deutschland laufen soll,
Sie Modellwahl und Kosten unabhängig von einer Plattform steuern möchten.

Mit Secure Cloud RAG und einem lokal betriebenen LLM mit Secure Gateway bleiben Daten und Anfragen im rein lokalen Betrieb in Rechenzentren in Bayern und Sachsen; eine Übermittlung an US-Anbieter ist dafür nicht erforderlich.

Anwendungsfälle für deutsche Unternehmen

Einkauf: „Welche Lieferanten hatten in den letzten sechs Monaten verspätete Lieferungen, und was steht in den Rahmenverträgen zu Verzugsregelungen?“
Vertrieb: „Welche Konditionen gelten für Kunde Y, und gibt es offene Reklamationen?“
Controlling: „Welche Kostenstellen liegen im laufenden Quartal über Plan?“
Materialwirtschaft: „Welche Artikel unterschreiten den Sicherheitsbestand, und welche Bestellungen sind unterwegs?“
Instandhaltung: „Welche Störmeldungen gab es an Anlage Z, und was sagt das Wartungshandbuch dazu?“

Vorgehen: vom Pilot zum Rollout

Als Richtwert lässt sich ein fokussierter Pilot in einigen Wochen bis wenigen Monaten umsetzen – abhängig von Datenlage, Schnittstellen und Freigaben:

Analyse: Anwendungsfälle priorisieren, Datenquellen und Schnittstellen klären, Datenschutz und Betriebsrat einbinden.
Anbindung: OData-Services beziehungsweise CDS-Views bereitstellen, Delta-Abgleich einrichten, Dokumentquellen anbinden.
Aufbereitung und Retrieval: Textbausteine, Metadaten, Embeddings, hybride Suche, strukturierte Abfragen.
Test: Testset mit echten Fachfragen, Rechteprüfung, Last auf dem SAP-System beobachten.
Rollout: Schulung der Key-User, Feedbackschleife, schrittweise Erweiterung.

Für die fachliche Priorisierung und das Prozessdesign unterstützt Sie unsere Schwestermarke VerdaGen.ai.

Häufige Fragen

Wie werden SAP-Daten an ein RAG-System angebunden?

Für S/4HANA empfiehlt sich der Zugriff über OData-Services und freigegebene CDS-Views. Diese Schnittstellen berücksichtigen das SAP-Berechtigungskonzept und sind von SAP für die Zukunft vorgesehen. Änderungen werden inkrementell übernommen, um das SAP-System zu entlasten.

Sieht jeder Nutzer alle SAP-Daten?

Nein, das sollte ein SAP-RAG-System verhindern. Abfragen laufen im Benutzerkontext oder werden über gespeicherte Organisationsmerkmale gegen die Rollen des Nutzers gefiltert. So erhält jeder nur Antworten auf Basis der Daten, die er auch in SAP sehen darf.

Kann ein RAG-System SAP-Kennzahlen berechnen?

Kennzahlen sollten über strukturierte Abfragen ermittelt werden, nicht durch das Sprachmodell selbst. Das Modell formuliert das Ergebnis verständlich und nennt die Quelle. So bleiben Summen und Rankings nachvollziehbar.

Brauche ich SAP BTP für KI auf SAP-Daten?

Nicht zwingend. SAP bietet mit BTP, Joule und der HANA-Vektor-Engine eigene Bausteine. Ein unabhängiger RAG-Stack ist eine Alternative, wenn Sie SAP- und Nicht-SAP-Quellen zusammenführen oder das Sprachmodell unter eigener Kontrolle in Deutschland betreiben möchten.