MLOps für SAP Analytics
Stand 2026-09-03
Die meisten ML-Projekte scheitern, nachdem das Modell bereits funktioniert: Ein Churn-Modell, das in einem Notebook gegen ACDOCA-Daten 85 % AUC erreicht, stellt nur 10-20 % des Engineerings dar, das nötig ist, um es sicher in Produktion zu betreiben. Die übrigen 80 % — CI/CD für Modellcode, ein HANA-basierter Feature Store und Drift-Überwachung — trennen ein Modell, das innerhalb von Monaten lautlos verfällt, von einem, das den Kontakt mit echten SAP-Daten übersteht. Dieses Modul ist das Playbook auf Architekturebene: die Applications, Configurations, Executions und Deployments von SAP AI Core mit einem HANA- oder Datasphere-Feature-Store verdrahten, schemaspezifische Fehler (leere BUKRS, Hierarchie-`#`-Werte) abfangen, bevor sie die Produktion erreichen, und die drei Drift-Typen instrumentieren, die entscheiden, wann neu trainiert wird. Berater, die alle vier beherrschen — ML-Engineering, SAP-Datenarchitektur, Monitoring und SAC- oder S/4HANA-Umsetzung —, sind wirklich rar, was diese Arbeit genau in die Architektur- und technische Führungsebene hebt, statt in die der Data Scientists.
Was Sie lernen
- Entwerfen Sie einen vollständigen Modell-Lebenszyklus auf SAP AI Core mit Applications, Configurations, Executions und Deployments — verpacken Sie Trainings- und Serving-Code in Docker-Containern mit hana-ml-Feature-Extraktion, Modellartefakt-Speicherung im BTP Object Store und Endpunkt-Registrierung in SAP AI Launchpad.
- Entwerfen Sie eine Strategie zur Vermeidung von Training-Serving-Skew mit HANA Calculation Views oder persistenten Datasphere-Views als Feature-Berechnungsschicht und hana-ml ModelStorage für versionierte Modellpersistenz, sodass Inferenz-Features byte-äquivalent zu Trainings-Features sind.
- Implementieren Sie eine produktive ML-Monitoring-Pipeline, die zwischen Data Drift, Concept Drift und Label Drift unterscheidet — mit statistischen Tests auf nach HANA zurückgeschriebenen Feature-Verteilungen, verknüpft mit Ground-Truth-Ergebnistabellen, und dargestellt als operatives SAC-Dashboard mit Auslösern über den SAP Alert Notification Service.
- Bauen Sie eine CI/CD-Pipeline für ML-Modellcode, die SAP-datenschema-spezifische Unit-Tests umfasst (die HANA-Feld-Grenzfälle wie leeres BUKRS, Hierarchie-#-Werte und fehlende Geschäftsjahresperioden abdecken), den Build und Push des Docker-Images sowie die automatisierte Erstellung von Executions in SAP AI Core über das ai_core_sdk.
Die Lücke zwischen einem funktionierenden Notebook und einem produktiven ML-System
Der teuerste Fehler in ML-Projekten ist, die Modelltrainingsphase als den Großteil der Arbeit zu betrachten. Ein Gradient-Boosted-Churn-Modell in einem Jupyter-Notebook gegen einen Snapshot von ACDOCA-Daten zu trainieren und dabei 85 % AUC zu erreichen, sind vielleicht 10-20 % des Engineerings, das nötig ist, um dieses Modell in Produktion verlässlich zu machen. Die verbleibenden 80 % sind das, was MLOps adressiert: reproduzierbare Pipelines, kontinuierliche Integration für Modellcode, Deployment-Infrastruktur, Monitoring, Retraining-Auslöser und Rollback-Verfahren. Für SAP-Analytics-Berater besteht die spezifische Herausforderung darin, dass diese 80 % mit SAP AI Core und SAP AI Launchpad auf BTP integriert werden müssen, mit HANA oder Datasphere als Feature Store und mit SAC oder individuellen UIs als Konsumschicht.
Ein Modell, das drei Monate lang lautlos verfällt, bevor es jemand bemerkt — weil sich das Kundenverhalten nach einem saisonalen Aktionszyklus verschoben hat, oder weil ein ETL-Job begonnen hat, in einer wichtigen Feature-Spalte Nullwerte zu produzieren —, ist kein produktives ML-System. Es ist eine technische Belastung. MLOps ist die Disziplin, die den Unterschied macht.
Voraussetzungen
- Praktische Erfahrung auf mittlerem Niveau in SAP-Analytics-Projekten
- Zunächst diese Kernkonzepte durcharbeiten: C087, C032, C083
Lernergebnisse
- Arbeiten Sie ein realistisches Szenario durch: Ein europäischer Industriedistributor betreibt Finanz- und Vertriebsprozesse auf S/4HANA und BW/4HANA.
- Erkennen und vermeiden Sie das Anti-Pattern: Ein Notebook mit guter AUC als „produktionsreif" zu bezeichnen — Das Modell geht ohne Feature Store, CI, Monitoring oder Rollback-Pfad in Produktion und verfällt innerhalb von Monaten lautlos.
- Wenden Sie die Kernentscheidung des Moduls an: Feature-Berechnung: HANA-/Datasphere-View vs. Python-Vorverarbeitung — entscheiden Sie sich dafür, jede Feature-Transformation in eine HANA Calculation View oder eine persistente Datasphere-View zu verlagern.
- Verfolgen Sie die Beherrschung anhand des KPI: Training-Serving-Feature-Parität (Ziel: 0 Feature-Wert-Abweichungen auf einem gemeinsamen Validierungs-Batch; Warnsignal: jede systematische Abweichung).
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.