SAP, Oracle & NetSuite: Wie Enterprise-ERP-Agenten Workflows übernehmen

SAP, Oracle und NetSuite stecken KI-Agenten direkt ins ERP-Datenmodell. Das klingt nach Versprechen. Es ist aber auch ein Eingeständnis: Klassische Workflow-Engines stoßen an ihre Grenzen – und die Hersteller wissen das genau.

Der Bruch mit der alten Workflow-Logik

Klartext: Was SAP, Oracle und NetSuite gerade ankündigen, ist keine schrittweise Verbesserung. Es ist ein Paradigmenwechsel. Jahrzehntelang hat Enterprise-ERP auf regelbasierte Prozessmodelle gesetzt – BPMN-Diagramme, SuiteFlow-Konfigurationen, ABAP-Workflows. Jeder Schritt musste hart kodiert werden. Das war teuer, starr und überforderte IT-Teams regelmäßig.

Agentische Workflows lösen sich von dieser Logik. Ein Ziel wird vorgegeben – etwa „diese Rechnung freigeben oder eskalieren“ – und ein KI-Agent entscheidet selbstständig, welche Datenquellen er anzapft, welche Regeln er anwendet und welche Aktionen er im ERP ausführt. Das ist strukturell anders als ein Trigger-Condition-Action-Regel, auch wenn das auf den ersten Blick ähnlich klingt.

Meine Einschätzung: Viele IT-Verantwortliche unterschätzen genau diesen Unterschied. Sie behandeln KI-Agenten wie smartere RPA-Bots. Das führt regelmäßig zu Governance-Problemen – und zu enttäuschten Erwartungen, wenn der Agent plötzlich Dinge tut, die niemand explizit konfiguriert hat. Genau deshalb ist das Thema Architecture-First und nicht Feature-First zu denken.

Oracle Fusion: Native Agenten als Wettbewerbsstrategie

Oracle ist aktuell am weitesten. Im März 2026 hat Oracle die „Fusion Agentic Applications“ vorgestellt – Agenten, die nativ in Oracle Fusion Cloud integriert sind und direkt auf Fusion-Daten und unternehmensweiten Policies arbeiten. Der Anbieter nennt sie explizit „outcome-driven, proaktiv und reasoning-basiert“. Das Versprechen: Entscheidungen werden nicht mehr vorgeschlagen, sondern im Rahmen definierter Grenzen direkt ausgeführt.

Die technische Architektur dahinter ist bemerkenswert: Oracle setzt auf eine sogenannte „swarm-based Agentic AI Architecture“, die auf dem Model Context Protocol (MCP) aufbaut. MCP standardisiert, wie LLM-Modelle auf externe Datenquellen und Tools zugreifen. Für Enterprise-Umgebungen bedeutet das: Mehrere spezialisierte Agenten koordinieren sich, ohne dass jeder einzelne Integrationsschritt manuell definiert werden muss. Oracle beschreibt diese Architektur im eigenen KI-Blog mit konkreten Anwendungsbeispielen für Enterprise-Workflows.

Was das in der Praxis bedeutet: Ein Finanzabschluss-Agent prüft offene Posten, generiert Abstimmungsvorschläge, eskaliert Ausnahmen und postet konforme Journalbuchungen – alles innerhalb der bestehenden Fusion-Berechtigungsstruktur und mit lückenlosem Audit-Trail. Kein Middleware-Basteln, kein separater Automatisierungsservice. Das ist der strategische Vorteil nativer Integration.

NetSuite: Offizielles KI-Commitment mit Lücken beim Reifegrad

NetSuite, ebenfalls Oracle-Produkt, geht einen etwas anderen Weg. Die Plattform integriert KI-Funktionen wie Forecasting, Anomalie-Erkennung und Textgenerierung nativ in die Cloud-ERP-Suite. NetSuites eigene Definition agentischer KI beschreibt Agenten, die komplexe Prozesse – etwa einen kompletten Sales-Zyklus mit Rabattprüfung, Legal Review und Fulfillment – automatisiert durchlaufen, ohne dass jeder Schritt hart kodiert sein muss.

Die Realität sieht aber so aus: Für viele Anwendungsfälle entsteht der agentische Layer heute noch um NetSuite herum, nicht in ihm. Externe Agenten binden sich über SuiteScript, SuiteTalk und REST-APIs an das ERP an, lesen Stammdaten und Transaktionen, treffen Entscheidungen und schreiben Ergebnisse zurück. NetSuite bleibt dabei konsequent das System of Record – alle Buchungen, alle Statusänderungen, alle Freigaben landen im originären ERP-Datenmodell.

Typische Pilotfälle, die Unternehmen in NetSuite-Projekten heute angehen: AP-Automatisierung, Financial Close und Reconciliation, FP&A-Szenarien sowie Collections-Management. Die offizielle NetSuite-KI-Produktseite zeigt, welche dieser Funktionen bereits als native Features ausgeliefert werden – und was noch über externe Layer läuft.

Schluss damit, das zu ignorieren: Die Grenze zwischen nativem Feature und externem Agent-Layer ist in Cloud-ERP-Systemen wie NetSuite oft unscharf. Hersteller-Marketing suggeriert manchmal mehr native Integration, als tatsächlich vorhanden ist. IT-Entscheider sollten vor jedem Projekt exakt klären, ob eine Funktion echtes ERP-native oder ein vorgelagerter Automatisierungsservice ist.

SAP: Business AI statt Agenten-Branding

SAP spricht offiziell nicht von „Agentic Applications“ wie Oracle. Das SAP-Messaging fokussiert auf SAP Business AI und auf Erweiterungen über die SAP Business Technology Platform (BTP). In S/4HANA Cloud sind KI-Funktionen eingebettet – Vorschläge, Forecasts, automatisierte Kategorisierungen – aber der Begriff „agentische Workflows“ taucht in SAPs Hauptkommunikation deutlich seltener auf als bei Oracle.

In der Praxis sieht die Umsetzung agentischer Cloud-ERP-Automatisierung mit SAP häufig so aus: Ein externer Agent-Service agiert über REST- oder OData-APIs als technischer User mit klar definierten SAP-Rollen. Der Agent liest Bestellungen und Rechnungen, führt Matching durch, routet Freigaben und postet Buchungen direkt ins Hauptbuch. SAP bleibt das führende System – Audit-Trail, Berechtigungen und SOX-Kontrollen bleiben vollständig erhalten.

Was das heißt: SAP-Kunden, die heute agentische Workflows wollen, bauen diese meist als Side-by-Side-Erweiterung auf BTP oder setzen auf Drittanbieter-Agenten, die über Standard-APIs angebunden sind. Das ist technisch solide, erfordert aber mehr Architekturarbeit als Oracles natives Modell. Die harte Wahrheit: Wer SAP einsetzt und auf agentische Automatisierung wartet, die genauso nahtlos wie Fusion Agentic Applications kommt, wartet möglicherweise noch eine Weile.

Governance: Der Punkt, an dem die meisten Projekte scheitern

Seien wir ehrlich: Die meisten Enterprise-ERP-Agenten-Projekte haben kein KI-Problem. Sie haben ein Governance-Problem. Agenten, die direkt im ERP buchen, freigeben oder eskalieren, brauchen exakt definierte Berechtigungsgrenzen – und zwar technisch erzwungen, nicht nur dokumentiert.

Best Practices aus laufenden Projekten zeigen ein klares Muster. Erstens: Agenten erhalten dedizierte technische User-Rollen mit minimalen Berechtigungen. Kein Generalzugang, kein Admin-Profil. Zweitens: Jede Agenten-Aktion hinterlässt einen Audit-Trail – in Oracle- und NetSuite-Projekten oft mit explizitem Zeitstempel und Agenten-Kennung wie „Automated by AI Agent“. Drittens: Der Einstieg läuft über einen Vorschlagsmodus. Der Agent empfiehlt, ein Mensch genehmigt. Erst wenn Präzision und Zuverlässigkeit nachgewiesen sind, schaltet man auf autonomes Posting unter definierten Schwellenwerten um.

Das ist kein Umweg. Das ist die einzige Art, wie agentische Workflows in Finance-nahen Prozessen langfristig akzeptiert werden. Compliance-Teams, interne Revision und externe Prüfer müssen jeden Agenten-Entscheid nachvollziehen können. Wer das nicht von Anfang an einplant, baut auf Sand.

Datenstrategie: Die unsichtbare Voraussetzung für funktionierende ERP-Agenten

Governance ist sichtbar. Datenstrategie ist es oft nicht – bis ein Agent fehlerhafte Entscheidungen trifft, weil er auf schlechten Stammdaten arbeitet. Das ist kein Randproblem. Es ist einer der häufigsten Gründe, warum Piloten nicht die versprochenen Ergebnisse liefern.

Ein KI-Agent im Beschaffungsprozess, der Lieferantenrechnungen automatisch matched und postet, ist nur so gut wie die Stammdatenqualität im Lieferantenstamm. Doppelte Kreditorenkonten, inkonsistente Steuerkennzeichen, veraltete Zahlungsbedingungen – all das produziert Ausnahmen, die der Agent eskalieren muss. Im besten Fall erhöht das den manuellen Aufwand statt ihn zu reduzieren. Im schlechtesten Fall postet der Agent fehlerhafte Buchungen, die erst in der Revision auffallen.

Die Konsequenz für die Projektplanung ist klar: Bevor ein Enterprise-ERP-Agent in Produktion geht, muss eine ehrliche Bestandsaufnahme der Stammdatenqualität stehen. Das bedeutet konkret: Lieferanten- und Kundenstammdaten bereinigen, Duplikate zusammenführen, Pflichtfelder konsequent befüllen und ein kontinuierliches Datenqualitäts-Monitoring einrichten. Wer diesen Schritt überspringt, verschiebt das Problem nur. KI in ERP-Systemen verstärkt bestehende Datenprobleme, löst sie nicht automatisch.

Ein weiterer Aspekt, der in Projekten zu wenig Aufmerksamkeit bekommt: die Qualität historischer Transaktionsdaten. Viele Agenten, insbesondere solche mit lernfähigen Komponenten, werden auf historischen Prozessdaten trainiert oder kalibriert. Wenn diese Daten inkonsistente Genehmigungsmuster, manuelle Korrekturen ohne Dokumentation oder unvollständige Buchungskreise enthalten, übernimmt der Agent diese Muster. Das Ergebnis sind Automatisierungen, die Fehler der Vergangenheit reproduzieren – nur schneller und in größerem Volumen.

Migration von alten Workflow-Engines: Kein Big-Bang-Ansatz

Was passiert mit bestehenden SuiteFlow-Konfigurationen, ABAP-Workflows oder RPA-Automationen? Niemand schmeißt funktionierende Prozesse einfach raus. Die Realität in Enterprise-ERP-Projekten ist: Agentische Workflows ergänzen zunächst, sie ersetzen nicht sofort.

Das typische Migrationsmuster läuft in drei Phasen ab. In Phase eins läuft der KI-Agent parallel zum bestehenden Workflow – Shadow-Mode. Er analysiert die gleichen Transaktionen, trifft Entscheidungen, ohne sie auszuführen, und die Ergebnisse werden gegen den laufenden Prozess validiert. Phase zwei schaltet den Agenten für klar abgegrenzte Transaktionsklassen scharf – etwa Rechnungen unter einem bestimmten Betrag ohne Preisabweichung. Phase drei weitet die Autonomie schrittweise aus, immer gesteuert durch Monitoring-Dashboards und Ausnahme-Quoten.

Für Legacy-SAP-Systeme wie SAP ECC gilt: Die Agenten arbeiten über APIs und Connectors auf dem bestehenden System, ohne es anzufassen. Das ist wichtig. Aussagen, man würde ein On-Premises-ERP „komplett agentisch machen“, sind meistens irreführend – in Wirklichkeit entsteht ein externer Automatisierungs-Layer, der das ERP als Datenbasis nutzt. Das kann trotzdem enorm wirkungsvoll sein, sollte aber architektonisch korrekt benannt werden.

Performance, Kosten und die Frage nach dem ROI

Die Zahlen, die im Markt kursieren, sind mit Vorsicht zu genießen. Integrations-Anbieter wie Peakflo sprechen von 85 bis 95 Prozent „touch-free“ Rechnungsverarbeitung bei AP-Automation mit agentischen Workflows in SAP, Oracle NetSuite und Microsoft Dynamics. Das sind Anbieter-Schätzungen, keine unabhängigen Branchenzahlen. In der Praxis hängen die Ergebnisse stark von Datenqualität, Prozessreife und dem tatsächlichen Scope ab.

Was sich belastbar kalkulieren lässt: Integrationsprojekte für Standard-AP-Workflows in NetSuite oder SAP über REST-APIs dauern laut Integrations-Anbietern typischerweise zwei bis vier Wochen, wenn die API-Infrastruktur bereits steht. Das ist der beste Fall. Komplexere Custom-Workflows mit mehreren Agenten, Datenbereinigung und Change Management dauern deutlich länger.

Kosten entstehen auf drei Ebenen: LLM-API-Kosten für jeden Agenten-Lauf, Infrastrukturkosten für den Orchestrierungs-Layer und interne Aufwände für Governance, Testing und Change Management. Wer nur die KI-API-Kosten kalkuliert, unterschätzt das Gesamtbild regelmäßig. Die harte Wahrheit: Agentische Workflows sind kein Kostenspar-Projekt, das sich im ersten Quartal amortisiert. Sie sind eine Infrastruktur-Investition mit mittelfristigem Hebel – wenn die Grundlagen stimmen.

Benutzer-Adoption: Das unterschätzte Problem

Finance-Teams, die jahrelang jeden Buchungssatz manuell geprüft haben, vertrauen einem KI-Agenten nicht automatisch. Punkt. Change Management ist kein weicher Faktor, der nach dem Go-Live mit ein paar Schulungen erledigt wird. Es ist eine Kernkompetenz agentischer ERP-Projekte.

Was in der Praxis funktioniert: Transparenz über jeden Agenten-Entscheid direkt in der ERP-Oberfläche. Nutzer sehen, welche Rechnung der Agent gebucht hat, nach welcher Regel und mit welcher Konfidenz. Ausnahmen, bei denen der Agent eskaliert hat, werden prominent angezeigt. Das gibt Kontrolle zurück – und Kontrolle ist der Schlüssel zu Akzeptanz.

Wer Agenten im Stillen agieren lässt und den Nutzern nur die Ergebnisse präsentiert, erzeugt Misstrauen. Seien wir ehrlich: Das ist keine KI-spezifische Herausforderung. Das ist grundlegendes Change Management in einem sensiblen Finanzumfeld. Die ERP-Hersteller liefern die Technologie. Die Verantwortung für Adoption liegt im Unternehmen.

Herstellerübergreifende Interoperabilität: Das nächste ungelöste Problem

Ein Aspekt, der in den Ankündigungen von SAP, Oracle und NetSuite systematisch unterbelichtet bleibt, ist die Frage der Interoperabilität zwischen Plattformen. Die meisten mittelgroßen und großen Unternehmen betreiben keine reine Single-Vendor-ERP-Landschaft. Die Realität ist oft ein SAP-System für das Kerngeschäft, NetSuite für eine Tochtergesellschaft und Oracle-Applikationen für spezifische Finance-Prozesse – verbunden durch eine gewachsene Middleware-Schicht.

Wenn Enterprise-ERP-Agenten plattformspezifisch konzipiert sind, entsteht das nächste Silo-Problem: Oracle-Agenten, die nicht mit SAP-Daten sprechen können, NetSuite-Agenten, die keine Konzern-konsolidierten Buchungskreise kennen. Der Einsatz von KI in ERP-Systemen wird langfristig nur dann sein volles Potenzial entfalten, wenn Agenten plattformübergreifend Kontext halten und Entscheidungen koordinieren können. Offene Standards wie MCP sind ein Schritt in diese Richtung – aber noch kein gelöstes Problem.

Für Architekturentscheidungen heute bedeutet das: Wer einen agentischen Layer aufbaut, sollte ihn nicht fest an eine einzelne ERP-Plattform koppeln. Ein Orchestrierungs-Layer, der oberhalb der einzelnen ERP-Systeme sitzt und über standardisierte APIs auf mehrere Systeme zugreift, ist aufwendiger in der Einführung, aber deutlich zukunftsfähiger als plattformspezifische Insellösungen.

Was bleibt offen – und was Sie jetzt entscheiden müssen

Oracle ist mit Fusion Agentic Applications aktuell am weitesten bei nativ eingebetteten Enterprise-ERP-Agenten. NetSuite kombiniert wachsende native KI-Funktionen mit einem ausgereiften Ökosystem externer Agenten-Layer. SAP setzt auf Business AI und BTP-Erweiterungen, ohne bisher ein vergleichbares „Agentic“-Branding zu etablieren. Alle drei Plattformen eint: Der Weg zu wirklich autonomen ERP-Prozessen führt über saubere Stammdaten, klar definierte Governance-Strukturen und echte Bereitschaft zu schrittweiser Autonomie-Ausweitung.

Experteneinschätzungen sehen bis Ende 2026 ein weitgehend „self-operating ERP“ in Reichweite – also ein System, das Maßnahmen nicht nur vorschlägt, sondern sie im Rahmen definierter Policies selbst ausführt. Das ist eine ambitionierte Vision. Ob sie Realität wird, hängt nicht primär von den Herstellern ab, sondern von den Unternehmen selbst: Wie reif sind die Prozesse? Wie sauber sind die Daten? Wie klar sind die Governance-Regeln?

Meine persönliche Meinung: Wer jetzt nicht anfängt, agentische Workflows in einem kontrollierten Piloten zu testen, verliert in drei Jahren wertvolle Lernkurve gegenüber Wettbewerbern, die früher gestartet sind. Die Frage ist nicht ob – die Frage ist: Mit welchem Prozess fangen Sie an, und wer in Ihrem Unternehmen übernimmt die Governance-Verantwortung dafür?