Testergebnisse
Was davon auf einem echten System tatsächlich funktioniert.
Der Rest dieser Website erklärt, wie das System arbeiten soll. Diese Seite zeigt, was dabei herausgekommen ist: auf einem gewachsenen Produktivsystem und zur Gegenprobe an drei fremden Systemen, die nichts miteinander zu tun haben.
Kein Kundenname, keine Branche, keine ausgesuchten Vorführfragen. Die Fälle, die nicht wie vorgesehen ausgingen, stehen mit auf dieser Seite.
verhielten sich im Referenztest fachlich wie vorgesehen.
Abfrageszenarien wurden ohne strukturellen Befund verarbeitet.
Referenztest
Ein Katalog aus 33 unterschiedlich komplexen Fachfragen – von einfachen Zählungen bis zu mehrstufigen Auswertungen über mehrere fachliche Zusammenhänge. 31 davon waren fachlich bewertbar.
27 von 31 bewertbaren Fällen verhielten sich wie vorgesehen.
Als bestanden zählt nicht nur die richtige Zahl. Auch die begründete Verweigerung ist das gewünschte Verhalten: Das System soll nicht um jeden Preis eine Zahl erzeugen, sondern nur dann antworten, wenn die fachliche Auslegung der Frage ausreichend abgesichert ist.
- 23
- Erwartetes Referenzergebnis
- Die Antwort stimmte mit dem Ergebnis überein, das aus dem System bereits bekannt war.
- 4
- Begründet abgelehnt
- Die Frage wurde erwartungsgemäß nicht beantwortet, weil die fachliche Grundlage für eine sichere Antwort fehlte. Diese Fälle zählen als bestanden – die Ablehnung war das gewünschte Verhalten.
- 1
- Andere, vertretbare Lesart
- Die Frage ließ mehr als eine fachliche Auslegung zu. Das Ergebnis war für die gewählte Auslegung richtig, entsprach aber nicht der erwarteten.
- 3
- Fachlicher Fehlbefund
- Die verbleibenden Fälle der 31 bewertbaren gingen nicht wie vorgesehen aus. Sie sind die Grundlage der aktuellen Weiterentwicklung.
Rechnet man die vertretbare andere Lesart hinzu, zeigten 28 von 31 Fällen – mehr als 90 % – keinen eindeutigen fachlichen Fehlbefund.
Der wichtigste Einzelbefund
Warum eine plausible Antwort trotzdem falsch sein kann.
Bei der Auswertung historischer Geschäftsdaten enthielt ein zentraler Datenbereich nicht den aktuellen Zustand eines Vorgangs, sondern dessen vollständige Änderungshistorie. Im Schema ist das nicht erkennbar.
Eine technisch völlig korrekte Auswertung lieferte deshalb zunächst ein Ergebnis, das um den Faktor 6 danebenlag. Beide Zahlen wirken ohne Kenntnis der internen Geschäftslogik plausibel – und genau deshalb wäre die falsche in keinem Bericht aufgefallen.
Erkannte Geschäftsregeln werden dauerhaft im semantischen Modell hinterlegt und ab dann bei jeder Auswertung berücksichtigt.
Derselbe Datenbestand, dieselbe Frage. Der Unterschied liegt allein darin, ob die Historisierung als solche erkannt wird.
Gegenprobe
Gute Ergebnisse auf dem System, an dem entwickelt wurde, sagen wenig aus. Deshalb wurde derselbe Ansatz an 3 vollständig unabhängigen Softwaresystemen geprüft.
27 von 30 Abfrageszenarien wurden vollständig verarbeitet.
Die 3 übrigen Szenarien betrafen fachliche Funktionen, die es im jeweiligen Testsystem gar nicht gab. Innerhalb der tatsächlich vorhandenen Szenarien blieb kein struktureller Befund offen.
Worin sich die Systeme unterschieden
- Datenmodell und Datenmenge
- Benennung von Tabellen und Spalten
- Umfang der vorhandenen Metadaten
- Art der Beziehungen zwischen Datenobjekten
- Datenbanktechnologie – im Test MySQL und PostgreSQL
- Qualität des vorhandenen Schemas, ein System ganz ohne Fremdschlüssel
Damit ist gezeigt, dass die Architektur nicht auf eine bestimmte Anwendung oder Datenbank zugeschnitten ist. Sie ist an 3 fremden Systemen geprüft – das ist etwas anderes als eine allgemeine Zusage für jedes System.
Belegt durch die Tests
Nicht die Roadmap, sondern das, was in den beschriebenen Testläufen nachweislich funktioniert hat.
Natürliche Fragen auf Unternehmensdaten abbilden
Fragen in der Sprache des Fachbereichs werden auf das semantische Modell aufgelöst, ohne dass Tabellen oder Spalten genannt werden müssen.
Mehrstufige Beziehungen verfolgen
Auswertungen über mehrere verbundene Geschäftsobjekte hinweg, nicht nur über eine einzelne Tabelle.
Gruppierungen und Schwellenwerte auswerten
Fragen der Form „welche … mehr als …“ werden als Gruppierung mit Bedingung aufgelöst statt als Freitextsuche.
Zeiträume und Zeitbezüge unterscheiden
„Dieses Jahr“ wird auf das fachlich gemeinte Datum bezogen – Erfassung, Rechnung oder Buchung sind nicht dasselbe.
Kennzahlen und Summen bilden
Bestände, Summen und Quoten werden nach der im Modell hinterlegten Rechenregel gebildet.
Statuswerte gegen echte Daten absichern
Statuscodes werden gegen die tatsächlich vorkommenden Werte geprüft, statt aus dem Spaltennamen abgeleitet zu werden.
Historische Datenstrukturen korrekt interpretieren
Enthält ein Datenbereich Änderungshistorie statt Gegenwart, wird das berücksichtigt – der Befund unten zeigt, warum das entscheidend ist.
Beziehungen in unvollständigen Schemata erschließen
Auch ohne hinterlegte Fremdschlüssel werden Zusammenhänge aus der vorhandenen Struktur abgeleitet.
Entwicklungsstand
Woran aktuell gearbeitet wird.
Die darunterliegende Daten- und Abfrageschicht verarbeitet bereits komplexe Abfragestrukturen. Der wichtigste offene Punkt liegt eine Ebene darüber: die Übersetzung besonders komplex formulierter natürlicher Fragen in den richtigen fachlichen Abfrageplan.
Diese Trennung ist Absicht und nicht Zufall der Reihenfolge. Sie ist der Grund, warum sich das Sprachverständnis weiterentwickeln lässt, ohne die Sicherheit des Datenzugriffs anzufassen.
Das Sprachmodell interpretiert die Frage. Die eigentliche Datenabfrage bleibt kontrolliert, prüfbar und deterministisch.
Einordnung
Was diese Zahlen nicht hergeben.
Wer diese Seite liest, rechnet ohnehin nach, wie belastbar eine Quote bei 31 Fällen ist. Deshalb steht die Einschränkung hier und nicht im Kleingedruckten.
- Es ist ein Referenzsystem, kein Durchschnitt
- Die 87 % beziehen sich auf ein gewachsenes System. Ein anderes System mit anderer Fachlichkeit kann besser oder schlechter abschneiden.
- Die Stichprobe ist klein
- 33 Fragen und 30 Szenarien sind genug, um Schwächen zu finden, und zu wenig für eine belastbare Fehlerquote. Sie werden hier als das dargestellt, was sie sind.
- Die Fragen stammen noch nicht von fremden Fachanwendern
- Der Katalog wurde für die Validierung zusammengestellt. Fragen, die Anwender eines fremden Unternehmens spontan stellen, sind der nächste und härtere Test.
- Geprüft wurde die Datenschicht, nicht der Betrieb über Monate
- Aussagen zu Verhalten unter Dauerlast, zu Pflegeaufwand über ein Jahr oder zu Betriebskosten lassen sich daraus nicht ableiten.
Der nächste Schritt sind weitere reale Systeme – mit Fragen, die von deren Fachanwendern selbst kommen.