Daten-Foundation für B2B-Industrie: Forecasting, After-Sales, Service-Datenflüsse

In B2B-Industrie-Setups ist die Daten-Foundation selten ein Snowflake-Projekt mit Commerce-Use-Case obendrauf. Sie ist ein Projekt zwischen S/4HANA oder ECC, einem CRM (oft Salesforce), einem Service-Tool (ServiceNow, SAP Service Cloud oder eigenentwickelt), einem MES und — neuerdings — IoT-Plattformen mit Sensordaten aus dem Feld. Wer hier die Commerce-Logik aus dem B2C eins-zu-eins übernimmt, baut eine Foundation, die nach Launch Reporting-Dashboards trägt, aber bei der ersten echten Industrie-Frage zerbricht: "Welche Ersatzteile werden wir in Q3 in Region Süd brauchen, abhängig davon, welche Anlagen 2022 ausgeliefert wurden?"

Dieser Beitrag zeigt drei Use Cases, die sich auf einer sauber gebauten Snowflake-Foundation für B2B-Industrie schnell zünden lassen — Forecasting, After-Sales-Prediction und Service-Datenfluss zurück in den Commerce —, und beschreibt, was an der ERP-/CRM-/Service-Anbindung Standard ist, was Maßarbeit braucht und wo die Lessons aus Industrie-Projekten zwischen Sicherheits-, Verbindungs- und Power-Tool-Herstellern liegen.

Im B2C-Commerce ist die Datenwelt überschaubar: Sessions, Bestellungen, Kunden, Produkte, Marketingkanäle, ein bisschen Loyalty. In der B2B-Industrie kommt eine zweite Welt dazu, die nicht im Shop entsteht — und die in vielen Foundation-Projekten entweder zu spät oder gar nicht angebunden wird.

Service-Tickets sind die kleinste, oft unterschätzte Einheit. Ein Techniker dokumentiert, dass an Anlage X die Komponente Y getauscht wurde, dass die Schraubverbindung Z Verschleißspuren zeigte und dass der Kunde bei der Gelegenheit nach Z-Ersatzteilen gefragt hat. Diese Information ist im Service-Tool. Sie ist nicht im Shop, nicht im CRM und meist nicht im ERP. Ohne sie ist jede Re-Order-Empfehlung im B2B-Portal ein Rateschüss.

Wartungszyklen und Lifecycle-Daten sind die zweite Schicht. B2B-Industrie-Produkte haben Lebenszyklen von fünf bis fünfzehn Jahren — bei einigen Hersteller-Setups deutlich länger. Wer eine Foundation auf einem 24-Monats-Fenster baut (typisch im Retail), verliert die Hälfte der Information, die für After-Sales-Vorhersagen relevant ist.

Sensor- und IoT-Daten sind die dritte Schicht. Vibration, Temperatur, Druck, Zykluszahlen — moderne Anlagen liefern diese Daten kontinuierlich. Snowflake hat mit dem Manufacturing-Data-Cloud-Angebot und Partnern wie HighByte, Crosser oder Cirrus Link eine Architektur etabliert, in der OT- und IT-Daten in derselben Plattform landen. Was vor fünf Jahren noch ein eigenständiges Industrial-IoT-Projekt war, ist 2026 ein Layer in der Foundation — wenn die Foundation entsprechend geplant ist.

Stammdaten-Hierarchien und Vertretungsregeln sind das vierte, leiseste Thema. In der B2B-Industrie bestellt selten ein einzelner Kunde. Es bestellt eine Einkaufsorganisation für mehrere Werke, mit unterschiedlichen Lieferadressen, mit Vertretungsregeln im Urlaubsfall, mit Genehmigungsschwellen je nach Position. Diese Logik liegt im ERP, im CRM und teils im Shop verteilt. Wer sie in der Snowflake-Foundation nicht sauber modelliert, baut Forecasts auf Kunden-IDs, die in der Realität gar nicht die Bestellung auslösen.

Die Konsequenz ist nicht akademisch. Sie zeigt sich an dem Tag, an dem die erste Forecast-Auswertung dem Vertriebsleiter vorgelegt wird — und der sagt: "Das kann nicht stimmen, das sind drei verschiedene Werke desselben Konzerns."

Eine Snowflake-Foundation, die ERP, CRM, Service und IoT zusammenführt, ist kein Selbstzweck. Sie ist die Voraussetzung für drei Use Cases, die in B2B-Industrie-Projekten regelmäßig den ersten Business Case liefern.

1. Forecasting — Mengen, Saisonalität, Kapazitätsplanung. Klassisches Demand-Planning bekommt durch Machine Learning eine andere Qualität. Gradient-Boosting-Verfahren (XGBoost, LightGBM) und LSTM-Modelle reduzieren Forecast-Fehler in Industrie-Studien um 20 bis 50 Prozent gegenüber statistischen Standardverfahren. Voraussetzung ist eine Foundation, die Bestellhistorie, Saisonalitäts-Signale, Marketing-Aktivitäten und externe Treiber (Wetter, Branchenindizes, Projekt-Pipeline aus dem CRM) in einer modellierten Schicht zusammenführt — typischerweise in dbt-Modellen mit klar getrennten Staging-, Intermediate- und Mart-Layern. Was Snowflake hier liefert, ist die Rechenleistung für tausende SKU-Forecasts parallel, nicht die ML-Magie selbst.

2. After-Sales — Re-Order-Wahrscheinlichkeit, Wear-out-Signale, Verschleißteile-Vorhersage. Dies ist der Use Case, der Industrie-CIOs am schnellsten überzeugt — weil er einen Margenhebel im Ersatzteilgeschäft hebt, das in vielen Hersteller-Bilanzen die profitabelste Sparte ist. Drei Signale gehen zusammen: Bestellhistorie (wer hat wann was gekauft), Service-Tickets (wo wurde wann getauscht) und — wenn vorhanden — Sensordaten (wo zeigen Anlagen Anomalien). Das Ergebnis ist eine Re-Order-Wahrscheinlichkeit pro Kunde × Artikel × Zeitfenster, die als Empfehlung im B2B-Portal, als Lead-Liste im CRM oder als Trigger für Outbound-Service-Calls landet. Wichtig: Diese After-Sales-Prediction ist nicht dasselbe wie Predictive Maintenance. Predictive Maintenance prognostiziert den Ausfall einer konkreten Anlage anhand von Sensordaten — eine Engineering-Disziplin, die tief in OT-Daten und Modellen wie Remaining-Useful-Life-Schätzungen sitzt. After-Sales-Prediction prognostiziert das Kauf- und Service-Verhalten ganzer Kundensegmente — eine Commerce- und CRM-Disziplin. Beide profitieren von derselben Foundation, beantworten aber unterschiedliche Fragen.

3. Service-Datenfluss — Field-Service ↔ Commerce. Der dritte Use Case ist der, der am häufigsten unterschätzt wird. Ein Techniker, der vor Ort eine Komponente tauscht, erzeugt eine Information, die in Echtzeit eine Re-Order-Empfehlung im Kundenportal auslösen sollte. Heute liegt diese Information meist auf einem mobilen Service-Gerät, wandert in ServiceNow oder SAP Service Cloud und endet dort. Wer den Datenfluss schließt — Service-Ticket → Snowflake → Event in Commerce-Plattform → Re-Order-Empfehlung — schließt nicht nur eine Datenlücke. Er macht aus jedem Wartungseinsatz einen halbautomatischen Vertriebskontakt.

Die Anbindung der Quellsysteme an Snowflake ist 2026 keine Erfindungsleistung mehr — die Mehrheit der Pfade ist beschrieben. Worauf es ankommt, ist die Trennung zwischen technischer Anbindung (gibt es als Standard) und semantischer Modellierung (bleibt Maßarbeit).

Standard sind die Connectoren. Für SAP S/4HANA und ECC sind im Markt vier Hauptpfade etabliert: SAP-native ODP-/CDS-View-Extraktion über SAP Datasphere, Drittanbieter-CDC auf Datenbank-Ebene (BryteFlow, Fivetran HVR, SNP Glue, Theobald), klassisches Batch-ETL über das SAP-Application-Layer (eher Auslaufmodell) und — neu für 2026 — SAP Business Data Cloud Connect for Snowflake mit Zero-Copy- und bidirektionalem Zugriff (Verfügbarkeit nach SAP-Roadmap H1 2026). Welcher Pfad trägt, hängt an drei Fragen: Wie sensitiv ist die SAP-Systemlast? Wie viel Business-Logik soll im Source-System bleiben? Wie nah an Echtzeit muss die Replikation sein? Für Salesforce, ServiceNow, HubSpot oder Microsoft Dynamics ist die Standard-Antwort meist ein ELT-Tool (Fivetran, Airbyte, Matillion) mit nativem Connector — schnell aufgesetzt, oft in Tagen statt Wochen.

Maßarbeit ist die Modellierung. Was die Connectoren liefern, sind Tabellen — keine Datenmodelle. Eine Forecast-fähige Foundation braucht eine semantische Schicht, in der Materialnummern, Kunden-Hierarchien, Vertretungsregeln und Zeitvaliditäten so verknüpft sind, dass die ML-Modelle nicht an Inkonsistenzen scheitern. In dbt heißt das: konsequente Trennung zwischen Staging (1:1 zur Quelle), Intermediate (saubere Business-Konzepte) und Marts (Use-Case-spezifische Tabellen für Forecasting, After-Sales-Prediction, Service-Reporting). Wer hier abkürzt, baut ein Reporting-Lager, keine analytische Plattform.

Maßarbeit bleibt auch die Behandlung der Stammdaten-Hierarchien. In B2B-Industrie-Setups ist die Frage "Wer ist der Kunde?" selten trivial. Ein Konzern bestellt für 14 Werke; jedes Werk hat einen technischen Einkäufer, der bestellt, und einen Werksleiter, der genehmigt; im Urlaubsfall springt ein anderes Werk ein. Im ERP sind diese Beziehungen oft mehrstufig modelliert, im CRM teils anders, im Shop nochmal anders. Diese Diskrepanzen früh zu mappen — bevor das erste ML-Modell trainiert wird — entscheidet, ob die Foundation hält oder ob in sechs Monaten eine zweite Welle Modellierungsaufwand nötig wird.

In Industrie-Projekten zwischen Sicherheits-, Verbindungs- und Power-Tool-Herstellern sehen wir das gleiche Muster: Die Technik ist in Wochen aufgesetzt. Die Stammdaten-Diskussion dauert Monate. Wer das umdreht und mit der Stammdaten-Arbeit beginnt, spart sich die Schleifen.