Autonomous Enterprise für Konzernabschluss: Vision und Realität

Einleitung: Das autonome Versprechen trifft auf die hybride Systemrealität

Die Vision des „Autonomous Enterprise“ (Autonomen Unternehmens) elektrisiert die Finanzwelt: Ein vollautomatischer Konzernabschluss, gesteuert von intelligenten KI-Agenten, die ohne menschliche Reibungsverluste Daten konsolidieren, Abstimmungen durchführen und Berichte verfassen [2, 5]. Doch zwischen diesem futuristischen Marketingversprechen und der harten Realität in den IT-Landschaften etablierter Konzerne klafft eine gewaltige Lücke.

In der Praxis arbeiten Finanzabteilungen in hochgradig heterogenen Systemumgebungen. Die Realität ist geprägt von bewährten Konsolidierungslösungen wie SAP SEM-BCS auf BW 7.5, BCS/4HANA auf BW/4HANA oder dem moderneren SAP S/4HANA Finance for Group Reporting [6]. Während vereinzelte Altsysteme immer noch in SAP EC-CS laufen, oder experimentieren erste Pioniere bereits mit SAP Datasphere und der SAP Business Data Cloud (BDC). Gleichzeitig sind nicht-SAP-Anwendungen, relationale Oracle- oder andere SQL-Datenbanken, Snowflake-Data-Warehouses, Power BI und vor allem unzählige, geschäftskritische Excel-Tabellen aus dem täglichen Abschluss nicht wegzudenken [10].

Vor diesem Hintergrund stellt sich für IT-Entscheider und CFOs eine fundamentale Frage: Müssen wir den von SAP propagierten Pfad eines geschlossenen, herstellereigenen Portals wie „Joule Work“ [2, 5] bedingungslos mitgehen und all unsere Prozesse in das SAP-Ökosystem migrieren? Oder gibt es einen datensouveränen Mittelweg, bei dem wir unsere IT-Unabhängigkeit bewahren, ein eigenes, übergeordnetes KI-Frontend aufbauen und dieses headless an die robusten Transaktionsprozesse von SAP anbinden?

Als unabhängiger IT-Architekt und Finanzsystem-Berater zeige ich Ihnen in diesem Beitrag, warum ein erzwungener „All-in-SAP“-Ansatz ein massives TCO- und Souveränitätsrisiko darstellt und wie Sie stattdessen eine offene, flexible und API-konforme Agenten-Architektur realisieren.

1. Der ERP-Sicherheitsrahmen: Warum KI im Finanzwesen ein „System of Trust“ benötigt

Wenn IT-Entscheider die Komplexität und die Kosten einer ERP-Modernisierung betrachten, liegt ein Gedanke nahe: „Warum extrahieren wir nicht einfach alle Daten aus unseren SEM-BCS- oder Group-Reporting-Systemen, laden sie in einen modernen Cloud Data Lake wie Snowflake und lassen eine generische, maßgeschneiderte KI die gesamte Konsolidierungslogik steuern?“

Dieser Ansatz ist ein gefährlicher Trugschluss. Im wertschöpfenden Finanzwesen und der regulatorischen Rechnungslegung ist eine KI-Fehlerrate von 10 % bis 15 % kein bloßes Ärgernis, sondern ein Compliance- und Haftungsdesaster [10]. Große Sprachmodelle (LLMs) sind zwar sprachlich brillant, besitzen aber von Haus aus keinerlei inhärente Geschäftslogik. Sie verstehen weder Bilanzierungsrichtlinien (IFRS/HGB) noch Intercompany-Eliminierungen, Konzern-Konsolidierungskreise oder die starren gesetzlichen Dokumentationspflichten [10].

„KI eliminiert Software nicht – sie verändert die Zusammensetzung des Werts innerhalb der Software.“ [10]

Um buchungssichere Transaktionen auszuführen, benötigen KI-Agenten das starre Regelwerk, die Belegprinzipien, die granularen Berechtigungskonzepte und die lückenlosen Audit-Trails des ERP-Kerns – das ERP als „Safety Frame“ (Sicherheitsrahmen) [4, 9, 10]. Der SAP-Kern fungiert als das ultimative „System of Trust“ [10]. Ein souveräner KI-Ansatz darf daher niemals die Transaktionsintegrität von SAP umgehen, sondern muss diese gezielt und kontrolliert nutzen.

2. Die Semantik-Schlacht: SAP Knowledge Graph vs. Eigenbau-Graph

KI-Agenten benötigen mehr als nur Zugriff auf Tabellen; sie müssen die semantischen Beziehungen zwischen Daten verstehen (z. B. welcher Debitor zu welchem Vertrag gehört und welche Konsolidierungsregel darauf anzuwenden ist) [2]. SAP bietet hierfür den SAP Knowledge Graph an, der jahrzehntelange ERP-Prozesslogik in ein maschinenlesbares Beziehungsnetzwerk übersetzt [2].

Der Haken: Dieser SAP Knowledge Graph ist cloud-exklusiv und fest an die hochpreisige SAP Business Technology Platform (BTP) und die Business Data Cloud (BDC) gebunden [2]. Für Unternehmen, deren Konsolidierung auf SEM-BCS (BW 7.5) oder BCS/4HANA (BW/4HANA) im eigenen Rechenzentrum oder in einer AnyPremise-Infrastruktur läuft, ist dieser Graph technisch kaum erreichbar oder mit prohibitiven Cloud-Kosten verbunden [10].

Für mittlere und große Konzerne mit ausgeprägter Hybrid-Landschaft ist ein selbstgebauter semantischer Knowledge Graph (z. B. auf Basis einer eigenen SAP HANA Cloud oder Open-Source-Graphdatenbanken) oft der überlegene und souveräne Weg. Ein solcher Eigenbau ermöglicht es, SAP-Finanzdaten nahtlos mit Nicht-SAP-Daten (wie CRM-, Logistik- oder externen Marktdaten) in einer eigenen Semantik-Ebene zu verknüpfen [7].

Allerdings darf der technische Realisierungsaufwand eines selbstgebauten Graphen nicht unterschätzt werden. In der Praxis zeigen sich vier zentrale Hürden [7]:

• Fragile SPARQL-Query-Generierung: LLMs müssen komplexe Graph-Abfragen (SPARQL) generieren, was bei unpräzisen Schemata schnell zu Fehlern führt.
• Aufwendiges Entity Matching: Die regelbasierte Normalisierung und Zusammenführung unterschiedlicher Entitäten (z. B. 'SAP-Kunde_A' und 'Snowflake-Client_1') erfordert kontinuierliche Pflege.
• Tägliche Synchronisationsprozesse: Es müssen robuste ETL- und Python-Synchronisationsjobs etabliert werden, um die Datenkonsistenz mit dem transaktionalen Kern zu wahren.
• Mandantenfähigkeit und Berechtigungen: Die Abbildung komplexer SAP-Berechtigungsstrukturen auf Graphebene ist eine architektonische Meisterleistung, die im Eigenbau manuell codiert werden muss.

Wer diese Hürden jedoch durch eine saubere Datenarchitektur meistert, erhält eine herstellerunabhängige Semantik-Ebene, die das Fundament für freie KI-Modelle bildet.

3. SAPs restriktive API-Policy (v4) und die DSAG-Position

Die strategische Entscheidung für ein eigenes Frontend wird durch die im April 2026 aktualisierte SAP API-Policy (v4) verschärft [1]. In Sektion 2.2.2 schränkt SAP den direkten, automatisierten Zugriff von Drittanbieter-KI-Systemen und autonomen Agenten auf SAP-Schnittstellen drastisch ein, sofern dieser Zugriff Transaktionsketten selbstständig plant oder ausführt [1, 10]. SAP begründet dies offiziell mit dem Schutz der Systemstabilität und der Vermeidung unkontrollierter Lastprofile durch unendliche Agenten-Loops [1, 10].

Die DSAG (Deutschsprachige SAP-Anwendergruppe) übt an dieser Policy scharfe Kritik. Vorstandsmitglieder wie Jens Hungershausen (Sorge um Planungssicherheit), Michael Bloch (Kritik an vertraglicher Intransparenz) und Stefan Nogly (Forderung nach Bestandsschutz für bestehende Integrationen) warnen vor einer künstlichen Barriere für Kundeninnovationen und dem Risiko verdeckter Zusatzkosten [1]. Zudem steht die restriktive Richtlinie im Spannungsfeld zum EU Data Act (gültig ab September 2025), der Unternehmen das gesetzliche Recht an den von ihnen in Systemen generierten Daten zusichert [1, 10].

Um diese Klippe lizenz- und rechtskonform zu umschiffen, dürfen eigene Agenten nicht unkontrolliert auf Standard-APIs zugreifen. Stattdessen müssen zwei von SAP offiziell unterstützte Integrationswege genutzt werden [3, 8]:

1. MCP (Model Context Protocol) Gateway auf der SAP Integration Suite: Hierbei greift der eigene Agent über einen gesicherten, kundenverwalteten MCP-Server zu, der Ratenbegrenzung, Audit-Logging und granulare Zugriffsrechte regelt [3, 8].
2. Agent-to-Agent (A2A) Protokoll: Ein offener Industriestandard der Linux Foundation. Unser eigener Konzern-Agent delegiert die transaktionale Ausführung im SAP-Kern über A2A an SAPs interne Joule-Schnittstellen, anstatt selbst direkt in die Tabellen zu schreiben [3, 5, 8].

4. Die Schnittstellen-Schlacht im Enterprise-Alltag

Welches Interface soll der Endanwender im Finanzalltag nutzen? Ein systematischer Dreifach-Vergleich verdeutlicht die strategischen Optionen und ihre Grenzen [3, 4, 8]:

Tabelle 1: Vergleich der Schnittstellen-Szenarien

• Hermes: Ein lokaler, auf dem Client-PC installierter Job-Assistent mag für kleine Teams reizvoll sein. Für Konzerne mit strengen Sicherheitsanforderungen ist er jedoch unbrauchbar [10]. IT-Sicherheitsabteilungen verbieten die Ausführung unkontrollierter Skripte auf Endgeräten, da diese weder auditierungsfähig sind noch zentrale Berechtigungsstrukturen erben.
• Joule Work: SAPs eigene Umgebung verspricht hohe Produktivität, bindet das Unternehmen jedoch kommerziell an verbrauchsbasierte „AI Unit“-Gebühren für jede triviale Routine-Interaktion [4, 10]. Zudem bleiben Nicht-SAP-Daten wie Excel-Konsolidierungen oder Drittdatenbanken außen vor.
• Eigene Kollaborations-Bots (z.B. MS Teams, Slack oder eigene Web-Portale): Dies ist der moderne Standard für Konzerne. Mitarbeiter kommunizieren in ihrer vertrauten Arbeitsumgebung. Ein im Hintergrund geschalteter, intelligenter Orchestrator nimmt Anfragen entgegen, bündelt den Kontext und holt sich die benötigten Transaktionsdaten headless über das MCP Gateway aus SAP SEM-BCS, BCS/4HANA oder Group Reporting [3, 8].

5. Aufgabenteilung: Wer macht was? (Die Governance-Matrix)

Um die Komplexität im Griff zu behalten und die IT-Sicherheit zu garantieren, müssen wir eine klare Trennlinie zwischen dem souveränen Konzern-Frontend und dem transaktionssicheren SAP-Backend ziehen [10].

Tabelle 2: Governance- und Aufgabenteilungs-Matrix

6. Der souveräne Transformations-Fahrplan: Inkrementelle Modernisierung statt „Big Bang“

Unternehmen können und sollten den Weg zum autonomen Finanzwesen nicht in einem riskanten, millionenschweren Gesamtprojekt erzwingen [4]. Ein inkrementeller, prozessweiser Transformationspfad minimiert das Projektrisiko und stiftet ab Tag eins echten geschäftlichen Nutzen [4].

Der Schlüssel liegt in sogenannten Finanz-Micro-Automations – kleinen, präzise abgegrenzten KI-Anwendungen, die direkt an der Arbeitsplatz-Oberfläche ansetzen, ohne die transaktionale Sicherheit des SAP-Backends zu gefährden:

• Excel-Formel-Agenten: Integration von KI-Assistenten, die Finanzanalysten beim automatischen Erstellen, Prüfen und Optimieren komplexer Accountingsformeln in Excel unterstützen.
• Natural-Language-Query-Schnittstellen (NLQ): Ein einfacher, lesender Bot in Teams oder Slack, der es Gelegenheitsnutzern ermöglicht, via Alltagssprache Konzernsalden oder Konsolidierungsstatus abzufragen („Wie hoch ist der IC-Abstimmungsstatus der Tochtergesellschaft Frankreich?“), ohne jemals einen komplexen SAP-Transaktionscode eingeben zu müssen [3, 8].
• Dokumentenvorprüfung: Ein lokaler Agent prüft Eingangsrechnungen und Buchungsbelege auf formale Korrektheit (z. B. Steuerpflichten, Pflichtangaben), bevor diese überhaupt an SAP übermittelt werden.

Dieser dreistufige Fahrplan führt Ihr Unternehmen sicher und souverän an das Ziel:

Die drei Stufen des souveränen Transformations-Fahrplans

1. Phase 1: API-Readiness & Micro-Automations: Erstellen Sie ein lückenloses API-Inventar Ihrer SEM-BCS- oder Group-Reporting-Schnittstellen [10]. Führen Sie parallel die ersten risikoarmen Micro-Automations ein (z. B. Excel-Formel-Assistenten oder automatisierte Berichtsentwürfe). Setzen Sie erste lesende NL-Query-Schnittstellen auf Teams-Basis auf, die Finanzdaten sicher abfragen, ohne transaktionale Risiken einzugehen [3, 8].
2. Phase 2: Semantische Entkopplung & Teams-Kopplung: Etablieren Sie Ihren selbstgebauten semantischen Knowledge Graph auf einer eigenen HANA Cloud oder nutzen Sie die SAP Datasphere / Business Data Cloud für ein Zero-Copy-Data-Sharing mit Snowflake. Verbinden Sie diesen Graphen mit Ihrem zentralen Kommunikations-Bot (z.B. Microsoft Teams) über ein konformes MCP Gateway [3, 8].
3. Phase 3: Prozess-Autonomie & A2A-Delegation: Erweitern Sie das System von reinen Lese- und Schreib-Szenarien auf komplexe, automatisierte Transaktionsketten. Nutzen Sie das Agent-to-Agent (A2A) Protokoll, um Freigaben und Buchungen aus Ihrem Teams-Bot an den headless agierenden SAP-Kern zu übergeben. Steuern Sie den gesamten Lebenszyklus über den SAP AI Agent Hub [3, 5].

Fazit: Technologie-Souveränität als CFO-Mandat

Das „Autonomous Enterprise“ ist keine reine Software-Entscheidung, sondern eine strategische Weichenstellung für die Souveränität Ihres Unternehmens. Ein bedingungsloser Wechsel in das geschlossene SAP-Portal Joule Work schränkt Ihre Flexibilität ein, erzeugt hohe Vendor-Lock-ins und führt zu unberechenbaren, verbrauchsabhängigen AI-Unit-Zusatzkosten [4, 10].

Indem Sie stattdessen eine offene, modular entkoppelte „Open but Anchored“-Architektur etablieren, kombinieren Sie das Beste aus beiden Welten. Sie behalten die volle Kontrolle über Ihr Benutzer-Interface, Ihre Datenflüsse und Ihre KI-Modelle. Gleichzeitig nutzen Sie SAP genau für das, was es am besten kann: Als hochsichere, gesetzeskonforme und unbestechliche Transaktions-Maschine im Hintergrund [10].

Der Weg dorthin ist kein riskanter „Big Bang“, sondern eine kontrollierte, prozessweise Evolution, die mit einfachen Lese-Assistenten und Excel-Micro-Automations beginnt und schrittweise zur vollen agentischen Orchestrierung reift.

Literatur- und Datenquellenverzeichnis

[1] Deutschsprachige SAP-Anwendergruppe e. V. (DSAG): “New SAP API Policy: DSAG sees a need for clarification, specification and adoption” [Offizielle Pressemeldung, 29. April 2026].

[2] SAP SE: “Architecting From Intent to Action with Joule Work & Knowledge Graph” [Fachvortrag im Rahmen der SAP AI Adoption & Learning Week, John Santic und Jason Taylor, 16. Juni 2026].

[3] SAP SE: “Playbook for Building your Own SAP Agents with Joule Studio” [Fachvortrag im Rahmen der SAP AI Adoption & Learning Week, Julia Kloppenburg & Gaurish Dessai, 26. Juni 2026].

[4] SAP SE: “AI Adoption Methodology for Architecting and Activating AI in SAP Landscapes” [Fachvortrag im Rahmen der SAP AI Adoption & Learning Week, Jose Augusto Tornero & Helmut Grimm, 1. Juli 2026].

[5] SAP Community: “SAP’s Autonomous Enterprise: beyond the announcement and into architecture” [Technischer Leitfaden für Enterprise-Architekten, 11. Juni 2026].

[6] SAP Press / Rheinwerk Publishing: “A History of Financial Consolidation with SAP: From FI-LC and SEM-BCS to S/4HANA Group Reporting” [Fachbeitrag zur Produktgeschichte, Mai 2026].

[7] SAP Community: “Knowledge Graphs on SAP HANA Cloud: From Zero to Enterprise Retrieval-Augmented Generation (RAG)” [Technischer Implementierungsbericht, März 2026].

[8] SAP Community: “Whitepaper: Transforming Enterprise Portals with Conversational AI on SAP BTP” [Architektur-Blueprint für kundenindividuelle Webportale, Juli 2026].

[9] SAP SE: “SAP Global AI Ethics Policy: UNESCO-aligned Rules for Proportionality, Security, and Governance” [Richtlinie Version 3.0, Wirksamkeitsdatum 15. Juni 2026].

[10] SAP Licensing Experts: “SAP S/4HANA Cloud vs. On-Premise Licensing: 2026 Cost & Risk Comparison Guide” [Unabhängiger Lizenzratgeber für Unternehmenskäufer, März 2026].