In unserem ersten Blogbeitrag zu Seamless Planning haben wir die Grundlagen dieser neuen Integration zwischen SAP Analytics Cloud (SAC) und SAP Datasphere vorgestellt und anhand unseres NextJuice-Modells gezeigt, wie sich externe Zusatzdaten nahtlos in ein Planungsszenario integrieren lassen. Der Beitrag hat viel positives Feedback erhalten - und gleichzeitig viele Folgefragen aufgeworfen: Welche weiteren Möglichkeiten gibt es? Was hat sich seitdem verändert? Und wo liegen die Grenzen?
Die gute Nachricht: Seit unserem ersten Beitrag hat SAP mit dem Q4 2025 Release ein Feature ausgeliefert, das Seamless Planning auf ein neues Level hebt - Externe Live-Versionen (External Live Version Data Sources). Damit lassen sich Faktendaten aus SAP Datasphere erstmals direkt und ohne Replikation als Versionen in SAC-Planungsmodelle einbinden. Das Ergebnis: Echtzeit-Zugriff auf Ist-Daten, Plandaten aus anderen Modellen oder eben externe Zusatzdaten - alles live, alles ohne manuellen Datenimport.
In diesem Beitrag greifen wir unser bewährtes NextJuice-Beispielmodell erneut auf und zeigen diesmal drei konkrete Wege, wie sich externe Daten - am Beispiel von Rabattinformationen (Discount) - in ein Seamless-Planning-Szenario integrieren lassen. Zum Abschluss werfen wir einen Blick auf eine vierte Variante, die aus unserer Sicht die mächtigste wäre - technisch aktuell aber leider nicht umsetzbar ist.
Unsere Blogreihe: Seamless Planning im Fokus |
| 1 SAC Planung trifft auf SAP Datasphere |
| 2 Drei Wege zur Integration externer Daten |
Unser NextJuice-Modell bildet die Absatzplanung eines fiktiven Getränkeherstellers ab. Die zentralen Planungskennzahlen sind unter anderem Absatzmenge (Quantity) und Umsatz (Sales Revenue). Für eine realistische und ganzheitliche Planung benötigen wir jedoch zusätzlich Rabattinformationen (Discount), die nicht direkt aus dem Sales-Prozess stammen, sondern extern gepflegt werden.
Diese Rabattdaten sind nicht mit den Actuals-Verkaufsdaten verknüpft und unterscheiden sich auch strukturell deutlich von den Sales-Daten. Es handelt sich um prozentuale Rabattsätze, die auf Ebene von Filialen bzw. Filialen und Produkten gepflegt werden und nach Rabattart unterschieden werden - Key Account Discounts gelten pauschal pro Filiale, Volume Discounts werden zusätzlich auf Produktebene differenziert.
Das Entscheidende: Sie existieren als eigenständiger Datensatz in Datasphere und müssen in den Planungsprozess integriert werden, um dort für Berechnungen oder als Referenz zur Verfügung zu stehen.
In unserem Szenario werden die Discount-Daten mit der Lösung NextTables gepflegt. NextTables bietet eine benutzerfreundliche Oberfläche zur manuellen Datenpflege direkt in SAP Datasphere - ideal für Zusatzdaten, die nicht automatisiert aus einem Quellsystem kommen. Besonders praktisch: NextTables lässt sich als Web-Komponente direkt in die SAC Story einbetten, sodass Planer die Rabattdaten im selben Kontext pflegen können, in dem sie auch planen.
Diese Variante haben wir bereits in unserem ersten Blogbeitrag ausführlich vorgestellt, sie funktioniert also bereits seit dem Q1 2025 Release von Seamless Planning. Der Ansatz besteht darin, in SAP Datasphere ein Analytic-Model zu erstellen, das sowohl die Planungsdaten aus dem Seamless-Planning-Modell als auch die externen Rabattdaten zusammenführt.
Technische Umsetzung
Datasphere View erstellen: Im Datasphere Data Builder wird eine View angelegt, die die Fakt-Tabelle des Seamless-Planning-Modells per Join mit der Discount-Tabelle verbindet und die gesamte Verrechnungslogik virtuell abbildet.
Analytic Model in Datasphere: Auf Basis dieser View wird ein Analytic Model in Datasphere erstellt, das die kombinierten Daten als konsumierbare Datenquelle bereitstellt.
Dashboard-Integration: In der SAC Story können nun Tabellen und Charts erstellt werden, die Daten aus dem Analytics Model und dem Planning Model gemeinsam darstellen.
Vorteile
Volle Flexibilität der Datasphere-Modellierung: SQL-Joins, berechnete Kennzahlen, Unions - alles möglich
Ideal für komplexe Berechnungslogiken, die in Berechneten Kennzahlen oder Advances Formulas nicht oder nur schwer abbildbar wären
Nachteile
Fazit Variante 1
Diese Variante eignet sich besonders gut für reine Reporting- und Analysezwecke, bei denen externe Daten mit den Plandaten virtuell verrechnet und gemeinsam ausgewertet werden sollen - ohne dass die Ergebnisse aktiv im Planungsprozess weiterverarbeitet werden müssen. Die Stärke liegt in der Flexibilität der Datasphere-Modellierung.
Mit dem Q4 2025 Release hat SAP die Externen Live-Versionen für Seamless-Planning-Modelle eingeführt. Dieses Feature ermöglicht es, Fact Views aus SAP Datasphere direkt als Versionen in ein SAC-Planungsmodell einzubinden - ohne jegliche Datenreplikation. Die Daten werden live aus Datasphere gelesen und verhalten sich aus SAC-Sicht so, als wären sie Teil des Modells.
Variante 2 nutzt dieses neue Feature, um die Discount-Daten als Externe Live-Version an das Planungsmodell anzubinden und dann über Formel-Referenzen in den Planungskontext einzubinden.
Technische Umsetzung
Datasphere View vorbereiten: Die Discount-Daten müssen als Fact View in Datasphere bereitgestellt werden. Diese View muss im selben Space liegen wie das Seamless-Planning-Modell (oder mit diesem Space geteilt sein) und für die Consumption freigegeben (Exposed) sein.
Vorteile
Anders als bei Variante 1 sind die Daten direkt im Planungsmodell sichtbar - kein separates Analytics Model erforderlich.
Der Planer sieht die Auswirkungen seiner Eingaben sofort, ohne die Plandaten erst publizieren zu müssen.
Über die Konfiguration CONFIG.READ_CALCULATED_MEMBER_VALUES = ON in Advanced Formulas lassen sich die Calculated Measures auch innerhalb von Data Actions lesen und für Berechnungen verwenden.
Nachteile
Die Discount-Werte aus der Externen Live-Version sind nicht überschreibbar. Es handelt sich um reine Referenzdaten als Formelergebnis - kein Persistieren.
Die Berechnungslogik in SAC über Advanced Formulas / Calculated Members hat Einschränkungen, z.B. bei kontextabhängigen Berechnungen, NULL-Handling oder verschachtelten LOOKUPs.
Fazit Variante 2
Variante 2 ist ideal, wenn externe Referenzdaten live im Planungskontext angezeigt und in Berechnungen einbezogen werden sollen. Sie verbindet Echtzeit-Zugriff mit direkter Integration im Planungsmodell, inklusive Nutzbarkeit in Data Actions. Die Grenzen liegen bei komplexer Berechnungslogik und wenn Werte persistiert oder manuell überschrieben werden müssen.
Die dritte Variante nutzt ebenfalls die Externe Live-Version, geht aber einen entscheidenden Schritt weiter: Die externen Daten werden nicht nur referenziert, sondern über eine Data Action aktiv in die planbare Version des Modells kopiert. Damit stehen die Discount-Werte anschließend als „echte“ Plandaten zur Verfügung und können in allen weiteren Planungsschritten genutzt werden.
Technsiche Umsetzung
Externe Live-Version einrichten: Wie bei Variante 2 wird die Discount-View aus Datasphere als Externe Live-Version am Planungsmodell angebunden.
Data Action erstellen: Eine Data Action wird angelegt, die die Discount-Daten aus der Externen Live-Version in die aktive Planungsversion kopiert. Dies kann über einen Copy-Schritt oder ein Advanced-Script erfolgen.
Trigger integrieren: Die Data Action kann manuell per Button in der Story ausgelöst werden oder in eine Multi Action integriert werden, die mehrere Schritte orchestriert.
Weiterverarbeitung: Nachdem die Discount-Daten in der aktiven Version persistiert sind, stehen sie wie jede andere Planungskennzahl zur Verfügung.
Vorteile
Wie in Variante 2 sind die Daten direkt im Planungsmodell sichtbar ohne ein separates Analytics Model und der Planer sieht die Auswirkungen seiner Eingaben sofort, ohne die Plandaten erst publizieren zu müssen.
Die Discount-Daten sind nach dem Copy vollwertige Planungsdaten und können in allen Planungsfunktionen genutzt oder bei Bedarf auch manuell überschrieben werden
Durch die Persistierung entsteht ein Snapshot der Rabattdaten zum Zeitpunkt der Planung. Ändern sich die externen Daten in Datasphere nachträglich, bleibt das Planungsergebnis davon unberührt - ein wichtiger Aspekt für die Nachvollziehbarkeit und Revisionssicherheit der Planung.
Nachteile
Die Daten sind nur so aktuell wie die letzte Ausführung der Data Action. Änderungen an den Discount-Daten in Datasphere werden erst nach erneutem Kopieren sichtbar.
Data Action mit Script/Copy-Logik muss entwickelt und getestet werden. Bei komplexeren Szenarien (verschiedene Granularitäten, fehlende Members) kann dies aufwendig sein
Fazit Variante 3
Variante 3 ist die umfassendste Lösung, wenn die externen Daten nicht nur angezeigt, sondern aktiv im Planungsprozess genutzt werden sollen. Sie kombiniert die Live-Anbindung an Datasphere (kein initialer Datenimport nötig) mit der vollen Planungsfunktionalität der SAC.
Die folgende Tabelle fasst die wesentlichen Unterschiede der drei Varianten zusammen:
| Kriterium | Variante 1: Analytics Model |
Variante 2: Formel-Referenz |
Variante 3: Data Action Copy |
| Daten-Aktualität | Erst nach Publish der Plandaten | Echtzeit, auch auf privaten Versionen | Zum Zeitpunkt der Data-Action-Ausführung |
| Planbarkeit der Kennzahl | Nein (nur lesend im Analytics Model) | Nein (Calculated Member, read-only) | Ja (nach Copy in aktive Version) |
| Nutzung in Data Actions | Nicht möglich | Eingeschränkt (Formelreferenz) | Voll nutzbar |
| Berechnungslogik | Datasphere View (SQL, Joins etc.) | SAC Calculated Measures | SAC Data Action |
| Komplexe Berechnungen | Sehr gut (SQL, Joins, Unions) | Eingeschränkt (Formel-Limitierungen) | Mittel (Data Action Scripting) |
| Entwicklungsaufwand | Gering (Join-View + Analytic Model) | Gering (Live-Version + Calculated Measures) | Gering (Live-Version + Data Action Script) |
Die Wahl der richtigen Variante hängt letztlich vom konkreten Anwendungsfall ab. Für reines Reporting reicht Variante 1 völlig aus. Wenn Echtzeit-Referenzdaten im Planungsmodell benötigt werden, ist Variante 2 der eleganteste Weg. Und wenn die externen Daten aktiv im Planungsprozess weiterverarbeitet werden sollen, führt kein Weg an Variante 3 vorbei.
Wer die drei Varianten aufmerksam gelesen hat, wird feststellen, dass jede ihre Stärken hat - aber keine alle Stärken vereint. Variante 1 bietet die mächtige Datasphere-Modellierung, aber die Daten sind nicht im Planungsmodell. Variante 3 bietet die volle Planungsintegration, aber die Berechnungslogik liegt in SAC-Data-Actions, was bei komplexen Anforderungen an Grenzen stösst.
Die „Dream-Variante“ wäre eine Kombination der Varianten: Man nutzt die volle Leistungsfähigkeit des Datasphere-Toolsets für die Berechnungslogik und bindet das Ergebnis dann als Externe Live-Version an das Planungsmodell an. Am Ende wäre nur noch ein einfacher Copy-Schritt per Data Action nötig, um die berechneten Werte in die aktive Planungsversion zu übernehmen.
Dieser Ansatz wäre besonders dann attraktiv, wenn die Berechnungslogik komplex wird und die SAC Advanced Formulas nicht ausreichen. Viele Unternehmen haben SQL-Experten, die sich mit dem Datasphere-Tooling deutlich leichter tun als mit der SAC-Formelsprache. Man würde also die Stärke von Datasphere mit der Stärke von SAC Planung kombinieren.
Warum es (noch) nicht funktioniert
Leider scheitert dieser Ansatz an einer technischen Einschränkung: Man kann keine Externe Live-Version anbinden, deren zugrunde liegende Datasphere-View auf der Fakt-Tabelle des eigenen Planungsmodells basiert.
Der Grund für diese Einschränkung liegt vermutlich in der Vermeidung von Zirkelabhängigkeiten: Wenn ein Modell eine Externe Version einbindet, die wiederum auf den eigenen Daten basiert, entsteht theoretisch ein Zirkelbezug. Aus unserer Sicht ist diese Einschränkung allerdings nicht zwingend. Denn: Die Daten einer Externen Live-Version sind im Seamless-Planning-Modell in Datasphere gar nicht sichtbar. Wenn man z.B. Actuals Live an ein Planungsmodell anbindet, sieht man die Actuals-Daten nur in der SAC direkt auf dem Modell - in Datasphere in der Fakt-Tabelle des Modells sind sie nicht enthalten. Die Externe Version wird erst in der SAC als zusätzliche Schicht „darauf gelegt“, ähnlich einem UNION. Die darunterliegende Fakt-Tabelle bleibt davon unberührt.
Zugegebenermassen: Von aussen ist nicht exakt ersichtlich, welches SQL das Seamless-Planning-Modell für die Externen Versionen aufbaut. Es kann also technische Gründe geben, die uns nicht transparent sind. Fakt ist aber: Wenn die Externe Version lediglich als zusätzlicher UNION-Layer fungiert und die Fakt-Tabelle nicht verändert, wäre eine Self-Reference technisch denkbar - sofern das System die Auflösungsreihenfolge sauber handhabt.
Unser Wunsch an SAP: Externe Live-Versionen wären noch deutlich mächtiger, wenn diese Self-Reference möglich wäre. Die Use Cases in Kombination mit Datasphere-Berechnungslogik wären enorm vielfältig. Vielleicht wird diese Einschränkung in einem künftigen Release adressiert - die Architektur lässt es aus unserer Sicht zu.
Möchten Sie das volle Potenzial von Seamless Planning in Ihrem Unternehmen nutzen? Sprechen Sie uns an, um die passende Integrationsstrategie für Ihren Use-Case zu entwickeln.