SAP Reporting mit KI 2026: Self-Service statt BW-Projekt

Pexon Consulting | 9 Min. Lesezeit | 16.07.2026

TL;DR

SAP Reporting mit KI heißt: Führungskräfte fragen ihre SAP-Daten in normaler Sprache und bekommen in Sekunden eine belegte Antwort. Pexon Consulting (80 Mitarbeiter, Microsoft-Partner, Deutschland) baut die Reporting-Schicht als Lakehouse mit korrekter SAP-Semantik und gespiegelten Berechtigungen. Erster Fachbereich produktiv in acht Wochen.

Warum jede SAP-Frage der Geschäftsführung Tage dauert

Die Kette ist überall gleich: Die Geschäftsführung stellt eine Frage, ein Key-User zieht einen SE16-Abzug, der wandert als Excel über drei Abteilungen, und zwei Tage später liegt eine Zahl auf dem Tisch, die niemand mehr gegenprüfen kann. Bis die Antwort da ist, entscheidet die Führung auf Basis des letzten Monatsabschlusses statt auf aktuellen Zahlen.

Das Wissen, wie man überhaupt an die richtigen Tabellen kommt, hängt bei den meisten Mittelständlern an ein oder zwei Personen. Fällt einer aus, steht das Reporting. Excel ist dabei nicht das Problem, sondern das Symptom: Es füllt die Lücke, die entsteht, weil es keine saubere Reporting-Schicht auf den SAP-Daten gibt.

Der naheliegende SAP-Weg wäre BW/4HANA oder die SAP Analytics Cloud. Für viele Häuser mit 300 bis 3.000 Mitarbeitern ist das aber ein zu großes, zu teures und zu projektlastiges Vorhaben. Man kauft sich ein Data-Warehouse-Programm über Monate ein, um am Ende drei Standard-Reports zu bekommen, die die Geschäftsführung dann doch wieder nach Excel exportiert.

Was Self-Service-Reporting auf SAP-Daten wirklich heißt

Self-Service bedeutet nicht, dass jeder Fachbereich sich seine SAP-Tabellen selbst zusammensucht. Es bedeutet: eine Person ohne SAP-Kenntnisse stellt eine fachliche Frage und bekommt eine korrekte, belegte Antwort, ohne einen Key-User zu blockieren. Der Unterschied liegt komplett in der Schicht dazwischen.

Diese Schicht ist ein semantisches Modell. Es übersetzt die SAP-Rohtabellen (VBAK, VBAP, BSEG und Konsorten) in fachliche Begriffe, die ein Mensch versteht: „offener Auftrag“, „A-Kunde“, „Deckungsbeitrag“. Und es kennt die SAP-Semantik, die man am Rohbeleg nicht raten darf. Ein Storno ist kein negativer Umsatz, den man einfach draufrechnet. Eine Gutschrift verhält sich in der Bewertung anders als eine Rechnung. Wer diese Regeln nicht in der Schicht abbildet, produziert Zahlen, die im Detail falsch sind, obwohl die Summe stimmig aussieht.

Hier kommt unsere klare Position: Ein KI-Chat ohne semantische Schicht ist ein Zahlen-Generator, kein Reporting. Wenn ein Sprachmodell direkt auf die SAP-Rohtabellen losgelassen wird, rät es sich das Datenmodell zusammen. Das geht bei „Zeig mir den Umsatz letzten Monat“ noch gut und bricht bei jeder Frage, die Storni, Teillieferungen oder Konzernkonsolidierung berührt. Genau dort trifft die Geschäftsführung aber ihre Entscheidungen.

So sieht die Reporting-Schicht technisch aus

Die Architektur besteht aus drei Teilen: Anbindung an SAP, ein Lakehouse als Reporting-Schicht und der KI-Chat als Oberfläche. Wir bauen das nicht als BW-Neuprojekt, sondern als schlanken Layer auf einer AI-ready Data Platform (bei uns meist auf Microsoft Fabric), auf der das semantische Modell und die Berechtigungen liegen.

Bei der Anbindung ist gerade jetzt Präzision gefragt. Der klassische ODP-RFC-Weg für Nicht-SAP-Consumer ist tot: Mit dem SAP-Sicherheitspatch ab Juni 2026 (SAP Note 3255746) prüft SAP bei jedem ODP-Call den Subscriber-Type und blockt Nicht-SAP-Consumer. Ein Self-Assessment-Tool dazu (SAP Note 3439624) steht seit dem 13. April 2026 bereit. Der saubere, zukunftsfeste Weg ist ODP-OData über eine CDS-View. Das ist genau die Anbindung, die ein moderner Reporting-Layer ohnehin braucht.

@AbapCatalog.sqlViewName: 'ZVOPENSO'
@OData.publish: true
@AccessControl.authorizationCheck: #CHECK
// Extraktion über ODP-OData statt ODP-RFC: seit dem Juni-2026-Patch
// prüft SAP den Subscriber-Type und sperrt Nicht-SAP-Consumer auf
// dem alten RFC-Weg. Die authorizationCheck-Annotation zieht die
// SAP-Berechtigung schon an der Quelle mit.
define view Z_Open_Sales_Orders as select from vbak
  association [1..*] to vbap as _Item on $projection.SalesOrder = _Item.vbeln
{
  key vbak.vbeln as SalesOrder,
      vbak.kunnr as Customer,
      vbak.audat as DocumentDate,
      vbak.gbstk as OverallStatus,   // Gesamtstatus des Belegs
      _Item
}
// 'C' = vollständig erledigt: erledigte Aufträge raus, Storni ebenso
where vbak.gbstk <> 'C'

Die ABAP-Bezeichner bleiben oben bewusst ASCII, die Kommentare tragen echte Umlaute. Aus dieser Extraktion landet ein sauberes, historisiertes Faktenmodell im Lakehouse. Dass selbst SAP diesen Weg geht, sieht man an SAP Business Data Cloud: Der Connect für Databricks ist seit Oktober 2025 allgemein verfügbar und teilt SAP-Daten per Zero-Copy in ein Lakehouse. Wer ohnehin bis Ende 2027 wegen des Mainstream-Wartungsendes von SAP ECC seine Datenanbindung neu baut, sollte den Reporting-Layer gleich mitdenken.

Der KI-Chat: natürliche Sprache zu SQL mit Beleg

Die Führungskraft tippt eine Frage in Klartext, der Chat antwortet mit Zahlen und einem Beleg auf die Zeilen. Technisch generiert der Chat kontrolliertes SQL gegen das semantische Modell, er erfindet keine Zahlen. Für den sprachlichen Teil nutzen wir ein aktuelles LLM (zum Beispiel claude-sonnet-5) im Text-to-SQL-Muster. Das Modell formuliert die Abfrage, ausgeführt wird sie deterministisch auf dem Lakehouse.

-- Frage der Geschäftsführung im KI-Chat:
-- "Zeig mir alle offenen Aufträge mit Lieferverzug bei A-Kunden"
--
-- Der Chat generiert kontrolliertes SQL gegen das semantische Modell.
-- 'offen' und 'Storno' kommen aus der SAP-Semantik-Schicht,
-- nicht aus einer Vermutung am Rohbeleg.
SELECT  c.customer_name,
        o.sales_order_id,
        o.confirmed_delivery_date,
        o.open_value_eur
FROM    fct_sales_orders o
JOIN    dim_customer c  ON c.customer_id = o.customer_id
WHERE   o.status = 'open'                 -- Storni und Gutschriften sind raus
  AND   o.confirmed_delivery_date < current_date
  AND   c.abc_class = 'A'
ORDER BY o.open_value_eur DESC;

Der entscheidende Teil ist der Beleg. Jede Antwort verweist auf die zugrunde liegenden Zeilen und das generierte SQL. Damit kann die Führungskraft nachvollziehen, woher die Zahl kommt, und ein Controller kann sie gegenprüfen. Das ist derselbe Vertrauensmechanismus, den wir aus belegorientierten RAG- und Knowledge-Bot-Projekten kennen: Eine Antwort ohne Quelle ist im Enterprise-Kontext wertlos.

Wir sehen bei unseren Kunden immer wieder denselben Aha-Moment: Die erste Frage im Chat ist nie eine Standard-Kennzahl, sondern eine, die im alten Prozess nie gestellt wurde, weil sie zwei Tage Key-User-Zeit gekostet hätte. Genau diese Fragen bewegen die Entscheidung.

SAP-Berechtigungen spiegeln, sonst wird es ein Datenschutz-Unfall

Ein Reporting-Layer, der jedem alles zeigt, ist kein Fortschritt, sondern ein Risiko. Die kurze Antwort: SAP-Berechtigungen müssen gespiegelt werden, sonst ist es ein Datenschutz-Unfall. Wenn der Vertriebsleiter im SAP nur seine Region sieht, muss er sie auch im Chat nur für seine Region sehen, auf die Zeile genau.

Das lösen wir, indem die SAP-Berechtigungsobjekte in die Lakehouse-Schicht übernommen werden und als Row-Level-Security greifen. Die authorizationCheck-Annotation an der CDS-View ist der erste Baustein, die zweite Ebene ist die Durchsetzung im semantischen Modell. Der KI-Chat fragt nie an den Berechtigungen vorbei, weil das SQL immer gegen die abgesicherte Sicht läuft, nie gegen die Rohtabelle.

Das ist der Punkt, an dem selbstgebaute Chat-Prototypen auf SAP-Exporten scheitern. Ein CSV-Dump im Chat-Tool kennt keine Berechtigungen. Sobald das Ding im Haus bekannt wird, sieht der halbe Betrieb Gehälter, Margen und Kundenkonditionen. In einem regulierten Umfeld ist das kein Schönheitsfehler, sondern ein meldepflichtiger Vorfall.

Warum kein BW-Neuprojekt: Reporting-Sprint statt Groß-Vorhaben

Ein BW-Neuprojekt nur fürs Reporting ist für den Mittelstand meist überdimensioniert. Unsere Empfehlung: Reporting-Sprint statt Wasserfall. Zwei Wochen zum Festpreis, in denen die Anbindung an einen Fachbereich steht, das semantische Modell für dessen Kernfragen sitzt und der KI-Chat auf echten Daten läuft. Danach acht Wochen bis ein kompletter Fachbereich produktiv ist, inklusive Berechtigungen und Betrieb.

Die Aufteilung im Bundle ist klar geschnitten: WIAG verantwortet die SAP-Anbindung und die Semantik (ODP-OData, CDS, das saubere Verständnis von Storni, Gutschriften und Bewertung), Pexon die Lakehouse-Plattform und den KI-Chat. Keiner rät am fremden Terrain herum. Genau das macht den Festpreis überhaupt seriös kalkulierbar.

Nach dem ersten Fachbereich rollt man dieselbe Schicht auf den nächsten aus. Das Modell wächst mit, statt dass man ein Monolith-Warehouse vorab durchplant.

Häufig gestellte Fragen

Was kostet Self-Service-Reporting auf SAP-Daten mit KI-Chat?

Der Einstieg ist ein Reporting-Sprint zum Festpreis über zwei Wochen, danach etwa acht Wochen bis ein Fachbereich produktiv läuft. Das liegt deutlich unter einem klassischen BW-Projekt, weil kein Data-Warehouse-Monolith vorab durchgeplant wird. Den genauen Zuschnitt und Preis legen wir im Use-Case-Workshop fest.

KI-Chat auf SAP-Daten oder klassisches SAP BW: was ist besser?

Kommt auf die Ausgangslage an. Wer ein eingespieltes BW-Team und komplexe Konzernkonsolidierung hat, bleibt oft bei BW. Für Mittelständler, die schnell tagesaktuelle Antworten für die Führung brauchen und kein BW-Team haben, ist der schlanke Reporting-Layer mit KI-Chat der pragmatische Weg, meist in Wochen statt Monaten.

Halluziniert der KI-Chat Zahlen aus dem SAP?

Nein, wenn er richtig gebaut ist. Der Chat generiert kontrolliertes SQL gegen ein semantisches Modell und führt es deterministisch aus. Er erzeugt selbst keine Zahlen, sondern nur die Abfrage, und liefert zu jeder Antwort einen Beleg auf die Zeilen. Ohne semantische Schicht dagegen rät ein Modell am Datenmodell, und dann sind Halluzinationen real.

Sieht im Chat wirklich jeder nur, was er im SAP darf?

Ja. Die SAP-Berechtigungen werden als Row-Level-Security in die Reporting-Schicht gespiegelt, und das generierte SQL läuft immer gegen die abgesicherte Sicht. Ein Vertriebsleiter sieht im Chat nur seine Region, exakt wie im SAP. Das ist kein optionales Feature, sondern die Voraussetzung für den Produktivbetrieb.

Müssen wir für die Anbindung auf S/4HANA migriert sein?

Nein. Die Anbindung läuft über ODP-OData und CDS-Views und funktioniert auch auf SAP ECC. Da die ECC-Mainstream-Wartung Ende 2027 ausläuft, bauen viele Häuser ihre Datenanbindung ohnehin gerade neu. Der Reporting-Layer lässt sich dabei direkt mitziehen, unabhängig vom S/4-Zeitplan.

Nächster Schritt

Wenn Sie gerade evaluieren, wie Ihre Führung ohne Excel-Ketten an aktuelle SAP-Zahlen kommt: Der schnellste Weg ist, die Reporting-Schicht an einem konkreten Fachbereich zu skizzieren.

Verwandte Themen

_{Quelle zur ODP-Änderung und SAP Business Data Cloud: Databricks, GA von SAP Business Data Cloud Connect}