Google Looker SAP: SAP-HANA-Daten verbinden und nutzbar machen

Definition

Google Looker ist eine BI- und Analytics-Plattform, die Daten aus SAP HANA per Datenbankverbindung abfragen und als standardisierte Kennzahlen über LookML bereitstellen kann. Es ist kein SAP-Ersatz und keine automatische Datenintegration, sondern eine Modellierungs- und Analyseebene auf vorhandenen Datenquellen.

Einleitung

Wenn Reporting auf SAP-Daten basiert, scheitert es in der Praxis oft nicht an Charts, sondern an Definitionen, Zugriffsrechten und Performance. Google Looker SAP schafft hier Struktur: einheitliche Kennzahlen, saubere Zugriffe und Dashboards, die Fachbereiche selbst bedienen können – ohne jedes Mal SQL neu zu bauen.

Welche Architektur passt: Direkt auf SAP HANA oder über BigQuery?

Es gibt zwei praxistaugliche Wege, je nachdem, wie stabil, skalierbar und integrationsfähig eure Analytics werden soll.

• Direktverbindung Looker → SAP HANA: schnell startklar, gut für klar abgegrenzte Analysen, aber stärker abhängig von Datenbank-Performance und SAP-Berechtigungslogik.

• Integration SAP → BigQuery → Looker: mehr Aufbauaufwand, dafür bessere Skalierbarkeit, leichtere Kombination mit Nicht-SAP-Daten und eine „Gold-Daten“-Basis, die auch weniger IT-affine Teams konsistent nutzen können.

• Hybrid: einzelne Echtzeit-Views direkt aus HANA, der Rest über BigQuery.

Für BigQuery-basierte Architekturen helfen Referenzmuster wie das Google Cloud Cortex Framework und Looker Blocks (z. B. der Cortex Looker Block for SAP). Wichtig: Das sind Bausteine, keine fertige Wahrheit – SAP-Version, Felder und Geschäftsregeln müssen passen.

Verbindung Looker → SAP HANA: Schritte, Sicherheit und Verschlüsselung

Für die Direktverbindung brauchst du: SAP-HANA-Host/Port, Datenbank, Schema(s) und einen dedizierten Datenbanknutzer.

Schrittfolge (kompakt)

• Netzwerkpfad klären: Looker muss SAP HANA erreichen (Firewall/IP-allowlist, Routing, ggf. Private Connectivity).

• DB-User anlegen: minimal notwendige Rechte (primär Lesen); für Persistent Derived Tables (PDTs) ggf. zusätzlich ein Zielschema.

• Looker-Verbindung konfigurieren: Dialekt SAP HANA/SAP HANA 2+, Host/Port/DB, Credentials.

Sicherheit ist nicht optional: SSL/TLS aktivieren, Zertifikate sauber verwalten und Verbindungen nur aus definierten Netzen zulassen. In Looker validierst du die Verbindung anschließend pragmatisch im SQL Runner (Verbindungstest und ein erstes Select auf eine erlaubte View).

Benutzer, Zugriffe und typische Berechtigungsmodelle

Damit Fachbereiche Zahlen vertrauen, müssen Zugriffe reproduzierbar sein. In der Praxis bewährt sich: ein technischer DB-User mit minimalen Rechten plus Governance in Looker über Modelle, Ordnerrechte und (falls nötig) Zeilen-/Spaltenfilter im Modell.

• DB-Ebene: Zugriff bevorzugt auf Views statt auf Roh-Tabellen, klar getrennte Schemas (z. B. reporting_read).

• Looker-Ebene: Rollen und Content-Rechte, getrennte Dev/Test/Prod-Projekte (LookML).

• Auditierbarkeit: dokumentierte Kennzahlen-Definitionen und ein Change-Prozess für LookML.

JDBC-Parameter und Feature-Unterstützung: was du realistisch erwarten solltest

Looker nutzt JDBC zur Verbindung mit SAP HANA. Welche Parameter und Features unterstützt werden, hängt von Dialekt, Treiber und Version ab. Häufig genutzte Parameter sind zum Beispiel SSL-/Verschlüsselungsoptionen, Timeout-Settings und Schema-Voreinstellungen (z. B. currentSchema).

Wichtig für die Planung: Nicht jede Looker-Funktion wirkt auf jeder Datenbank gleich. Themen wie PDTs, Caching, SQL-Dialekt-Unterschiede und abgeleitete Tabellen sollten früh in einem Mini-Test geprüft werden – bevor Dashboards breit ausgerollt werden.

Welche Dashboards und Insights sind typisch?

Der Nutzen entsteht, wenn Kennzahlen wiederverwendbar werden: gleiche Definition, egal ob Controlling, Sales oder Operations. Typische SAP-nahe Analysefelder sind Order to Cash, Bestände, Lieferfähigkeit oder finanzielle Ist/Soll-Sichten.

Mini-Story (synthetisch): Ein Team startet mit Order to Cash, modelliert wenige Kernkennzahlen in LookML (Auftrag, Lieferung, Rechnung, Zahlung) und baut ein Dashboard mit eindeutigen Drilldowns. Ergebnis: weniger Diskussion über Zahlen, schnellere Ursachenanalyse bei offenen Posten – ohne dass jede Anfrage ein neues Reporting-Projekt auslöst.

Deployment-Plan: praxisnaher Implementierungsansatz

Damit Zeitaufwand, Kostenrisiko und Ergebnis-Messbarkeit im Griff bleiben, hat sich ein gestuftes Vorgehen bewährt:

• Woche 1: Zielbild und Use Case festlegen, Datenquellen/Views identifizieren, Security-Check (SSL, Netzwerk, Rollen).

• Woche 2: Verbindung und Abfrageverhalten testen, erstes LookML-Modell (Kernmetriken), Prototyp-Dashboard.

• Woche 3–4: Performance-Tuning, Datenqualitätsregeln, Governance (Naming, Reviews, Deployments), Pilot-Rollout.

Messbarkeit: Tracke Adoption (Nutzer/Abfragen), Dashboard-Ladezeiten und Anteil „einer Kennzahl – eine Definition“. So kannst du den Wert belegen, ohne vage Einsparversprechen.

Wann externe Unterstützung sinnvoll wird

Externe Unterstützung lohnt sich, wenn eines davon zutrifft:

• Unklare Architekturentscheidung (Direkt vs. BigQuery) oder Performance-Risiko auf SAP HANA.

• Sicherheitsanforderungen sind hoch (SSL, Netzwerkgrenzen, Audit-Anforderungen) und müssen sauber dokumentiert werden.

• Fachbereiche streiten über Kennzahlen oder es fehlt ein belastbares LookML-Datenmodell als gemeinsame Grundlage.

Nächste Schritte

Als erstes: Entscheide, ob du SAP HANA direkt anbinden willst oder ob BigQuery als Analytics-Fundament in der Google Cloud sinnvoller ist. Danach: minimaler Security- und Berechtigungsrahmen, dann Pilot-Use-Case. Wenn du das strukturiert bewerten willst: Jetzt ein kostenloses Erstgespräch vereinbaren und für den Plattformkontext gern auch unsere Übersicht zu Google Cloud ansehen.