Funktioniert. Aber wie lange noch?
Krombachers Data-Science-Team hatte sich über die Jahre einen eigenen Stack auf AWS aufgebaut: SageMaker fürs Model Training, Lambda und API Gateway fürs Model Serving, Dagshub als gehostetes MLflow, DVC für Datenversionierung, Airflow für Scheduling. Jedes Tool für sich funktionierte, aber ein einzelnes Modell-Deployment erforderte manuelle Anpassungen in vier verschiedenen Services. Der Wartungsaufwand wuchs mit jedem neuen Projekt. Model Drift und Data Drift konnten nicht systematisch erkannt werden: Es gab schlicht kein zentrales Monitoring, das Abweichungen in Datenqualität oder Modellperformance automatisch erkennt.
Datenprodukte entstanden mehrfach an verschiedenen Stellen. Es gab keine Single Source of Truth, keine einheitlichen Qualitätsprozesse, kein zentrales Monitoring. Die Sorge, dass produktive Modelle irgendwann unbemerkt falsche Ergebnisse liefern, war real; auch wenn es bis dahin noch nicht passiert war.
Die bestehende Lösung funktionierte – noch. Doch statt auf den ersten Ausfall zu warten, entschied sich Krombacher bewusst für den Wechsel, solange der Handlungsspielraum noch da war.

Databricks oder Snowflake?
Databricks oder Snowflake? Diese Entscheidung hatte Krombacher bereits mit verschiedenen Beratern beleuchtet. Gemeinsam mit ruhrdot führte das Team anschließend eine strukturierte Plattformbewertung durch, basierend auf konkreten Anforderungen statt auf Versprechen aus dem Marketing.
Databricks überzeugte im Bereich Machine Learning und GenAI am meisten. Die Plattform fühlt sich an wie die Werkzeuge, die Data Scientists ohnehin nutzen: Notebooks, Python, MLflow. Kein Framework-Wechsel, kein Umlernen, keine Medienbrüche, sondern eine natürliche Erweiterung der bestehenden Arbeitsweise. Auch Snowflake hinterließ einen guten Eindruck – für den ML/AI-Fokus von Krombacher brachte Databricks jedoch entscheidende Funktionen mit, die das Team im Custom Stack selbst hätte bauen müssen: automatisches Monitoring für Modell- und Datenqualität, durchgängige Lineage von der Datenquelle bis zum Modell-Output, und Model Serving ohne eigene Infrastruktur.
Krombachers IT ist stark SAP-getrieben – genau hier spielt Databricks seine Stärken aus. Über die Integration mit SAP Datasphere (per HANA Native oder zukünftig Zero-Copy Delta Sharing) gelangen Daten kontrolliert in den Unity Catalog und stehen für Analytics und ML zur Verfügung. Prognosen und Modellergebnisse werden anschließend zurück in SAP bereitgestellt, z. B. für Reports in der SAP Analytics Cloud. Die Fachbereiche bleiben in ihrer vertrauten SAP-Arbeitsweise, profitieren aber von zusätzlichen ML-Insights. Gleichzeitig bindet Databricks auch Non-SAP-Quellen wie Shopify, IoT, PayPal oder Klarna effizient an; dort, wo SAP-Produkte heute oft weniger flexibel sind.
Krombacher entschied sich für Databricks als Developer-First-Plattform: geringe Wartungsaufwände, aber genügend Flexibilität und Freiräume für ein team, das technische Tiefe schätzt.
Die Bedenken: Kosten, Vendor Lock-In und fehlende Flexibilität wurden offen adressiert. Am Ende überwog die Überzeugung: Die Plattform lässt genügend Gestaltungsspielraum.
Kein Code ohne Strategie
Bevor die Migration startete, entwickelte Krombacher gemeinsam mit ruhrdot eine Data Strategy, die deutlich über einen reinen Plattformwechsel hinausgeht. Im Fokus stand die Architekturfrage: Wie muss eine Daten- und KI-Plattform aufgebaut sein, damit sie heutige ML-Use-Cases zuverlässig trägt und gleichzeitig die Grundlage für GenAI- und Agentic-AI-Szenarien schafft?
Die Entscheidung fiel auf Databricks als Lakehouse-Plattform: als einheitliche Grundlage für Data Engineering, Data Science und AI. Der Ansatz war bewusst pragmatisch statt overengineered: Unity Catalog sauber nach bewährten Best Practices strukturiert, ETL-Pipelines zielgerichtet designt und Compute passgenau dimensioniert: von SQL Warehouses bis zu Spark-Clustern. Leitprinzip: so wenig Komplexität wie möglich, so viel Struktur wie nötig. Grundlage dafür waren Erfahrungswerte aus zahlreichen Databricks-Projekten, die ruhrdot über Jahre aufgebaut und verfeinert hat. Mindestens genauso wichtig wie die Technik: Enablement, Sparring und Change Management. ruhrdot begleitete das Krombacher-Team dabei als Partner auf Augenhöhe.
„Wir hatten zu jeder Zeit das Gefühl, bei der ruhrdot. sehr gut aufgehoben zu sein und zu jeder Zeit eine höchst vertrauensvolle Zusammenarbeit auf Augenhöhe zu genießen!”
Fabian Wörenkämper, Senior Full Stack Data Scientist, Krombacher

Zielarchitektur: SAP + Databricks im Lakehouse
In rund zwölf Monaten entstand bei Krombacher eine einheitliche Data-&-AI-Workbench auf Databricks. Daten aus SAP Datasphere, SAP BW, Shopify, IoT-Sensoren der Betriebsdatenerfassung sowie PayPal, Klarna und weiteren Quellen laufen heute in einer zentralen Lakehouse-Architektur zusammen. Rohdaten werden in Databricks verarbeitet, Prognosen und Scores fließen zurück in die SAP-Welt. So können Fachabteilungen ML-Ergebnisse nutzen, ohne ihre gewohnte SAP-Umgebung zu verlassen.
Die Plattform unterstützt den gesamten ML-Lebenszyklus: von Ingestion und Feature Engineering über Training und Deployment bis zu Batch- und Realtime-Inferenz, Monitoring und automatisiertem Retraining. Mit Lakebase als Online Feature Store stehen Features in Echtzeit für Serving-Endpoints bereit: etwa für das Loyalty-Programm. Unity Catalog bildet dabei die zentrale Governance-Schicht für Berechtigungen, Lineage und saubere Trennung von Verantwortlichkeiten.
Auch der Betrieb ist konsequent standardisiert: Die Infrastruktur wird per Infrastructure as Code ausgerollt: versioniert, reproduzierbar und als Template wiederverwendbar. Neue ML-Projekte starten dadurch nicht mehr mit manueller Basis-Konfiguration, sondern mit einer vorkonfigurierten Umgebung inklusive Compute, Storage, Berechtigungen und CI/CD: in kurzer Zeit statt in mehreren Arbeitstagen.
„Durch die Versionierung der Infrastruktur, habe ich insgesamt deutlich weniger Sorgen und Bauchschmerzen als früher. Robustheit kann hier tatsächlich gefühlt werden.”
Fabian Wörenkämper, Senior Full Stack Data Scientist, Krombacher
Klassisches ML ist erst der Anfang. Durch den Lakehouse-Ansatz, Unity Catalog als Governance-Layer und die nativen Features der Databricks Data Intelligence Platform ist die Architektur von Beginn an auf GenAI vorbereitet: bis hin zu Agentic AI, also Agentensystemen, die autonom auf Unternehmensdaten arbeiten und Entscheidungen vorbereiten, z. B. als Unterstützung für den Außendienst bei der proaktiven Besuchsvorbereitung.
Von der Abfüllung bis zur Kampagne: KI im Einsatz
- Demand Forecasting
Wie viel Krombacher wird in den kommenden Tagen nachgefragt? Diese Frage wurde lange auf Basis von Erfahrungswerten beantwortet. Heute liefert ein ML-gestützter Forecasting-Service präzise Absatzprognosen, die direkt in die Abfüllplanung einfließen: zuverlässigere Planung, optimierte Abfüllprozesse, spürbare Entlastung der Produktionssteuerung. - Abwasserprognose
ML-Modelle prognostizieren auf Basis von IoT-Sensorendaten aus der Betriebsdatenerfassung die anfallenden Abwassermengen. So kann Krombacher die kommunalen Klärwerke frühzeitig und zuverlässig über zu erwartende Einleitungen informieren - vorausschauend statt reaktiv. - Loyalty-Programm
Customer Segmentation und Customer Lifetime Value Modelle liefern die Grundlage für datengetriebene Kampagnen: gezielt statt Gießkannenprinzip. Die Ergebnisse werden über Model Serving als API bereitgestellt, sodass andere Fachbereiche direkt darauf zugreifen und in ihre Prozesse integrieren können.






.png)














.png)



