Agentic Planning mit Analysis for Office

Agentic Planning steht bei SAP längst auf der Roadmap, und der Weg dorthin heißt Joule. Joule ist der Kern von SAPs Business AI Strategie, und für die Planung bekommt Joule eigene Planning Agents. Einer baut Planungsmodelle, einer schreibt die Logik für Data Actions, und einer lädt Plandaten hoch. Für später ist ein Agent angekündigt, der einfache Planungszyklen per Prompt ausführt. Dazu zeigt SAP, wie ein Planer in Joule in eigenen Worten beschreibt, was er ändern will, und Joule die Werte in die Planversion schreibt. Wie wir unter anderem in unserem Beitrag zum DSAG-Jahreskongress 2026 berichtet haben, sind die ersten Agenten für das vierte Quartal 2026 angekündigt, mit dem Vorbehalt, dass sich der Stand noch ändern kann. Gedacht sind sie alle für SAP Analytics Cloud.

Sehr viele Unternehmen planen allerdings nach wie vor im BW, auf BW Integrated Planning oder BPC Embedded, und häufig sind genau das ihre größten und geschäftskritischsten Planungen. Gearbeitet wird darin mit Analysis for Office, in Excel, jeden Tag. In SAPs Strategie für Agentic Planning kommt diese Welt nicht vor. Sie ist aber die Realität, in der viele Planungsabteilungen heute arbeiten und noch einige Jahre arbeiten werden.

Im April habe ich hier den bw-modeling-mcp vorgestellt, einen Open Source MCP Server, mit dem ein KI-Agent direkt im BW modelliert. Er nimmt schon sehr viel von der Design Time ab. Seit Version 1.8 von Mitte Oktober baut er ein komplettes Planungsmodell, vom Plan aDSO über Aggregationsebene und Planungsfunktionen bis zur eingabebereiten Query, mit dem Funktionsumfang, den BW-IP bietet.

Agentic Planning ist aber mehr als ein schneller gebautes Modell. Es verändert, wie geplant wird. Bei Agentic Analytics frage ich meine Daten einfach nach dem, was ich wissen will. Beim Agentic Planning sage ich genauso, was ich planen will, auch wenn es eine komplexe Anforderung mit Bedingungen ist. Steigen die Energiekosten im zweiten Halbjahr um zehn Prozent, verteile das auf die Werke nach ihrem Verbrauch und zeig mir, was das für die Marge bedeutet. Ganze Szenarien lassen sich so in ein paar Sätzen durchspielen. Dafür braucht es aber mehr als das Modell im BW. Geplant wird in einer Mappe in Analysis for Office, und die muss erst einmal gebaut werden, mit Datenquellen, Planungsfunktionen an Buttons und VBA, bisher von Hand. Und wenn die Mappe steht, sieht ein KI-Assistent in Excel wie Claude in Excel oder Microsoft Copilot dort zwar die Zellen, ein Planwert, den er hineinschreibt, kommt aber ohne weiteres nicht im BW an.

Genau diese Lücke schließt der afo-mcp, den ich diese Woche als zweites Open Source Projekt auf GitHub veröffentlicht habe. Er baut Planungsmappen für AfO, ohne dass jemand Excel öffnen muss, und rüstet sie mit einer Agent Bridge aus. Über diese Bridge plant der KI-Assistent in Excel richtig mit. Er gibt Werte ein, startet Planungsfunktionen, rechnet Szenarien durch und sichert erst nach dem OK des Planers. Damit läuft Agentic Planning heute schon auf BW/4HANA mit Analysis for Office im Standard, also in genau der Landschaft, die Sie bereits haben. Ein neues Produkt oder eine Migration braucht es dafür nicht.

Planung im BW, mächtig und viel Handarbeit

Wer ein Planungsprojekt im BW begleitet hat, misst die Dauer selten in Tagen oder Wochen. Große Planungslösungen brauchen Monate, manche sogar Jahre, bis sie stehen. BW Integrated Planning und BPC Embedded sind ein generisches Framework. Jede Planung wird aus Bausteinen zusammengesetzt, aus Plan aDSOs, Aggregationsebenen, Filtern, Variablen, Merkmalsbeziehungen, Datenscheiben und Planungsfunktionen in vielen Typen bis hin zu FOX und ABAP. Damit lässt sich fast jede Anforderung abbilden, zum Preis einer Komplexität, die ehrlich gesagt manchmal frickelig ist. Wer damit arbeitet, kennt die Fragen, warum eine Kennzahl plötzlich nicht eingabebereit ist oder warum die Daten nach dem Sichern komisch aussehen. Dahinter steckt das Zusammenspiel von Eingaben auf aggregierter Ebene mit den Deltasätzen, die daraus entstehen und die Merkmalsbeziehungen und Datenscheiben respektieren müssen. Der Engpass ist die Übersetzung dessen, was die Fachabteilung meint, in diese Bausteine.

Danach braucht der Planer noch eine Oberfläche, und das ist im BW meistens Analysis for Office. Planer kennen Excel, und AfO bringt die BW Queries mit Eingabebereitschaft, Planungsfunktionen und Variablen direkt dorthin. Auch diese Mappe ist Fleißarbeit mit Ansage, die bei jeder Änderung am Modell wieder anfällt.

Vom Satz zum Planungsmodell mit fertiger Mappe

Seit Version 1.8 baut der bw-modeling-mcp alle Objekte einer BW-IP-Planung, auch Planungsfunktionen inklusive FOX, Planungssequenzen, Formelvariablen, Hierarchien und Umrechnungsarten. In unserer Demo beginnt es mit einem Satz, wir brauchen für 2027 eine Absatz- und Preisplanung je Produkt, Land und Monat. Der Agent liest das Ist-Modell, schlägt einen Entwurf vor und baut nach meiner Freigabe Plan aDSO, CompositeProvider, Aggregationsebene, Variablen, Planungsfunktionen und Queries. Nach unter fünf Minuten ist alles aktiviert, angelegt über dieselben Schnittstellen, mit denen auch die BW Modeling Tools in Eclipse arbeiten, und mit Transportauftrag wie bei jeder anderen Entwicklung.

Die Mappe dazu baut der afo-mcp, offline und ohne Excel oder BW-Anmeldung. Sie enthält Datenquellen mit gespeicherten Prompts, eingabebereite Crosstabs, Buttons für Planungsfunktionen und Sequenzen, Filter und VBA. AfO öffnet sie wie eine von Hand gebaute Mappe. In der Demo hat sie eine Parameterkarte für Version und Planmonat, Buttons für Ist übernehmen, neu berechnen, sichern und verwerfen und KPI-Kacheln über dem Crosstab. Umgekehrt liest der afo-mcp bestehende Mappen, zeigt, welche Mappen an einer Query hängen, und überträgt alle AfO-Elemente in ein neues Layout. Er steht unter MIT-Lizenz, enthält keinen SAP-Code und arbeitet mit dem, was in den Dateien steht, denn das Format von AfO hat SAP nicht dokumentiert. Die fachlichen Entscheidungen bleiben beim Menschen, die Übersetzung in Objekte und Mappen übernimmt der Agent.

Hier unsere Präsentation "Agentische Entwicklung mit SAP BW" anfordern

Warum KI-Assistenten in Excel an AfO scheitern

KI-Assistenten in Excel wie Claude in Excel oder die Integrationen anderer Hersteller arbeiten über Office.js, die Programmierschnittstelle von Microsoft für Office Add-ins, und schreiben damit Zellen. AfO erkennt eine Eingabe aber am Change-Event von Excel, und das löst Office.js nicht aus. Der Planwert steht in der Zelle, kommt aber nie im BW an. Excel-Filter auf einem Crosstab sind beim nächsten Refresh weg, und eine Planungsfunktion starten kann Office.js gar nicht. Das Tückische daran ist, dass in Excel alles richtig aussieht.

Die Agent Bridge, Hände in der Mappe und Wissen in der KI

Der afo-mcp rüstet jede Mappe mit einer Agent Bridge aus, einem versteckten Blatt mit Befehlszelle und einem VBA-Modul, das die Befehle als echte AfO-Eingabe ausführt und das Ergebnis zurückmeldet. Damit kann die KI Werte setzen, das Ist übernehmen, Planungsfunktionen starten, sichern und verwerfen, filtern und den Aufriss ändern, und über einen allgemeinen Befehl jede Funktion der AfO-API außer der Anmeldung nutzen. Nach jedem Schritt prüft das VBA-Modul die Meldungen von AfO, sodass der Agent sieht, ob AfO eine Eingabe wirklich angenommen hat, statt es nur anzunehmen.

Wie der Agent damit arbeitet, steht in einem Skill, einer Anleitung, die man dem KI-Assistenten einmal mitgibt. Sie sorgt dafür, dass er vor dem Sichern nachfragt, keine technischen Namen rät und eine fehlende Bridge nachrüsten lässt. An einen bestimmten Hersteller ist die Bridge nicht gebunden, jede KI, die Excel über Office.js anspricht, kann die Befehle aus der Hilfe auf dem Bridge-Blatt lernen. Getestet habe ich das mit Claude in Excel auf BW/4HANA mit AfO 2.8.

Bestehende Mappen agentisch machen, der Closed Loop

Die meisten Unternehmen haben bereits etliche Planungsmappen im BW und wollen ihre bestehenden Lösungen nicht von Grund auf neu aufbauen. Seit Version 1.9 listet der bw-modeling-mcp die im BW gespeicherten AfO-Mappen mit ihrem Verwendungsnachweis auf. Er lädt eine Mappe, ohne jemanden zu stören, der gerade darin arbeitet, und speichert sie zurück ins BW, auf Wunsch direkt in ein Rollenmenü.

Zusammen mit dem afo-mcp ergibt das einen geschlossenen Kreislauf. Der Agent lädt eine bestehende Mappe aus dem BW, liest sie und verbessert sie, rüstet zum Beispiel die Agent Bridge nach oder legt eine zusätzliche Planungsfunktion auf einen Button. Vorhandene Ereignisbehandlungen ergänzt der afo-mcp dabei, statt sie zu ersetzen, und signierte VBA-Projekte fasst er nicht an. Danach geht die Mappe in dieselbe Rolle zurück. Am nächsten Morgen öffnen die Planer ihre gewohnte Mappe und planen darin agentisch, ohne neues Werkzeug und ohne Migration.

Der Agent sieht mehr als die Zellen

Entscheidend ist, was der Agent sieht. Mit dem afo-mcp und dem bw-modeling-mcp sieht ein KI-Assistent in Excel drei Ebenen, die angezeigten Zellen, in denen ein zugeklappter Hierarchieknoten oder ein herausgefiltertes Merkmal schlicht nicht vorkommt, die Datenquelle hinter dem Crosstab mit den ungesicherten Planwerten der Sitzung und über den bw-modeling-mcp als Connector das ganze BW-Modell mit Vorjahren, Stammdaten, Hierarchien und der Logik der Planungsfunktionen, immer innerhalb der Berechtigungen des Planers. Wer sagt, die Preise sollen den Deckungsbeitrag der letzten zwölf Monate halten, bekommt deshalb eine Antwort, auch wenn diese Zahl nicht im Planungsblatt steht.

Unser Fazit:v Agentic Planning als Messlatte für SAPs Planning Agents

SAP entwickelt AfO nicht mehr weiter, sichert den Support aber bis mindestens 2031 zu. Dass sich darin jetzt agentisch planen lässt, auf Standardschnittstellen und als Open Source, wertet die bestehende Landschaft enorm auf. Und es setzt eine Messlatte für die Joule Planning Agents. Aus meiner Sicht kommt es auf vier Punkte an.

• Was der Agent sieht. In SAPs eigener Planungsdemo spricht Joule die Zellen der Story-Tabelle über ihre Koordinaten an, das entspricht der ersten der drei Ebenen. Was unter einem zugeklappten Hierarchieknoten liegt, welche Planwerte noch ungesichert sind oder wie das Vorjahr aussah, bleibt einem solchen Agenten verborgen. Gute Planungsvorschläge brauchen aber genau diesen Blick hinter die Tabelle.
• Ob er die Design Time auch bei komplexen Anforderungen wirklich abnimmt.
• Ob er an eigenen Kontext wie Wissensrepositories und Konventionen herankommt.
• Was er kostet. Für die Premiumfunktionen in Joule hat SAP noch keine Preise genannt.

Wer im Planungsbereich die Hoheit verteidigen will, muss Agentic Planning deshalb richtig angehen. Planer brauchen neue Möglichkeiten, Szenarien durchzuspielen, Kontexte einzubeziehen, die für ihre Planung relevant sind, und treiberbasiert zu planen. Was in der vermeintlichen Legacy-Welt mit BW und AfO heute schon geht, zeigt, wie weit das reichen kann.

Wer im BW mit SAC als Frontend plant, kann denselben Weg gehen. Mein Kollege Rafael Sachs hat letzte Woche den SAC Workbench MCP als Open Source veröffentlicht und in seinem Blog-Beitrag vorgestellt. Das Backend baut der bw-modeling-mcp, das Frontend der SAC Workbench MCP. Dazu folgen weitere Beiträge.

Die MCP Server finden Sie auf GitHub, den afo-mcp unter github.com/dnic-dev/afo-mcp, den bw-modeling-mcp unter github.com/dnic-dev/bw-modeling-mcp und den SAC Workbench MCP unter github.com/RafaelSachsNL/sac-workbench-mcp.

Möchten Sie herausfinden, was Agentic Planning für Ihre Planung im BW konkret leisten kann? Sprechen Sie uns an, wir begleiten Sie vom ersten Prototyp bis zum Einsatz in Ihrer Planungsrunde.