# KI für SAP S/4HANA on-premise: Antworten aus Ihren Daten, ohne dass etwas das Haus verlässt

> Source: https://netray.co/de/sap-s4hana-ki-on-premise
> Language: de
> Publisher: Netray (netray.co)

Sie können Fragen in natürlicher Sprache an Ihr S/4HANA stellen, ohne Daten an einen externen KI-Dienst zu senden: Ein Open-Weight-Modell läuft auf Ihren eigenen GPUs, liest über freigegebene CDS Views und OData-Services und respektiert Ihre SAP-Berechtigungen. Das ist sinnvoll, wenn Joule oder Ihr Cloud-Vertrag nicht in Frage kommen oder die Fachbereiche mehr als Standardberichte brauchen.

Viele Mittelständler in der Fertigung betreiben S/4HANA bewusst on-premise oder im Private-Cloud-Modell beim Hosting-Partner. Gründe sind Kundenanforderungen aus Automotive, Luftfahrt und Rüstung, Konstruktionsdaten mit Geheimhaltungspflicht oder schlicht die Entscheidung, die Kontrolle über Daten und Release-Zyklen zu behalten. Genau diese Unternehmen stehen jetzt vor der Frage, wie sie von generativer KI profitieren, ohne Stücklisten, Preise und Lieferantenkonditionen an einen US-Anbieter zu schicken.

Gleichzeitig läuft der Druck aus der anderen Richtung: Die Mainstream-Wartung für SAP ECC endet nach aktueller SAP-Aussage 2027, mit optionaler verlängerter Wartung bis 2030. Wer in der Migration steckt, hat selten Kapazität für zusätzliche Projekte. Eine KI-Schicht, die neben dem System läuft und den S/4-Kern nicht anfasst, passt zur Clean-Core-Idee: keine neuen Z-Eingriffe, sondern lesender Zugriff über offizielle Schnittstellen.

Diese Seite beschreibt, wie so eine Architektur aussieht, welche Anwendungsfälle sich im Einkauf, in der Disposition und im Controlling lohnen und wann Sie auf SAPs eigene KI-Funktionen zurückgreifen sollten.

## Die Ausgangslage: viele Daten, wenige schnelle Antworten

Die typische Frage im Werk lautet: Warum ist der Fertigungsauftrag 4711 verspätet, welche Komponente fehlt, und welche Bestellung ist dafür offen? Heute wechselt der Disponent zwischen MD04, ME2N, CO03 und einer Excel-Liste. Die Antwort steht im System, aber sie ist auf viele Transaktionen und Fiori-Apps verteilt.

Berichte aus CO-PA, Bestandsbewertung (MR21, MM60) oder offene Posten sind dagegen gut abgedeckt, aber starr. Jede neue Fragestellung wird zum Ticket an die IT oder zum ABAP-Auftrag. Genau diese Lücke zwischen Standardreport und Einzelfrage schließt eine Frage-Antwort-Schicht über den Daten.

## Anwendungsfälle auf S/4HANA, die sich rechnen

Am besten funktionieren Fälle, in denen die Antwort aus wenigen gut definierten Objekten zusammengesetzt wird und der Nutzer das Ergebnis sofort prüfen kann. Die Anfrage wird in eine Abfrage auf freigegebene Views übersetzt, die Abfrage wird angezeigt, und das Ergebnis erscheint als Tabelle oder Diagramm.

- Einkauf: Welche offenen Bestellpositionen (EKPO/EKET) überschreiten den zugesagten Liefertermin, sortiert nach Lieferant und Umsatzrelevanz?
- Disposition: Welche Fertigungsaufträge sind wegen Materialfehlteilen gefährdet, und welche Zulieferbestellung löst das Problem?
- Controlling: Wie haben sich Abweichungen auf Kostenstellen oder Fertigungsaufträgen gegenüber dem Vormonat entwickelt, und welche Buchungen treiben sie?
- Qualität: Welche Prüflose (QALS) mit Befund sind seit drei Wochen offen, gruppiert nach Lieferant und Material?
- Vertrieb: Welche Kundenaufträge hängen im Liefersperrstatus, und was ist der Grund laut Belegfluss?

## Architektur: Modell im eigenen Haus, Zugriff nur lesend

Das Sprachmodell (Open-Weight, zum Beispiel aus der Llama-, Qwen-, Mistral- oder gpt-oss-Familie) läuft mit vLLM oder Ollama auf GPUs in Ihrem Rechenzentrum oder in Ihrer privaten Cloud in Deutschland. Der Zugriff auf S/4HANA erfolgt über freigegebene CDS Views und OData-Services, nicht über direkte Tabellenzugriffe an der Anwendungsschicht vorbei. Ein technischer Benutzer mit eng gefasstem Rollenkonzept bleibt die Ausnahme: Besser ist, dass die Anfrage im Kontext des fragenden Benutzers läuft, damit Berechtigungsobjekte wie Werk, Einkaufsorganisation oder Buchungskreis greifen.

Standardmäßig ist alles lesend. Schreibende Vorgänge, zum Beispiel das Anlegen einer Bestellanforderung, laufen über BAPIs oder APIs erst nach ausdrücklicher Freigabe durch einen Menschen. Dokumente für Wissensfragen (Arbeitsanweisungen, Lieferantenverträge, Prüfpläne) werden getrennt indexiert und per Retrieval eingebunden, mit Quellenangabe in der Antwort.

- Kein Datenabfluss an externe KI-Dienste, kein Training fremder Modelle mit Ihren Daten
- Abfragen werden angezeigt und protokolliert, Ergebnisse sind nachvollziehbar
- SAP-Berechtigungen des Benutzers bleiben maßgeblich
- Betrieb vollständig isoliert möglich, auch ohne Internetzugang (air-gapped)

## DSGVO, Geheimschutz und Betriebsrat

Weil keine Daten an Dritte übermittelt werden, entfallen Drittlandübermittlungen nach Kapitel V DSGVO und die Diskussion um Schrems II für diese Verarbeitung. Es bleiben die üblichen Pflichten: Verzeichnis der Verarbeitungstätigkeiten, Zweckbindung, Berechtigungskonzept und gegebenenfalls eine Datenschutz-Folgenabschätzung, wenn Personaldaten oder Leistungsdaten berührt werden. Für Kunden mit Exportkontroll- oder Geheimschutzanforderungen ist der lokale Betrieb die Voraussetzung dafür, dass Sie als Betreiber Ihre eigenen Pflichten erfüllen können. Eine Zertifizierung durch uns ist damit nicht gemeint.

Sobald KI-Auswertungen Beschäftigtendaten betreffen können, etwa Leistungsdaten aus Betriebsdatenerfassung oder Zeitwirtschaft, greift die Mitbestimmung nach § 87 Abs. 1 Nr. 6 BetrVG. Wir empfehlen, den Betriebsrat vor dem Pilot einzubinden und die Nutzung auf Sachdaten wie Material, Aufträge und Lieferanten zu begrenzen.

## So starten Sie: Assessment, dann ein enger Pilot

Ein sinnvoller Start ist ein Assessment über zwei bis drei Wochen: Welche Fragen stellen Disposition, Einkauf und Controlling wirklich, welche CDS Views und OData-Services existieren bereits, wo liegen die Daten, und welche GPU-Kapazität steht zur Verfügung. Daraus entsteht ein Pilot mit einem Fachbereich und zehn bis zwanzig realen Fragen, die vorab als Testfälle festgelegt werden.

Gemessen wird, ob die Antworten korrekt sind und ob die Fachanwender das Werkzeug tatsächlich nutzen. Erst danach lohnt sich die Ausweitung auf weitere Bereiche. ERPray setzt auf diese Weise auf SAP-Daten auf; für individuelle Agenten oder private RAG-Lösungen bauen wir eine Lösung nach Maß.

## Ehrliche Abgrenzung: wann SAP Joule oder Standard genügt

Wenn Sie ohnehin in der SAP-Cloud sind, die Datenfreigabe für SAPs KI-Dienste datenschutzrechtlich geklärt ist und Ihre Fragen innerhalb der von Joule unterstützten Szenarien liegen, ist SAPs eigener Weg einfacher. Auch für reine Standardkennzahlen genügen Fiori-Apps und Analytics oft. Eine eigene lokale Schicht lohnt sich vor allem bei strengen Datenanforderungen, bei Fragen quer über mehrere Systeme (S/4HANA, MES, Dokumente) und bei Bedarf an angepassten Modellen.

Rechnen Sie außerdem ehrlich mit dem Aufwand: GPU-Hardware, Betrieb und Pflege der Modelle sind zusätzliche Aufgaben. Bei sehr geringem Fragevolumen kann eine gehostete Variante im EU-Rechenzentrum der pragmatischere Kompromiss sein.

## FAQ

### Muss ich dafür S/4HANA anpassen oder Z-Programme schreiben?

In der Regel nein. Der Zugriff erfolgt lesend über vorhandene CDS Views und OData-Services. Fehlt eine Sicht, kann sie im Rahmen von Clean Core als standardnahe CDS-Erweiterung ergänzt werden, ohne den Kern zu verändern.

### Bleiben die SAP-Berechtigungen erhalten?

Ja, wenn die Abfrage im Kontext des fragenden Benutzers ausgeführt wird. Dann gelten Berechtigungsobjekte für Werk, Buchungskreis und Einkaufsorganisation wie in Fiori. Ein technischer Sammelbenutzer wäre dagegen ein Berechtigungsrisiko und sollte vermieden werden.

### Welche Hardware brauche ich für ein lokales Modell?

Das hängt von Modellgröße und Nutzerzahl ab. Für Pilot und kleine Teams reichen oft ein bis zwei Server-GPUs mit ausreichend Speicher. Wir dimensionieren das im Assessment anhand Ihrer tatsächlichen Anfragen, statt pauschale Zahlen zu nennen.

### Kann die KI auch Bestellungen oder Buchungen anlegen?

Technisch ja, über BAPIs oder APIs. Standardmäßig ist das aber ausgeschaltet. Schreibende Aktionen sollten nur nach ausdrücklicher Bestätigung durch einen Menschen und mit vollständiger Protokollierung erfolgen.

### Ist das auch während der ECC-zu-S/4-Migration sinnvoll?

Ja, die Schicht ist ERP-agnostisch aufgebaut. Sie kann Fragen auch auf dem alten ECC beantworten und später auf S/4HANA umgestellt werden. Planen Sie dennoch genug Zeit ein, die Datenmodelle beider Systeme zu mappen.