- „Self-Serve-Dashboards“ funktionieren in der Praxis nicht gut. Der Grund ist, dass Engineers oder Data Scientists viel Zeit damit verbringen müssen, für Business-User Abfragen zu schreiben und Dashboards vorzubereiten.
Warum „Self-Serve BI“ nicht funktioniert
- SQL ist das einzige echte Tool für „Self-Serve BI“. Die meisten Anbieter von „Self-Serve BI“ versuchen jedoch, SQL als etwas anderes zu tarnen.
- Das Schreiben von SQL-Abfragen ist nicht die einzige Hürde dafür, dass Business-Stakeholder Daten abfragen können. Sie verstehen weder die Bedeutung der Daten, noch deren Herkunft oder Berechnungsweise, und sie wissen nicht, wie Ergebnisse interpretiert und validiert werden.
Versuch 1: der klassische „Dropdown- und Checkbox“-Ansatz
- Diese Oberfläche ist letztlich nur ein Versuch von „SQL-per-Maus“. Sie ist SQL nicht überlegen, sondern eher langsamer, unzuverlässiger, eingeschränkter und lässt sich nicht auf andere Tools verallgemeinern.
- Jemand wie ein CFO wird mit dieser Oberfläche keine Daten abfragen. Es fehlt der Kontext, um die Daten zu verstehen, und damit auch das Vertrauen in die Ergebnisse.
Versuch 2: der Text-to-SQL-Ansatz
- LLMs sind fast zu effektiv darin, natürliche Sprache in SQL zu übersetzen. Selbst wenn eine Frage nicht passend formuliert ist, werden sie versuchen, eine Abfrage zu erzeugen.
- Technische Fachleute würden erkennen, dass die Frage nicht passend ist, und nach mehr Kontext fragen. Sie würden die verfügbaren Datentypen erklären und mit den Fachbereichen zusammenarbeiten, um präzise und nützliche Fragen zu formulieren.
- LLMs könnten die tatsächliche Lösung für „Self-Serve BI“ sein, aber nicht in ihrer heutigen Form. Sie brauchen mehr Kontext und müssen besser darin werden, Unsicherheit auszudrücken und zusätzliche Informationen anzufordern.
Was tatsächlich funktioniert
- Das Problem bei „Self-Serve BI“ ist nicht SQL, sondern der Kontext und die Bedeutung der Daten. Die Lösung besteht darin, Menschen unabhängig von der Oberfläche zu vermitteln, was die Daten bedeuten, die sie abfragen.
- Wenn Technikteams ihr gesamtes Wissen dokumentieren sollen, verursacht das erheblichen Overhead und veraltet sehr schnell.
- Die eigentliche Lösung für „Self-Serve BI“ besteht nicht darin, BI für nichttechnische Personen „self-serve“ zu machen, sondern technischen Fachleuten bessere Tools zu geben, damit sie Business-Stakeholder effizienter unterstützen können.
Vorschläge für bessere Tools:
- LLMs den technischen Fachleuten zur Verfügung stellen, nicht den Business-Stakeholdern.
- Ermöglichen, Daten frei mit vertrauten Tools wie Python oder R zu bearbeiten.
- Es technischen Fachleuten leicht machen, ihre Arbeit zu teilen. Notebooks und interne Datenanwendungen sind schwer zu teilen, weil dabei Container, Abhängigkeiten und Infrastruktur berücksichtigt werden müssen.
1 Kommentare
Hacker-News-Kommentar
Probleme mit BI-Tools: Beim Einsatz von BI-Tools wurde erlebt, dass Daten falsch angezeigt wurden, weil Joins in Abfragen falsch eingerichtet waren. Dadurch ging das Vertrauen in Abstraktionsschichten verloren, die für Menschen gedacht sind, die SQL nicht gut beherrschen.
Nützlichkeit von Text-to-SQL: Für Entwickler ist es weiterhin nützlich, aber bei Nichtentwicklern besteht die Möglichkeit, dass falsche Abfragen erzeugt werden, weil sie die Struktur der Datenbank nicht richtig verstehen.
Inkompetenz von Organisationen: Berichte mit Fehlern und Falschinformationen aus BI- und AI-Tools werden tatsächlich verwendet, und Ähnliches wurde bereits im Dilbert-Comic kritisiert.
Lernfähigkeit von Business-Usern: Die Annahme, dass Business-User das Verhältnis zwischen Datenmodellen und Dropdown-Menüs nicht verstehen können, ist falsch. Probleme entstehen, weil Datenmodellierer die Domäne nicht gut genug verstehen.
Erfahrung mit Datenbereitstellung: Aus 24 Jahren Erfahrung in der Bereitstellung von Daten zeigt sich, dass nur wenige Nutzer die Tools tatsächlich verwenden, während das Management KPI-Dashboards bevorzugt.
Vorteile von Metabase: Metabase bietet unter den BI-Tools eine gute Oberfläche, und per GUI erzeugtes SQL kann in reines SQL umgewandelt werden, sodass auch Menschen mit geringerem technischem Niveau es leicht nutzen können.
Grenzen von Self-Service-BI: Die Grenzen von Self-Service-BI sollten anerkannt werden; die Lösung besteht darin, maßgeschneiderte Dashboards zu bauen, ohne SQL gegenüber Business-Usern offenzulegen.
Erfahrungen mit Metabase: Bei der Nutzung von Metabase wurde nichttechnischen Nutzern in "Office Hours" die Bedienung erklärt, wodurch viele Anfragen nicht an das Engineering-Team weitergereicht werden mussten.
Die Ironie bei der SQL-Nutzung: Es ist ironisch, dass Führungskräfte keine SQL-Abfragen ausführen können. SQL wurde ursprünglich geschaffen, damit Manager Daten leicht abfragen können.
Schwierigkeiten bei ETL: Für nichttechnische Nutzer ist der Umgang mit Daten bei ETL schwieriger als bei BI. Bei der Entwicklung von AWS Glue wurde klar, dass technische Nutzer Werkzeuge brauchen, mit denen sie Probleme debuggen können.