Warum Self-Service-Dashboards nicht funktionieren

• „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:

1. LLMs den technischen Fachleuten zur Verfügung stellen, nicht den Business-Stakeholdern.
2. Ermöglichen, Daten frei mit vertrauten Tools wie Python oder R zu bearbeiten.
3. 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.

[GN⁺]

Hacker-News-Kommentare

• In einem Unternehmen, in dem Dashboards mit einem BI-Tool erstellt wurden, kamen mir die Zahlen seltsam vor, also sah ich mir den Query-Generator an – und es war überhaupt nicht erkennbar, ob Teile der Query ein Inner Join oder ein Left Join waren.
  Auch der Business Analyst, der das Dashboard gebaut hatte, wusste es nicht. Tatsächlich war ein Inner Join beabsichtigt, ausgeführt wurde aber ein Left Join, wodurch die angezeigten Daten um eine Größenordnung zu hoch ausfielen.
  Seitdem vertraue ich solchen Abstraktionsschichten über SQL für Menschen, die kein SQL können, nicht mehr.

  • Aus der Perspektive von jemandem, der seit über 15 Jahren Data-Engineering- und Data-Science-Teams leitet: Genau das ist der Kern.
    Zu viele Menschen können auf Daten zugreifen, verstehen aber die Daten selbst, ihre Beziehungen und die Bedeutung der von ihnen erzeugten Ergebnisse nicht.
    In den letzten 25 Jahren wurden verteilte/eingebettete Engineers und Wissenschaftler, Self-Service-Dashboards, Low-Code-BI-/Datentools und nun LLM-basierte Text-zu-SQL-/Visualisierungslösungen als Ausweg gehandelt, aber am Ende haben sie das Problem des fehlenden Datenverständnisses und des Vertrauens in die Ergebnisse nicht gelöst.
    SQL ist allerdings auch nicht die Lösung. Es gibt viele Menschen, die genug SQL können, um Daten herauszuziehen, aber nur wenige, die auch die Datenstruktur, das Schema und die richtige Verwendung verstehen.
    Außer Erfahrung gibt es bisher kein Tool, das dieses Problem löst; vielleicht schaffen LLMs das irgendwann, aber ehrlich gesagt erscheint mir das eher unwahrscheinlich.
    Dashboards sind gut, um KPIs schnell zu sehen und tiefer einzusteigen, aber entscheidend sind letztlich Datenmanagement-Praktiken und die Fähigkeit, Daten/Beziehungen/Metriken richtig zu verstehen und in Business Insights zu übersetzen.
    Ich bin gespannt auf die Zukunft, aber bisher hat keine Generation der nächsten Tools ihre Versprechen gehalten, daher vertraue ich ihnen ganz sicher nicht leichtfertig.
  • Ich habe gesehen, wie so etwas bei Low-Code-Tools immer wieder passiert.
    Vernünftige Defaults und Vorrichtungen, mit denen man sich selbst ins Bein schießt, sind nur eine Frage der Perspektive.
  • Ich frage mich, ob nach der Korrektur alle ausgerastet sind, weil die Zahlen niedriger wurden.
    In großen Unternehmen habe ich erlebt, dass bei subtilen Bugs oder Designs, die den Umsatz höher aussehen lassen, niemand daran rühren will, um nicht die Verantwortung für den Umsatzrückgang zu tragen.
    Zum Beispiel: Der Button für den kostenlosen Tarif liegt bei durchschnittlicher Auflösung unterhalb des sichtbaren Bereichs, eine State-Berechnung ist falsch und Rabatte werden nicht angewendet, oder jemand hat ein false vergessen, sodass eine Registrierung verlangt wird, obwohl sie technisch nicht nötig wäre.
    Ich frage mich, ob es sich ähnlich angefühlt hat – aus Angst, dass einem die niedrigeren Zahlen angelastet werden.
  • Das ist ein Problem, das alle No-Code-Lösungen gemeinsam haben.
    Der schwierige Teil bei der Umsetzung komplexer Logikflüsse besteht nicht darin, Code in eine IDE zu tippen, sondern darin, das Problem zu modellieren und einen wirksamen Algorithmus zu entwerfen.
    Diese Tools richten sich mit dem Versprechen, keinen Code schreiben zu müssen, an nichttechnische Nutzer, aber die Nutzer verstehen weiterhin nicht den komplexen Teil, eine Lösung ingenieurmäßig zu entwerfen, und verirren sich oder produzieren falsche Ergebnisse.
    Versuche, komplexe Geschäftsprozesse mit No-Code-Tools aufzubauen, stoßen nach viel Trial-and-Error am Ende an eine Wand und werden schließlich an echte Engineers übergeben.
    Diese Engineers müssen dann aber ohne die Unterstützung arbeiten, die beim Schreiben von Code in einer echten Programmiersprache selbstverständlich ist.
    Wenn man in einem visuellen Flow-Builder gefangen ist, werden ein gemeinsames Repository, saubere Versionskontrolle, Code Reviews, automatisierte Tests und CI/CD nahezu unmöglich.
  • Man sollte es so machen wie anderswo: Abstrakte Beziehungen zu Views zusammensetzen und Self-Service-BI-Dashboards auf semantisch passende Views beschränken.
    Nutzer sehen Dinge grundsätzlich aus ihrer eigenen Perspektive, daher muss man alternative Wege bereitstellen, die auch ihrer Denkweise entsprechen.
    Ich kenne ein Produkt, das Anwesenheit im Bildungsbereich zeitbasiert verarbeitet, weil die Kombinationen von Stundenplänen je nach Schule, Campus und Datum unterschiedlich sind und flexibel genug für Sportveranstaltungen, Ersatzdienste, klassenübergreifende Aktivitäten und 14-Tage-Rotationspläne sein müssen.
    Das heißt aber nicht, dass man aus diesen komplexen Stundenplänen keine Views für kursbasierte Anwesenheit oder Vormittags-/Nachmittagsanwesenheit zusammensetzen kann.

• Die Annahme, dass Business-Nutzer die Beziehung zwischen ihren Fragen, dem Datenmodell und Dropdowns nicht lernen können oder dafür zu ungeduldig sind, ist absurd.
  Meiner Erfahrung nach wollen sie eher lernen, aber Data Modeler verstehen die Domäne oft nicht ausreichend und können die Nuancen der Fragen nicht abbilden.
  Das Ergebnis ist, dass man unter dem Vorwand, Self-Service zu vereinfachen, Nuancen versteckt und so die Zeit bis zur Antwort verlängert – oder sie ganz entfernt und dadurch ungenaue und irreführende Antworten produziert.
  Ich mag auch den Euphemismus nichttechnisch nicht. Zwischen LLMs, BI-Query-Buildern und SQL gibt es genug Zwischenstufen; man muss keine absolute Kompetenzmauer ausrufen.

  • Das hängt auch mit dem Rat zusammen, den ich jungen Menschen mit Interesse an Programmierung immer gebe.
    Es ist gut, Experte für Computer, Programmierung und Datenanalyse zu werden, aber wenn möglich sollte man die Domäne, in der man lernt oder arbeitet, ins Zentrum stellen und diese Fähigkeiten ergänzend entwickeln.
    Die Lösung für das Problem, dass Domänenexperten keine Daten verstehen und Datenexperten die Domäne nicht verstehen, besteht darin, dass beides dieselbe Person wird.
  • Die besten Business-/Datenergebnisse meiner Karriere entstanden, wenn es einen PM mit SQL-Kenntnissen, einfache Extraktions- und Scheduling-Tools sowie ein vernünftiges Datenmodell gab, das vom Data-Engineering-Team verwaltet wurde und Input von BI-Entwicklern oder deren Tabellendesigns aufnahm.

• Es wirkt, als hätte organisatorische Unfähigkeit gerade ein neues Niveau erreicht.
  Es gab einmal einen Dilbert-Comic, der Spreadsheets kritisierte, und er lässt sich eins zu eins auf BI-Tools und AI-Tools übertragen.
  Sinngemäß: „Natürlich enthält das Spreadsheet in dieser Präsentation Fehler und falsche Informationen. Das spielt keine Rolle, denn niemand wird es sich je wieder ansehen, solange es nicht eine Entscheidung bestärkt, die das Management bereits getroffen hat.“
  Auch in der Realität gibt es überall kaputte Reports und Dashboards.
  Manche werden Monate, manchmal Jahre lang überhaupt nicht aktualisiert, und trotzdem werden sie unbemerkt in Prozessen, Entscheidungen und Workflows verwendet.
  Es gibt auch Fälle, in denen die Daten nicht aktualisiert werden, aber nach Datum/Uhrzeit gepivotet sind und bei jeder Ausführung dieselben Daten neu anordnen, sodass selbst ein massiver Defekt kaum auffällt.
  Häufig geben diverse Formeln und „Mathematik“ völlig falsche Fantasiezahlen aus.

  • Der Ausdruck organisatorische Unfähigkeit ist unpassend. Die Menschen sind nicht unfähig.
    Die Datenprobleme sind exponentiell schwieriger geworden, weil sich die Welt von zentralisierten EDW- und ERP-Systemen entfernt hat, und das Investitionsniveau hat damit einfach nicht Schritt gehalten.

• In den vergangenen 24 Jahren habe ich Business-Anwendern Daten bereitgestellt, aber egal ob Query-Tool, MS Access, Power BI oder Data Cubes in Excel: Tatsächlich nutzt sie nur eine kleine Minderheit.
  Wahrscheinlich sind es genau dieselben Leute, die schon vor 40 Jahren Daten aus Terminals und gedruckten Berichten herausgekratzt und analysiert hätten.
  Trotzdem mögen Führungskräfte Dashboards mit Kernkennzahlen, und neue BI-Tools machen es viel einfacher, KPI-Dashboards zu erstellen und zu pflegen.

  • Es ist gut, im Unternehmen Menschen zu entdecken, die selbst nicht wissen, wie gut sie im Coden sind.
    Ihre Stellenbezeichnung ist vielleicht so etwas wie „Personal Assistant“, aber sie bearbeiten SharePoint-Formulare, Access und Excel wie Hacker und bauen damit beeindruckende Dinge.
    Wenn man ihre cleveren Fähigkeiten anerkennt und ihnen leistungsfähigere Tools gibt, ist das großartig. Manchmal wechseln sie dann in einen besseren Job, und auch das ist eine schöne Sache.
  • In den frühen Tagen der Computertechnik lief der Großteil der Arbeit auf großen, gemeinsam genutzten Mainframes.
    Computer waren so teuer, dass die „Computerabteilung“ eine eigene Abteilung im Unternehmen war; wenn etwa die Westsparte Rechenressourcen brauchte, schloss sie einen Vertrag mit der Computerabteilung, die vor Ort einen Mainframe betrieb.
    Unsere Gruppe war ein kleines, agiles internes Analyseteam, das neue, „preiswerte“ Minicomputer nutzte.
    Der Vorteil war, dass wir dank der Finanzierungsstruktur viel schneller auf Nutzeranforderungen reagieren konnten.
    Eines Tages lief ich durch die Fabrik und sah, wie ein Nutzer Zeilen aus einem von uns erstellten grün gestreiften Bericht ausschnitt, auf ein anderes Blatt klebte und kopierte.
    Er sortierte den Bericht nach anderen Kriterien, also sagte ich: „Das können wir für Sie erledigen!“ — die Antwort war: „Wirklich?“
    Wer eine Aufgabe erledigen muss, findet einen Weg. Das Ziel einer Computersystemgruppe, die interne Kunden bedient, ist es, diesen Prozess so effizient wie möglich zu machen.
    Eine andere Person nutzte einen PC, einen Tablet-Digitizer und AutoCAD, um Punkte an einem Flugzeug zu erfassen und Radarprofile zu erstellen.
    Das war weniger der eigentliche Zweck von CAD als vielmehr eine kreative Methode, Daten aus Zeichnungen in Jane's Combat Aircraft zu erfassen.
  • Wenn man den Auftrag bekommt, Systemintegrationssoftware zu bauen, sind Kunden oft schon sehr überrascht, wenn man vorhandene Dashboards einrichtet oder freilegt.
    Sie können kaum glauben, dass diese Daten die ganze Zeit schon vorhanden waren.
    Integration ist für den Geschäftsbetrieb nötig, aber leicht verständliche Daten kommen bei Stakeholdern wirklich gut an. Das ist ein sehr einfacher Mehrwert.

• Die im Artikel gezeigte klassische BI-Oberfläche ist Metabase, und sie gehört derzeit zu den ziemlich guten Interfaces für BI.
  In Metabase kann man das von der GUI erzeugte SQL sehen und die Frage auch in reines SQL umwandeln; das eignet sich gut für den Übergang von Self-Service zu Governance.
  Die Logik lässt sich leicht ändern und prüfen, und weniger technisch versierte Menschen bekommen einen Weg, ihre Fähigkeiten auszubauen.
  Der Kern des Artikels stimmt aber. Auch aus Sicht jemandes, der professionell mit Daten arbeitet, geben BI-Tools selten mehr Menschen das genaue Verständnis von Daten oder die Fähigkeiten, die für ihre korrekte Nutzung nötig sind.
  Wenn Daten gut verwaltet werden, sind die Tools einfach und die Leute können es herausfinden, aber die Welt ist komplex, also werden auch die Daten komplex.
  Die Kosten für Datenmanagement sind gut sichtbar, die Vorteile dagegen weniger.

• Zu „Self-Service BI“ bin ich zu einem ähnlichen Schluss gekommen, sehe die Lösung aber etwas anders.
  Ich halte es für besser, die Abstraktionsebene höher anzusetzen: sehr stark anpassbare Dashboards bauen, Business-Anwendern aber kein SQL zeigen.
  Zum Beispiel ein Dashboard mit 20 Filtern, Aufschlüsselungsdimensionen und 20 Parametern, die die „verwendeten Annahmen“ steuern.
  Die Frage „Ich möchte die Performance der Google-Anzeigen des letzten Monats nach Altersgruppen sehen“ wird dann zum Ändern von drei oder vier vordefinierten Dropdowns.
  Genau hier sind Parameter wichtig: Man stellt nur geprüfte Stellschrauben bereit und erlaubt kein beliebiges SQL.
  Natürlich sind solche Dashboards schwer zu bauen und erfordern einiges an Visualisierungs-Know-how mit Looker, Tableau, Excel und Ähnlichem, aber im Ergebnis werden 70 % der Fragen Self-Service.
  Die übrigen 30 % sollte man besser aufgeben, und man braucht jemanden, der Business-Fragen in Datenfragen übersetzt. Das ist ein Menschenproblem.

  • Man kann die häufigen Fragen identifizieren und passende Dashboards dafür bauen.
    Dann öffnet der CFO oder wer auch immer das Dashboard, wenn er eine Antwort für einen bestimmten Zeitraum braucht, und passt nur ein paar Standardparameter an.

• Wir nutzen Metabase, das im Bild gezeigt wird, und im Großen und Ganzen verwenden es auch nichttechnische Nutzer tatsächlich.
  Bei der Einführung half es, „Office Hours“ anzubieten und direkt Beispiele zu zeigen, etwa „wie man den Umsatz einer bestimmten Filiale oder eines Bundesstaats abruft“.
  Das hat nicht jedes Problem, jede Query und jeden Export gelöst, aber ein erheblicher Teil der Anfragen, die früher beim Engineering landeten, kommt heute gar nicht mehr bis zu dieser Stufe.
  Ein weiterer Grund, warum Metabase gut ist: Man kann es selbst hosten und GSuite SSO nutzen.

  • Meiner Erfahrung nach liegt das Problem nicht im Mittel, Daten abzufragen, sondern im besonderen Kontext der Daten selbst.
    Die entscheidende Kennzahl ist nicht: „Es gibt weniger Hilferufe, also sind die Nutzer unabhängiger.“
    Denn es ist sehr wahrscheinlich, dass diese Nutzer völlig falsche Kennzahlen ziehen und interpretieren.
    Ich habe immer wieder gesehen, wie wenig technische Nutzer nach dem Zugriff auf Daten glauben: „So schwer ist das ja gar nicht“, und dann eine Pyramide aus fehlerhaften Analysen aufbauen.
    Korrekte Analyse braucht immer Kontext.
    Zum Beispiel sollte man für die Berechnung des Monatsumsatzes nicht das Versanddatum verwenden, weil das Finanzteam bei wiederkehrendem Umsatz die Versanddaten nachträglich auffüllt.
    Listenpreise werden in USD gespeichert, tatsächlich werden die Wechselkurse aber monatlich anhand der Tabelle monthly_discount angepasst.
    Wegen der Praxis, unverkaufte Bestände aus dem Vorjahr auszuweisen, müssen Einträge mit null als Kaufdatum aus Umsatzberichten ausgeschlossen werden.
    Weil Preise in lokaler Währung vorliegen, darf man Umsätze nicht einfach summieren, ohne mit der Wechselkurstabelle zu joinen.
  • Metabase ist gut.
    Ich habe es für die Nicht-Programmierer im Unternehmen eingerichtet, und ehrlich gesagt nutzen sie es kaum über das Anschauen der von mir gebauten Dashboards hinaus, aber die Reaktion war positiv.
    Es ist ein wirklich nützliches Tool.

• Ich finde es immer wieder lustig, dass hochrangige Führungskräfte viel Geld verdienen und trotzdem keine BI-SQL-Queries ausführen können.
  SQL wurde ursprünglich doch dafür entwickelt, dass Manager Daten einfacher abfragen können.
  Aus Sicht eines früheren Vertriebsmitarbeiters/Managers habe ich für solche Leute wenig Mitgefühl.

  • Ich kenne einen CEO, der SQL „kann“ – und zwar besser als die meisten Leute im Unternehmen, die von sich sagen, sie könnten SQL.
    Aber er macht es nicht selbst. Er kennt nämlich die grundlegenden ökonomischen Prinzipien.
    Selbst wenn er etwas, wofür jemand anderes drei Tage braucht, in einem halben Tag erledigen könnte, wäre dieser halbe Tag Zeit, in der er nicht die Dinge tun kann, die nur ein CEO tun kann.
    Ein fähiger CxO weiß auch, dass der wirklich zeitaufwendige Teil darin besteht, die Details exakt richtig hinzubekommen.
    Auch wenn SQL „High-Level“ ist, braucht man Zeit und Konzentration, um bei Dingen wie den Eigenheiten der Null-Behandlung, Datumsverarbeitung oder nicht passenden Joins eine verlässliche Antwort zu bekommen.
    Wenn es jemanden gibt, der darauf spezialisiert ist, sollte man es dieser Person überlassen.

• Ich denke, BI-Dashboards können bei sehr einfachen Abfragen gut funktionieren.
  Wenn man an dem Punkt ist, an dem man von nichttechnischen Nutzern verlangt, Daten-Joins auszuführen, ist man schon zu tief drin; dann ist es besser, einfach SQL zu verwenden.
  Joins mögen manchen wie etwas Grundlegendes erscheinen, aber ich finde sie selbst gelegentlich schwer zu verstehen, und in einer Dashboard-UI, die weniger ausdrucksstark ist als SQL, sind sie eine Kombination, die Verwirrung stiftet.
  Am Ende ist es ein Kompromiss. Man kann es für nichttechnische Nutzer zugänglicher machen als SQL, aber zwangsläufig wird es weniger mächtig als SQL.
  Trotzdem ist der Raum dazwischen sehr nützlich. Tatsächlich besteht ein großer Teil von „BI“ aus Dingen auf dem Niveau von: „Hier sind ein Dutzend Datenspalten, bitte zeichne eine gegen eine andere.“
  Der Autor bezeichnet SQL als einziges „Self-Service“-BI-Tool, aber ehrlich gesagt ist das meiner Meinung nach Excel.
  Viele BI-Tools laufen darauf hinaus, Excel mit einer neuen und deshalb weniger vertrauten Oberfläche neu zu bauen.
  Ich glaube, das Meme, Excel zu hassen, entstand aus der Vergangenheit, in der man versucht hat, komplexe Dinge in Excel zu erledigen.
  Wenn man komplexe Datenmanipulation in SQL macht und „zeig mir das als Kreisdiagramm“ in Excel, braucht man BI-Tools möglicherweise wirklich nicht.

  • Ich wollte zur Beziehung zwischen SQL und Excel fast genau dasselbe sagen.
    Wenn die zugrunde liegenden Datenquellen bereinigt, transformiert und mit sauberer Zugriffskontrolle versehen sind, kommt man allein mit VLOOKUP und Pivot-Tabellen erstaunlich weit.
    Sobald es mehr als eine Datenquelle gibt, führt jede Self-Service-Möglichkeit für nichttechnische Nutzer immer dazu, dass Daten offline zusammengewürfelt werden.
    Und dann kommt die Frage: „Datenteam, warum stimmen ‚eure‘ Daten nicht mit ‚meinen‘ Daten überein?“, wobei immer vorausgesetzt wird, dass die eigene Seite recht hat.

• Das Kernproblem liegt darin, dass moderne Tools anders sind als klassische Desktops wie Smalltalk-Workstations oder Emacs.
  Solche Umgebungen waren eine vollständig integrierte Umgebung, alles lag in den Händen des Nutzers, und Konzepte für End-User-Programming waren eingebaut.
  In org-mode kann man im Handumdrehen ansehnliche Folien erstellen, schnell Code-Snippets schreiben, ausführen und Ergebnisse bekommen.
  Aus Dashboard-Sicht gibt es allerdings große Grenzen. Man kann Daten zwar schnell plotten, aber das Ergebnis ist eher ein grobes statisches Bild; wenn man es mit PGF/TikZ schön machen will, dauert es zu lange, um eine echte Option zu sein, und es bleibt trotzdem statisch.
  Emacs selbst ist das richtige Werkzeug, aber es ist ein Werkzeug aus einer älteren Ära.
  Moderne Tools bieten schickere und schnellere Bedienung, sind aber in unflexiblen UIs gefangen, die nur sehr begrenzte Aktionen erlauben, und sie sind auch nicht mit anderem integriert.
  R ist zusammen mit RStudio/quarto vielleicht der schnellste Weg, schnell und schmutzig, aber dennoch gut aussehende Inhalte zu erstellen, kommt aber bei Weitem nicht an die Flexibilität von Emacs heran.
  Letztlich scheint es keine Lösung zu geben, solange man nicht auf Basis des klassischen Paradigmas und der Leistung moderner Hardware den gesamten modernen Software-Stack neu schreibt.