Das Beste aus zwei Welten: SAP-Prozesswissen trifft auf die KI-Power von Databricks

In der Unternehmenspraxis ist die Rollenverteilung meist in Stein gemeißelt: Das SAP-System fungiert als „System of Record“ – es ist die verbindliche Quelle der Wahrheit für Transaktionen. Doch sobald es darum geht, diese Daten für generative KI, Predictive Maintenance oder die Analyse unstrukturierter Daten zu nutzen, stößt die klassische SAP-Architektur oft an Grenzen.

Warum überhaupt Databricks für SAP-Daten?

Die Antwort liegt in der Spezialisierung: Während SAP ungeschlagen ist, wenn es um Prozessstabilität und strukturierte Buchungsdaten geht, bietet Databricks die notwendige Umgebung für modernes Machine Learning – von GPU-basiertem Training über Python-basierte Data Science bis hin zum Hosting offener LLMs. Die Herausforderung bestand bisher darin, diese beiden Welten zu verbinden, ohne massive Datensilos aufzubauen.

Bisher war der Aufbau umfangreicher ETL-Pipelines der einzige Weg. Das bedeutete konkret: Hoher Entwicklungsaufwand, steigende Storage-Kosten durch Duplikate und – das Schlimmste – eine systembedingte Latenz. Wenn der Report erst am nächsten Tag verfügbar ist, entscheiden Fachbereiche oft auf Basis veralteter Zahlen.

Hier ändern sich die technologischen Vorzeichen gerade massiv. Durch die Partnerschaft von SAP und Databricks stehen neue Integrationsmuster zur Verfügung, die diese Latenz architektonisch eliminieren und die KI-Stärken von Databricks direkt auf die SAP-Daten anwenden.

Der technologische Hebel: Logischer Zugriff statt physischer Kopie

Die Lösung liegt in der Virtualisierung des Datenzugriffs. Technisch ermöglicht durch das offene Protokoll Delta Sharing (Databricks Delta Sharing - Data Sharing | Databricks), ändert sich die Art der Datenbereitstellung grundlegend.

Anstatt Daten physisch zu extrahieren, zu transportieren und neu zu speichern, greift das Databricks Lakehouse lediglich logisch auf die Datenprodukte in der SAP Datasphere zu. Für Data Scientists und Analysten sieht es so aus, als lägen die Daten lokal im Lakehouse vor – physisch verbleiben sie jedoch sicher im SAP-System.

Architektur-Entscheidung: Virtualisierung vs. Ingestion

Dies bietet zwei entscheidende architektonische Vorteile:

• 1. Vermeidung von Redundanz: Wir reduzieren Speicher- und Egress-Kosten erheblich da keine doppelten Datenhaltungen für reine Analysezwecke aufgebaut werden müssen.
• 2. Erhalt der Semantik: Wir extrahieren nicht nur kryptische technische Tabellen wie KNA1 (Kundenstamm) oder MARA (Materialstamm), sondern greifen auf die semantischen Modelle zu. Die Geschäftslogik und die Beziehungen zwischen den Datenobjekten bleiben erhalten und müssen in Databricks nicht mühsam rekonstruiert werden.
• 3. Echtzeit statt „Daten von gestern“: Da kein physischer Kopiervorgang mehr stattfindet, arbeiten eure Analysen stets auf den aktuellsten Daten. Die Latenz zwischen Buchung im SAP und Sichtbarkeit im Dashboard sinkt auf null.

Die Implementierungs-Strategie: Virtualisierung oder Ingestion?

Databricks stellt die Technologie bereit, aber die Architektur-Entscheidung liegt in der Implementierung. Es gibt keine „One-Size-Fits-All“-Lösung. In modernen Projekten wird daher strikt nach Anwendungsfall differenziert:

• Der virtuelle Weg (Zero-Copy): Dies ist der präferierte Standard für Business Intelligence und Ad-hoc-Analysen. Wenn ein Controller den aktuellen Umsatz sehen will, ist der virtuelle Zugriff ideal: schnell, aktuell und kosteneffizient.
• Der physische Weg (Lakeflow Connect): Es gibt Szenarien, in denen Virtualisierung an Grenzen stößt – etwa beim Training komplexer KI-Modelle, die historische Snapshots benötigen oder massive I/O-Last erzeugen. Hier kommen native Konnektoren via Lakeflow zum Einsatz, um Daten inkrementell und transaktionssicher (ACID) in den Delta Lake zu überführen.

Die Kunst im Engineering liegt darin, diese beiden Wege in einer hybriden Architektur so zu kombinieren, dass ihr das Beste aus beiden Welten erhaltet.

Sicherheit über Systemgrenzen hinweg

Die technische Öffnung von SAP-Daten löst bei Security-Verantwortlichen oft Bedenken aus. Damit hier keine Governance-Lücken entstehen, fungiert der Unity Catalog als zentrale Kontrollinstanz.

Der Vorteil dieser Architektur ist die Synchronisation: Sicherheitsrichtlinien und Metadaten lassen sich über die Systemgrenzen hinweg mappen. Das schafft eine durchgängige Data Lineage. Es ist technisch lückenlos beweisbar, welcher SAP-Datensatz in welches KI-Modell oder Dashboard fließt. Die Zugriffsrechte werden dabei zentral durchgesetzt – egal ob der Zugriff via Python-Code oder SQL-Abfrage erfolgt.

Wie sich diese Governance-Anforderungen konkret umsetzen lassen, vertiefen wir im nächsten Teil der Serie: „Unity Catalog in der Praxis: Wie ihr Daten-Demokratie und deutsche Compliance endlich vereint“.

Der Payoff: Strategischer Mehrwert und operative Exzellenz

Warum betreiben wir diesen architektonischen Aufwand? Die Antwort ist zweigeteilt: Zum einen realisiert ihr strategische Vorteile, die in einer reinen SAP-Welt nicht möglich wären. Zum anderen bietet ihr den Fachbereichen völlig neue, operative Werkzeuge an.

1. Der strategische Hebel: Warum SAP mit Databricks verbinden?

Die Kombination beider Plattformen schafft Synergien, die weit über das reine Reporting hinausgehen:

• Structured meets Unstructured (Der 360°-Blick): SAP ist ungeschlagen bei strukturierten Transaktionsdaten. Databricks ist führend bei unstrukturierten Daten (PDFs, Bilder, IoT-Logs). Erst wenn ihr SAP-Stammdaten mit diesen Informationen verknüpft, entsteht der Kontext für echte KI – etwa wenn ein Agent nicht nur den Umsatzverlust kennt, sondern auch den wütenden E-Mail-Verkehr der Kundin oder des Kunden dazu analysiert.
• Time-to-Value für KI: Eure Data Scientists erhalten sofortigen Zugriff auf Produktionsdaten in einer Umgebung, die für Machine Learning optimiert ist (Python, GPUs, LLMs). Da komplexe Extraktions-Projekte entfallen, lassen sich KI-Piloten in Tagen statt Monaten verproben.

2. Der operative Nutzen: Zwei Wege zur KI-Assistenz

Ist das Fundament gelegt, lassen sich statische Reports durch intelligente Assistenten ersetzen. Je nach Komplexität der Anforderung bieten sich zwei Pfade an:

• Weg A: Die Ad-hoc-Analyse mit AI/BI Genie
  Für klassische Business-Fragen nutzen Fachbereiche AI/BI Genie (AI/BI Genie is now Generally Available | Databricks Blog). Sie interagieren direkt mit den Daten: „Analysiere die Margenentwicklung der Produktgruppe 'Maschinenbauteile' in Q3 und zeige mir die Ursachen für die Abweichung.“

Das System liefert nicht nur Text, sondern erstellt automatisch passende Visualisierungen, erkennt komplexe Zusammenhänge und lernt durch Feedback dazu. Der Vorteil: Echte Self-Service-Analytics, ohne dass die IT für jede Frage einen neuen Report bauen muss.

• Weg B: Der maßgeschneiderte Weg (Custom Agents)
  Genie ist der Einstieg. Wenn spezifische Prozesslogik erforderlich ist – etwa wenn der Assistent nicht nur lesen, sondern auch komplexe Workflows steuern oder in Systeme zurückschreiben soll – bietet das Mosaic AI Agent Framework die Freiheit, hochspezialisierte Agenten zu entwickeln.

Wie solche Agenten jenseits von Standard-Tools professionell entwickelt und evaluiert werden, lest ihr im Detail im vierten Teil zum Thema „Agent Engineering statt Spielerei: Der Weg zu sicheren KI-Anwendungen mit Mosaic AI“.

Vertrauen durch den Semantic Layer

Ein Risiko bei generativer KI sind "Halluzinationen" – etwa wenn die KI den Umsatz falsch berechnet. Ein Sprachmodell kennt die unternehmensspezifische Definition von „EBITDA“ oder „Deckungsbeitrag“ nicht von Haus aus.

Um dies zu verhindern, werden Metric Views (Unity Catalog metric views | Databricks on AWS) im Unity Catalog implementiert. Hier sind die Berechnungslogiken einmalig und verbindlich als „Single Source of Truth“ hinterlegt. Wenn der KI-Agent antwortet, greift er technisch zwingend auf diese zertifizierten Formeln zu.

Das Ergebnis: Verlässliche Zahlen, die mit den offiziellen SAP-Berichten übereinstimmen.

Fazit

Die moderne Datenarchitektur löst das historische Dilemma zwischen Stabilität (SAP) und Innovation (Databricks) auf. Die Entscheidung zwischen beiden Welten entfällt. Durch die intelligente Kombination via Zero-Copy entsteht eine Infrastruktur, die agil genug für KI ist, ohne die Integrität der Stammdaten zu gefährden.