SAP BDC Connect bringt SAP Data Products ohne Replikation nach Snowflake und Ergebnisse wieder zurück. Wir zeichnen an einem Referenzszenario aus der Konsumgüterbranche nach, wie daraus Mehrwert entsteht und worauf man vorher achten sollte.
Prognosemodelle schauen nicht über den SAP-Tellerrand
Ein Prognosemodell in SAP kennt jede Buchung der letzten Jahre, in SAP. Sein Blick endet an der Systemgrenze. Die Hitzewelle in zwei Wochen, die Handelsaktion des Wettbewerbers, der Nachfrageschub im Onlineshop: all das entsteht außerhalb. All das ist entscheidend, um Absatzprognosen aufzustellen.
Damit beschreibt das Modell die Vergangenheit sauber und die Zukunft nur so weit, wie sie der Vergangenheit ähnelt. Genau dort entsteht Ungenauigkeit, die Ressourcen und am Ende Geld kostet: Überbestand bindet Kapital, Fehlmengen kosten Umsatz.
Die Daten, die es braucht, um diese Lücke zu schließen, finden sich nicht in SAP. Sie müssen von externen Quellen hinzugefügt werden. Bisher wurde das über Ladestrecken organisiert, die jemand entwickeln und warten musste. Mit SAP BDC Connect für Snowflake gibt es dafür einen kürzeren Weg.
Zeichnen wir auf, was wir zusammenziehen:
Ein Konsumgüterhersteller plant den Absatz je Artikel, Distributionszentrum und Kalenderwoche. Bei 1.400 Artikeln, sechs Distributionszentren und einem Horizont von 13 Wochen entstehen so gut etwa 100.000 Datenpunkte. Jede Woche neu. An ihnen hängen Produktionsaufträge, Einkaufsmengen und gebuchte Lkw-Slots.
Die Grundlage liefert SAP: Verkaufsbelege zeigen die Nachfrage, Rechnungen den tatsächlichen Abverkauf, Bestände die aktuelle Lage, der Materialstamm ordnet jeden Artikel einer Marke, einer Charge und einer Saison zu. Diese Inhalte stehen in der SAP Business Data Cloud als Data Products bereit.
Dem Modell fehlen zahlreiche Treiber. Welche hängt vom Geschäft, von der Branche, von der Jahreszeit, von der Region ab. Diese zu benennen und zu finden, braucht Fachexpertise und Recherche. Vier Beispiele:
- Wetter. Hitzewochen treiben Getränke und Eis, Regen bremst den Grillbedarf.
- Aktionen. Eigene und fremde Kampagnen verschieben Absatz zwischen Wochen und Artikeln.
- Wettbewerbspreise. Preisbewegungen verändern Marktanteile innerhalb weniger Tage.
- Digitale Nachfragesignale. Suchvolumen und Klickdaten zeigen Bewegung, bevor der
Auftragseingang sie sieht.
So soll es am Ende aussehen: eine wöchentliche Prognose, die SAP-Historie und diese Signale gemeinsam auswertet und die Disposition dort erreicht, wo sie ohnehin arbeitet.
Was sich technisch geändert hat
Ein SAP-Integrationsprojekt verbrauchte bisher Ressourcen vor allem in den Bereichen: Extraktion und Integration der Daten. Seit SAP die externen ODP-RFC-Zugriffe (SAP Note 3255746) begrenzt hat, steht dieser Weg zusätzlich unter Druck (Was das für bestehende Strecken bedeutet, haben wir hier aufgeschrieben).
BDC Connect setzt eine Ebene höher an. Der Zerocopy-Connector ist seit dem 4. Mai 2026 allgemein verfügbar. Wer damit arbeitet, arbeitet also mit einem offiziell lizensierten Produkt
Das Vorgehen: Die SAP-Administration gibt Data Products im Katalog der Business Data Cloud für ein Snowflake-Konto frei. Auf der Snowflake-Seite richtet ein Administrator den
Zero-Copy-Connector ein und bindet die freigegebenen Produkte als Catalog-Linked Database ein. Die Daten bleiben dabei in der Business Data Cloud. Ihre fachliche Bedeutung kommt mit:
Snowflake legt in der angebundenen Datenbank automatisch ein Schema an, das Semantic Views aus der SAP Core Schema Notation enthält. Die Einrichtung ist in der
Snowflake-Dokumentation beschrieben.
Der Rückweg läuft über denselben Mechanismus: Ergebnisse aus Snowflake gehen als eigenes Data Product zurück in den SAP-Katalog.
Zwei Systeme, ein Datenraum. Die Daten bleiben in beide Richtungen dort, wo sie entstehen. Die Zeit fließt in Modellierung und Fachlogik statt in Extraktion.
Zwei Wege, je nach Ausgangslage. SAP und Snowflake bieten die Integration in zwei Varianten an. SAP BDC Connect für Snowflake richtet sich an Unternehmen, die Snowflake bereits betreiben. Wer bei Snowflake neu einsteigt, findet unter dem Namen SAP Snowflake eine
zertifizierte Variante innerhalb der Business Data Cloud. Die Business Data Cloud ist in beiden Fällen die Voraussetzung.
Die Architektur in fünf Schritten
Schritt 1: SAP-Daten anbinden
Die SAP-Seite gibt die benötigten Data Products frei, auf der Snowflake-Seite werden sie per
Zero-Copy-Connector als Catalog-Linked Database eingebunden. Sie stehen dort als Tabellen zur Verfügung, ergänzt um die automatisch erzeugten Semantic Views mit der fachlichen Bedeutung.
Schritt 2: Externe Daten dazuholen
Wetterprognosen, Feiertags- und Ferienkalender sowie Marktdaten kommen über den
Snowflake-Marketplace hinzu, ebenfalls als Share statt als Ladestrecke. Eigene Quellen wie
Shop- und Aktionsdaten laufen über die bestehenden Strecken. Damit sind Kernsystem, Markt
und digitale Kanäle an einem Ort verfügbar.
Schritt 3: Datenbasis aufbauen
Aus SAP-Daten und externen Signalen entsteht in einem eigenen Schema die Modellbasis, auf der Granularität Artikel, Standort und Woche. Dynamic Tables halten sie nach definiertem Target
Lag aktuell, den Ladelauf stößt die Plattform selbst an.
Schritt 4: Prognose rechnen
Ein Zeitreihenmodell rechnet über alle Artikel und Standorte und bezieht die externen Signale
als erklärende Größen ein. Für den Einstieg genügen die ML Functions der Plattform, eigene
Modelle lassen sich mit Snowpark und der Model Registry trainieren und betreiben.
Ein Punkt entscheidet hier über die Qualität: Externe Treiber müssen für den Prognosehorizont
selbst als Vorhersage vorliegen. Trainiert wird auf dem Wetter, das war. Gerechnet wird auf dem
Wetter, das erwartet wird. Die Wettervorhersage bringt ihre eigene Unsicherheit mit, und die
wächst mit dem Horizont. Für Aktionen gilt dasselbe: Der eigene Plan ist bekannt, der des
Wettbewerbers bleibt eine Annahme. Wer diese Trennung sauber zieht, bekommt ein Modell, das auch im Betrieb hält.
Schritt 5: Ergebnis zurückgeben
Das Modell schreibt die Prognose in eine Iceberg-Tabelle mit Primärschlüssel. Share Back
veröffentlicht sie als eigenes Data Product im Katalog der Business Data Cloud. Von dort
verwendet das SAP-Reporting sie weiter, etwa in SAP Analytics Cloud, und meldet auffällige
Abweichungen von der laufenden Planung an die Disposition.
Was sich dadurch verändert
Bessere Prognosen: Das Modell sieht Treiber, die eine reine Fortschreibung der Historie
übersieht. Wetter und Aktionen erklären genau die Ausschläge, an denen Planung teuer wird.
Kürzerer Weg zum Ergebnis: Am Anfang stehen eine Freigabe und die Einrichtung des
Connectors. Die Wochen, die sonst in ein Extraktionsprojekt fließen, gehen in Modellierung und
Fachlogik.
Vertrauen in die Zahl: Herkunft und Verwendung bleiben über beide Welten nachvollziehbar.
Die Disposition sieht, worauf ein Wert beruht. Erst diese Nachvollziehbarkeit bringt jemanden
dazu, Empfehlungen und Prognosen in sein Handeln zu übernehmen.
Wo sind die Grenzen?
Berechtigungen bleiben im Quellsystem. Der Share überträgt Daten, das SAP-Berechtigungskonzept bleibt zurück. Wer im Snowflake-Konto Zugriff auf die Catalog-Linked Database hat, sieht deren Inhalt. Rollen, Masking und Row Access Policies gehören damit in die Konzeption, bevor der erste Share läuft.
Der Katalog entscheidet über den Umfang. Das Szenario setzt voraus, dass Verkaufsbelege, Fakturadaten, Bestände und Materialstamm als Data Products bereitstehen. Der Katalog der Business Data Cloud wächst und deckt einen definierten Ausschnitt ab. Erster Schritt in jedem Vorhaben: prüfen, was tatsächlich freigegeben ist.
Aktualität ist eine Konfigurationsfrage. Das Sync-Intervall des Connectors lässt sich zwischen 30 Sekunden und 24 Stunden setzen, voreingestellt ist ein Tag. Dazu kommt der Refresh-Rhythmus des Data Products auf der SAP-Seite. Für eine Wochenprognose spielt das eine untergeordnete Rolle. Sobald daraus ein Alert für die Disposition wird, müssen beide Werte bewusst ausgelegt werden.
Zero-Copy spart die Kopie, die Kosten bleiben. Rechenleistung in Snowflake fällt weiter an, ebenso die Kapazität in der Business Data Cloud. Der Business Case trägt sich über die bessere Entscheidung. Die eingesparte Datenkopie ist ein willkommener Nebeneffekt.
Unsere Empfehlung
Das Spannende an BDC Connect ist neben der gesparten Kopie vor allem eines: SAP-Daten lassen sich schnell um externe Informationen anreichern, und das Ergebnis findet den Weg zurück in die Umgebung, in der die Fachbereiche ohnehin arbeiten.
Wer SAP BDC und Snowflake bereits parallel betreibt, zieht jetzt einen Use Case durch. Ein abgegrenztes Thema, ein Fachbereich, eine Kennzahl, an der sich der Nutzen zeigen lässt. Wer bei einer der beiden Plattformen am Anfang steht, prüft die beiden Wege aus dem Abschnitt oben und entscheidet danach.
Das ist der Kipppunkt: Daten hören auf, Bericht zu sein, und fangen an, Entscheidungen zu
tragen.
Was areto dabei macht
- Wir begleiten Teams von der ersten Standortbestimmung bis zur produktiven Strecke.
- Wir klären den Use-Case und den bestehenden Datenbestand mit Blick auf die Qualität ihrer Daten und mögliche Anreicherungsoptionen aus externen Quellen.
- Wir bewerten die SAP-Datenlandschaft, entwerfen die Architektur für die Anbindung, bauen die Modellbasis auf und übergeben an den Fachbereich.
Technologie ist für uns kein Selbstzweck, der Maßstab ist die Entscheidung, die am Ende besser wird.
Sie betreiben SAP BDC und Snowflake und suchen den ersten Use Case?
Lassen Sie uns gemeinsam prüfen, was am schnellsten trägt. Wir freuen uns auf Ihren Kontakt.