Das böse Wort Self-Service - und wie es dennoch funktionieren kann

Nach dem Launch eines neuen Produkts bemerkt Markus aus dem Vertrieb bei einem Blick in das Sales-Dashboard, dass die Verkäufe in die Höhe schießen. Doch liegt das tatsächlich am neuen Produkt oder eher an der Vorweihnachtszeit? Leider lässt sich das aus dem Dashboard nicht eindeutig herausfiltern. Jetzt muss Markus einen zuständigen Datenanalysten ausfindig machen, um einen Produktfilter hinzuzufügen, oder sogar ein Ticket erstellen – und … warten.

Wäre es nicht großartig, wenn Markus diese kleine Änderung selbst vornehmen könnte?

Das ist die Idee von Self-Service im Kontext von Data Analytics. Doch in den meisten Data Departments hat dieses Thema einen eher schlechten Ruf, da Unternehmen immer wieder negative Erfahrungen machen.

Die Hauptprobleme des Self-Service-Ansatzes sind:

  • Überforderung der Nutzer

  • Falsche Interpretationen von Daten

  • Mangelnde Kontrolle und Governance

Zurück zu Markus:
Markus’ Unternehmen hat bereits Self-Service eingeführt - wusste er gar nicht. Einige Tage später hat er ein Meeting mit Sara. Sara ist Data Analyst und zeigt Markus, wie er künftig Änderungen und kleine Analysen selbst durchführen kann. „Schau mal, hier kannst du einfach die SQL-Query anpassen. Ein einfacher Join auf die Products-Tabelle, und schon hast du die Produkte in der Datenquelle.“

SQL-Query? Join? Leider spricht Markus - wie die meisten Self-Service-Nutzer - nicht fließend SQL. Nach der Session hat Markus zwar die Produkte im Sales-Dashboard verfügbar und kann sehen, woher der Anstieg kam, aber:

Markus hat BWL studiert, und aus dem Treffen ist vor allem eines bei ihm hängen geblieben:

  1. SELECT * FROM

  2. Export to Excel

Ab sofort wird in den ihm vertrauten Tools gearbeitet, auch wenn die Daten nicht immer aktuell sind. Im gesamten Unternehmen führt die Einführung von Self-Service zu einer ähnlichen Entwicklung: Es werden zahlreiche Exporte erstellt, Dashboards kopiert und leicht verändert. Konsistente Daten? Fehlanzeige.

Was tun?

Diese und ähnliche Probleme treten in immer mehr Unternehmen auf. In den letzten Jahren hat sich jedoch ein Trend abgezeichnet, der hilft, diese Herausforderungen zu bewältigen: der Semantic Layer.

Spätestens seit dbt – eines der führenden Tools für Datentransformationen in Data Warehouses – im Jahr 2022 angekündigt hat, einen Semantic Layer in einer neuen Version anzubieten, ist das Konzept endgültig im Mainstream angekommen.

Der Semantic Layer ist eine abstrakte Schicht zwischen den Daten im Data Warehouse und den Endnutzern. Er übersetzt komplexe Datenstrukturen in verständliche und benutzerfreundliche Begriffe, sodass auch Fachanwender ohne tiefgehende technische Kenntnisse auf die Daten zugreifen und sie nutzen können.

In der Praxis sieht dies folgendermaßen aus:

Wenn Nutzer:innen in einem Tool zur Datenvisualisierung wie Tableau oder Looker auf Daten zugreifen möchten, erfolgt der Zugriff nicht direkt auf die Tabellen im Data Warehouse, sondern über semantische Modelle. Diese Modelle enthalten Definitionen von Dimensionen und Kennzahlen sowie die Beziehungen zwischen ihnen.

Dadurch können im Visualisierungstool einfach Metriken und Dimensionen ausgewählt werden, ohne dass die zugrunde liegenden Datenstrukturen bekannt sein müssen. Im Hintergrund erzeugt der Semantic Layer automatisch eine SQL-Abfrage, die das korrekte Ergebnis bereitstellt.

Im Fall von Markus würde das bedeuten: Er öffnet das Dashboard, zieht die Dimension „Produkt“ in den Filter – fertig. Kein SQL, keine Joins und deutlich einfacher als „Export to Excel“.

Im Bezug auf eine Self-Service-Strategie bringt dieser Ansatz klare Vorteile:

  • Vereinfachung von Datenmodellen: Anwender:innen können auf verständliche, businessorientierte Begriffe zugreifen, die im Semantic Layer definiert sind.

  • Erhöhung der Zugänglichkeit: Ohne tiefe technische Kenntnisse können Nutzer:innen eigene Dashboards und Analysen erstellen.

  • Datenkonsistenz und Governance: Der Semantic Layer stellt sicher, dass alle Nutzer:innen dieselben, geprüften und bereinigten Daten verwenden, was Qualität und Vertrauen in die Analyseergebnisse steigert.

Auch wenn die Nutzung auf den ersten Blick einfach erscheint und das Wort Self-Service es nicht unbedingt vermuten lässt, sollten Mitarbeitende in der Nutzung des Systems allerdings geschult und unterstützt werden. Andernfalls können fehlende Grundlagen schnell zu Frustration führen und die Akzeptanz des Systems verringern.

Ein Nachteil den ein Semantic Layer mit sich bringt ist die damit verbundene wachsende Komplexität, die vor allem die Data-Teams betrifft. Während die Nutzung für Endanwender:innen einfach gestaltet ist, kann die Entwicklung und Implementierung des Semantic Layers für Entwickler:innen herausfordernd sein. Es sind beispielsweise umfangreiche Abstimmungen erforderlich, um die „richtige“ Definition von Metriken zu finden oder eine gut strukturierte Organisation der semantischen Modelle sicherzustellen. Allerdings führen diese Abstimmungen auch zu einem gemeinsamen Datenverständnis, was durchaus zu einem positiven Effekt in der generellen Datenstrategie und die Data Literacy im Unternehmen führen wird.

Fazit

Die Vergangenheit hat gezeigt, dass Self-Service-Analytics-Strategien in Unternehmen oft mehr Probleme als Nutzen mit sich brachten. Dies könnte sich jedoch durch den wachsenden Einsatz von Semantic-Model-Technologien ändern. Diese ermöglichen es, die Vorteile von Self-Service mit konsistenter Datenqualität und klaren Governance-Strukturen zu verbinden.

Doch auch dieser Ansatz bringt Herausforderungen mit sich: Besonders für die ohnehin stark ausgelasteten Data-Teams bedeutet ein Semantic Layer zusätzlichen Aufwand und wachsende Komplexität bei der Implementierung und Pflege.

Es bleibt abzuwarten, wie sich dieser Trend weiterentwickelt und in welchem Maße er dazu beitragen kann, das Image von Self-Service Analytics nachhaltig zu verbessern.

Weiter
Weiter

7 ways to level up your SQL queries