**Robin**, Consultant für GenAI bei Pexon Consulting | 10 Min. Lesezeit | 01.10.2026
TL;DR: SAP KI bidirektional kurz erklärt
SAP KI bidirektional heißt: die KI-Plattform liest aus SAP und schreibt kontrolliert zurück – mit Auth zwischen Azure und ERP und mit Idempotenz gegen Doppelbuchung. Reine RAG-Auskunft reicht nicht, wenn Prozesse im Quellsystem enden sollen. Pexon baut das als Capability der offenen KI-Plattform, parallel zur S/4-Roadmap.
Das Problem: Lesen klappt, Übergabe bremst
In Gesprächen mit Betrieb und Technik hören wir ein wiederkehrendes Muster. Extraktion und Lesen aus SAP gelten als lösbar. Die Sorge sitzt bei der Übergabe: stark individualisierte Prozesse, Alt-ERP-Eigenentwicklungen, mehrere Hersteller-Clouds, Auth zwischen Azure und ERP, Rückschreiben ins Quellsystem.
Dazu kommt der Satz, der Projekte stoppt: hinten dran hängt die SAP-Anbindung, und die dauert Jahre. Wer parallel die S/4-Umstellung plant, schiebt die KI oft weiter nach hinten. Bidirektionalität bleibt trotzdem ein Muss – sonst schließt kein Prozess im System of Record.
Genau diese Lücke ist der Anlass für die Capability unter der offenen KI-Plattform: nicht noch eine Beleg-LP, nicht reine SAP-Beratung, sondern die Plattform-Schicht, die Write-back mit Guardrails trägt.
Warum nur lesen selten reicht
Eine lesende Anbindung liefert Status, Belege und Kontext. Das ist wertvoll für Auskunft und Assistenz. Sobald aber Freigaben, Rückmeldungen oder Buchungsschritte im SAP landen sollen, entsteht eine zweite Wahrheit neben dem ERP – wenn die KI nur spricht und nicht schreibt.
Bidirektionalität heißt nicht: jeder Agent darf alles buchen. Es heißt: freigegebene Schreibpfade existieren, mit Nutzerkontext oder klar begrenztem technischen Kontext, Audit im Quellsystem und einer Schwelle, ab der ein Mensch entscheidet. Ohne diese Grenze wird aus Assistenz schnell Schattenbuchhaltung.
Viele Teams starten mit einem Chat über exportierte Tabellen. Das fühlt sich wie Fortschritt an. Es skaliert aber nicht in den Betrieb, weil Rechte, Aktualität und Schreibverantwortung im ERP fehlen. Der Schritt von „Fragen beantworten“ zu „Vorgang abschließen“ ist der eigentliche Production Gap.
Doppelbuchung: das Risiko, das CFOs zu Recht scheuen
Agenten wiederholen Aufrufe. Netze brechen ab. Retries sind normal. Ohne Idempotenz führt derselbe Geschäftsvorfall zweimal zu einer Buchung oder Statusänderung.
Öffentliche Integrationsleitfäden von SAP beschreiben Exactly-Once als Kombination aus Zustellung und idempotentem Empfang: ein stabiler Schlüssel (Geschäfts-ID oder Message-ID) und Deduplizierung, bevor das Zielsystem erneut verändert wird. Für die KI-Plattform heißt das konkret:
- Jeder Schreibversuch trägt einen Idempotenz-Key.
- Der Connector prüft vor dem SAP-Aufruf, ob der Key schon erfolgreich verarbeitet wurde.
- Kritische Buchungen bleiben Human-in-the-Loop unter einer Konfidenz- oder Freigabeschwelle.
Ohne diese drei Punkte ist Write-back kein Fortschritt, sondern ein Kontrollverlust. Timeouts nach erfolgreicher Buchung sind der klassische Fall: der Client sieht einen Fehler und sendet erneut. Nur ein gespeicherter Key erkennt „schon geschrieben“.
Idempotenz ist keine SAP-Sonderdisziplin. Sie ist Pflicht in jedem asynchronen Agenten-Pfad. Wer sie auf „später im S/4-Projekt“ verschiebt, akzeptiert Doppelbuchung als Feature der Demo-Phase.
Auth Azure ↔ ERP: wer schreibt wirklich?
Viele Demos nutzen einen technischen Lesenutzer. Für Write-back reicht das selten. Audit und Berechtigungen im SAP erwarten den Menschen oder einen klar freigegebenen Kontext.
In Azure-nahen Landschaften heißt das typischerweise: Entra ID bzw. Azure AD und Propagation in den ERP-Kontext, soweit die Landschaft das hergibt. Fehlt die Verdrahtung, schreibt ein generischer Service-Account – und niemand kann später erklären, wer den Vorgang ausgelöst hat.
Mehrere Hersteller-Clouds verschärfen das Bild. Identität endet nicht an der Azure-Grenze, wenn Freigaben in einem anderen Cloud-Produkt starten und im SAP enden. Die Integrationsschicht muss den Principal über den gesamten Pfad tragen oder bewusst einen technischen Kontext mit Vier-Augen-Prinzip dokumentieren. Beides ist zulässig. Nur „irgendein Tech-User“ ist es nicht.
Parallel zur S/4-Umstellung statt danach
Interessenten berichten, dass Dienstleister SAP-Anbindung in Jahren denken und die S/4-Migration mit einplanen. Das ist nachvollziehbar für Modul-Customizing. Für eine schlanke Plattform-Capability gilt etwas anderes:
- Ein Use Case startet auf dem heutigen System.
- Die Schnittstelle wird so geschnitten, dass der Umstieg die Plattform-Schicht nicht neu erfindet.
- Jahre entstehen, wenn KI an das Ende der Transformation gebunden wird – nicht, wenn Scope, Auth und Idempotenz klar sind.
Fachquellen im Mittelstand nennen für klassische SAP-Agent-Anbindungen oft Wochen je klarer Schnittstelle inklusive Sandbox, nicht automatisch Mehrjahresprogramme. Der Unterschied liegt im Scope: ein Schreibobjekt mit Guardrails versus ein Programm „alle alten Eigenentwicklungen und alle Clouds gleichzeitig“.
OData, BAPI und der gekapselte Connector
In der Praxis stehen mehrere technische Wege nebeneinander. Bei S/4HANA ist OData oft der erste Griff für Lesen und Schreiben dokumentierter Objekte. Bei ECC und Sonderfällen bleiben RFC und BAPI relevant. Ein Nachtlauf-Export in eine zweite Datenbank liefert Aktualität von gestern und umgeht Rechte – das ist für Write-back ungeeignet.
Was Teams unterschätzen: Die KI-Schicht sollte diese Wege nicht direkt aus jedem Chat-Produkt heraus ansprechen. Ein Connector hinter dem Gateway der offenen KI-Plattform kapselt OData oder BAPI, setzt Rate-Limits, prüft Idempotenz-Keys und schreibt Protokolle. Mehrere Assistenten nutzen dieselbe Anbindung. Rechte und Audit bleiben an einer Stelle pflegbar.
Eigenentwicklungen ändern daran nichts Grundsätzliches. Sie ändern den Scope. Wenn der Schreibpfad über einen hausinternen Baustein läuft, gehört dieser Baustein in die Aufnahme – nicht in die Hoffnung, ein Standard-Connector erkenne ihn magisch. Genau hier verlieren Projekte Monate: die Schnittstelle ist „Standard“, der Prozess ist es nicht.
Was „Jahre“ wirklich meint
Wenn Interessenten sagen, die SAP-Anbindung dauere Jahre, meinen sie selten den HTTP-Call. Sie meinen:
- Klärung, welche Objekte wirklich geschrieben werden dürfen
- Abgleich mit Eigenentwicklungen und Freigabeworkflows
- Sandbox-Zugang, Testdaten und Abnahme mit Fachbereich
- Parallelität zur S/4-Roadmap und zu anderen Cloud-Herstellern
- Betrieb nach Go-live: Monitoring, Retries, Eskalation
Das ist Projektarbeit. Es ist aber keine Begründung, jeden KI-Use-Case an das Ende der Transformation zu hängen. Ein schlanker Pilot mit einem Schreibpfad, klarer Auth und Idempotenz kann parallel laufen. Jahre entstehen, wenn Scope und Guardrails fehlen – oder wenn die Organisation Write-back bewusst auf „nach S/4“ verschiebt.
Die ehrliche Gegenfrage lautet: Welches eine Objekt wollen Sie in den nächsten Wochen schreiben dürfen – und wer gibt das fachlich frei? Ohne diese Antwort bleibt die Jahre-Narrative unangreifbar.
Architektur-Checkliste vor dem ersten Write-back
Nutzen Sie diese Liste im internen Architektur-Review. Sie ist bewusst technisch und kaufmännisch gemischt:
- Objektliste: Welche SAP-Objekte werden gelesen, welche geschrieben? Was ist ausdrücklich tabu?
- Identität: Welcher Principal steht im Audit? Nutzerpropagation oder freigegebener technischer Kontext mit Vier-Augen-Prinzip?
- Idempotenz: Welcher Schlüssel ist stabil über Retries hinweg? Wo wird Duplikat erkannt – vor dem SAP-Aufruf?
- HITL: Ab welcher Schwelle entscheidet ein Mensch? Wer ist Owner der Warteschlange?
- Fehlerfall: Was passiert bei Timeout nach erfolgreicher Buchung? Wie wird „schon geschrieben“ erkannt?
- Parallel S/4: Bleibt der Connector portierbar, oder ist er an ECC-Sonderlogik geklebt?
- Betrieb 8×5: Wer sieht Alerts? Wer darf den Connector stoppen?
- Abgrenzung Belege: Ist der Use Case wirklich Plattform-Write-back – oder Document Intelligence (Rechnung, Postfach, 3-Way-Match)?
Wenn Punkt 8 Richtung Belege zeigt, gehören Sie auf die Document-Intelligence-Strecke, nicht auf diese Capability. Das ist keine Abwertung, sondern Kannibalisierungsschutz für Suchintention und Delivery.
Entscheidungsmatrix für IT-Leitung
| Frage | Wenn ja | Wenn nein |
|---|---|---|
| Muss ein Prozess im SAP abgeschlossen werden? | Bidirektional planen | Lesende Strecke prüfen |
| Sind Retries im Agenten-Pfad möglich? | Idempotenz-Keys Pflicht | Trotzdem Keys vorsehen |
| Läuft S/4-Umstellung parallel? | Connector portierbar schneiden | Trotzdem Eigenentwicklungen listen |
| Gibt es Sandbox-Zugriff? | Pilot starten | Erst Zugang klären, nicht Architektur fantasieren |
| Ist 24/7 gefordert? | Separates Betriebsmodell | 8×5 reicht oft und ist ehrlich |
Diese Matrix ersetzt kein Scoping. Sie verhindert, dass ein Chat-Pilot als „SAP-Anbindung erledigt“ verkauft wird. Besonders Zeile fünf ist in Mittelstandsprojekten entscheidend: Betrieb 8×5 mit klarer Eskalation ist oft realistischer als ein 24/7-Versprechen ohne On-Call.
Abgrenzung: was diese Story nicht ist
| Thema | Bleibt wo |
|---|---|
| Rechnungskontrolle, FiBu-Postfach, DATEV/SAP-Belege | Document Intelligence / KI-Integration Beleg-LPs |
| S/4 KI-Anbindung allgemein, RAG-Chatbot | bestehende KI-Integration-Spokes |
| SAP on Azure Infra | Cloud-Consulting |
| Diese Story | Offene KI-Plattform ↔ SAP bidirektional |
Die Money-Page bundelt Auth, Write-back, Idempotenz und Betrieb 8×5. Belegautomatisierung und Plattform-Write-back teilen Wörter wie „SAP“ und „KI“, aber nicht denselben Kaufintent. Wer beides mischt, verliert Ranking und Sales-Klarheit.
Was Sie im Plattform-Check mitbringen
- Welcher Schreibpfad ist Pflicht (nicht nur Lesen)?
- Welche Eigenentwicklungen hängen daran?
- Wie stehen Azure/Entra und SAP-Benutzer heute zueinander?
- Läuft S/4 parallel oder ist ECC noch führend?
In 45 Minuten lässt sich klären, ob Bidirektionalität jetzt startbar ist – ohne Fake-Festpreise und ohne 24/7-Versprechen. Betrieb 8×5 reicht, wenn Monitoring und Eskalation klar sind. Preise entstehen nach Scoping des Schreibpfads, nicht aus einer Blog-Zahl.
Production Gap: Demo läuft, Betrieb fehlt
Viele Teams haben eine lesende Demo. Was fehlt: Auth im Nutzerkontext, Idempotenz bei Retries, HITL für kritische Buchungen und ein 8×5-Betriebspfad. Genau diese Lücke adressiert die Capability der offenen KI-Plattform. Der Plattform-Check klärt, ob Ihr Schreibpfad jetzt startbar ist.
Häufig gestellte Fragen
Was heißt SAP KI bidirektional konkret?
Lesen aus SAP und kontrolliertes Zurückschreiben freigegebener Vorgänge, mit Auth und Idempotenz. Nicht: unbegrenzte Agenten-Rechte auf dem Produktivsystem.
Reicht MCP oder ein Chat-Connector?
Ein Protokoll oder Chat-Produkt allein ersetzt weder Principal Propagation noch Exactly-Once. Die Guardrails sitzen in der Integrationsschicht hinter der Plattform.
Was kostet der Einstieg?
Auf der Money-Page stehen bewusst keine Deal-Festpreise. Der Einstieg ist der Plattform-Check und ein gescopter Pilot-Schreibpfad. Endpreis nach Scoping.
Wann lohnt sich Write-back nicht?
Wenn nur gelegentliche Auskunft reicht und kein Prozess im SAP abgeschlossen werden muss. Dann bleibt eine lesende Strecke oft die ehrlichere Lösung.
Kann man parallel zur S/4-Umstellung starten?
Ja, wenn der Connector portierbar geschnitten ist und der erste Schreibpfad auf dem heutigen System freigegeben ist. Die Alternative „erst nach Go-live“ verschiebt den Nutzen ohne das Risiko zu löschen.
