MLOps for SAP Analytics
As of 2026-10-10
Most ML projects fail after the model already works: a churn model that reaches 85% AUC in a notebook against ACDOCA data represents only 10-20% of the engineering needed to run it safely in production. The other 80% — CI/CD for model code, a HANA-based feature store, and drift monitoring — is what separates a model that decays silently within months from one that survives contact with real SAP data. This module is the architecture-level playbook: wire SAP AI Core's Applications, Configurations, Executions, and Deployments to a HANA or Datasphere feature store, catch schema-specific failures (blank BUKRS, hierarchy # values) before they reach production, and instrument the three drift types that decide when to retrain. Consultants who can do all four — ML engineering, SAP data architecture, monitoring, and SAC or S/4HANA delivery — are genuinely scarce, which is exactly what pushes this work into the architecture and technical-leadership rate tier rather than the data-science one.
What you will learn
- Architect a complete model lifecycle on SAP AI Core using Applications, Configurations, Executions, and Deployments — packaging training and serving code in Docker containers with hana-ml feature extraction, model artefact storage in BTP Object Store, and endpoint registration in SAP AI Launchpad.
- Design a training-serving skew prevention strategy using HANA Calculation Views or Datasphere persistent views as the feature computation layer, and hana-ml ModelStorage for versioned model persistence, so that inference features are byte-equivalent to training features.
- Implement a production ML monitoring pipeline that distinguishes data drift, concept drift, and label drift — using statistical tests on feature distributions written back to HANA, joined to ground-truth outcome tables, and surfaced as a SAC operational dashboard with SAP Alert Notification Service triggers.
- Build a CI/CD pipeline for ML model code that includes SAP-data-schema-specific unit tests (covering HANA field edge cases such as blank BUKRS, hierarchy # values, and missing fiscal periods), Docker image build and push, and automated Execution creation in SAP AI Core via the ai_core_sdk.
The Gap Between a Working Notebook and a Production ML System
The most expensive mistake in ML projects is treating the model training phase as most of the work. Training a gradient-boosted churn model in a Jupyter notebook against a snapshot of ACDOCA data and achieving 85% AUC is perhaps 10-20% of the engineering required to make that model reliable in production. The remaining 80% is what MLOps addresses: reproducible pipelines, continuous integration for model code, deployment infrastructure, monitoring, retraining triggers, and rollback procedures. For SAP analytics consultants, the specific challenge is that this 80% must integrate with SAP AI Core and SAP AI Launchpad on BTP, with HANA or Datasphere as the feature store, and with SAC or custom UIs as the consumption layer. (SAP BTP has since been renamed SAP Business AI Platform, announced at SAP Sapphire 2026.)
A model that degrades silently for three months before anyone notices — because customer behaviour shifted after a seasonal promotion cycle, or because an ETL job started producing null values in a key feature column — is not a production ML system. It is a technical liability. MLOps is the discipline that makes the difference.
Prerequisites
- Intermediate hands-on experience on SAP analytics projects
- Review core concepts first: C087, C032, C083
Outcomes
- Work through a realistic scenario: A European industrial distributor runs finance and sales operations on S/4HANA and BW/4HANA.
- Recognize and avoid the anti-pattern: Calling a notebook with a good AUC 'production-ready' — The model ships without a feature store, CI, monitoring, or rollback path, and degrades silently within months.
- Apply the module's core decision: Feature computation: HANA/Datasphere view vs Python preprocessing — choose Push every feature transformation into a HANA Calculation View or a Datasphere persistent view.
- Track mastery with the KPI: Training-serving feature parity (target: 0 feature-value mismatches on a shared validation batch; red flag: Any systematic mismatch).
Full module available to members. The full module adds: the decision framework · the end-to-end scenario walkthrough · the KPI scorecard · the anti-patterns · the code blocks · the knowledge check · the diagrams.