Dashboard und Datenpipeline zeigen verschiedene Zahlen. Wer hat recht?

Meist hat keiner von beiden recht, weil keinem von beiden je gesagt wurde, was “richtig” bedeutet. Wenn ein Dashboard und die Pipeline darunter nicht übereinstimmen, liegt es fast immer an einer fehlenden Definition oder an einem Verarbeitungsschritt, der die Zahl verändert, ohne dass es jemand merkt. Sie finden die Ursache, indem Sie eine einzige Zahl für einen kurzen Zeitraum durch jede Schicht verfolgen, bis die beiden Werte auseinanderlaufen. Sie beheben sie mit einer schriftlichen Definition und einem automatischen Test, der sie prüft. Gebraucht wird eine Definition plus ein Test, kein neues Tool.

Das ist wichtiger, als es aussieht. Sobald Menschen einer Zahl nicht mehr trauen, bauen sie sie in ihrer eigenen Excel-Datei nach, und aus zwei Zahlen werden drei. Die eigentlichen Kosten sind all die Meetings, die mit “Welche Version ist das?” beginnen.

Zuerst prüfen: Messen beide dasselbe?

Bevor Sie irgendetwas debuggen, bitten Sie beide Seiten, in einem Satz zu sagen, was ihre Zahl zählt. Oft stellt sich heraus, dass es ein Benennungsproblem ist. Der “Umsatz” der Buchhaltung ist der fakturierte Betrag abzüglich Gutschriften, nach Rechnungsdatum. Der “Umsatz” im Dashboard ist der Bestellwert beim Checkout, einschließlich später stornierter Bestellungen.

Beide Zahlen können stimmen. Sie beantworten unterschiedliche Fragen. Wenn das der Befund ist, geben Sie den beiden Zahlen unterschiedliche Namen und legen fest, welche die Geschäftsführung sieht. Technischer Aufwand: keiner.

Sollen es wirklich dieselbe Zahl sein, geht es weiter mit der Rückverfolgung.

So verfolgen Sie eine Zahl von der Quelle bis zum Diagramm

Wählen Sie eine Kennzahl und einen kurzen Zeitraum. Ein einzelner Tag ist ideal. Ein Monat verdeckt zu viel.

Dann berechnen Sie die Zahl auf jeder Schicht nach, die sie durchläuft:

1. Das Quellsystem. Die Anwendungsdatenbank, das ERP, das CRM. Das System, das im Unternehmen als Aufzeichnung dessen gilt, was tatsächlich passiert ist.
2. Die Rohdaten im Data Warehouse oder in der Analysedatenbank, so wie der Loader sie abgelegt hat.
3. Jedes Modell und jede Transformation zwischen Rohdaten und Reporting-Tabelle.
4. Die Abfrage, die das Dashboard ausführt, einschließlich aller Filter, die direkt im BI-Tool gesetzt sind.

Notieren Sie auf jeder Stufe zwei Werte: die Summe und die Zeilenanzahl. Die Stufe, auf der sich einer davon gegenüber der vorherigen ändert, ist die Stelle, an der das Problem sitzt. Dann gehen Sie auf einzelne Datensätze herunter. Suchen Sie eine Bestellung, die an einer Stelle auftaucht und an der anderen nicht, und verfolgen Sie sie.

Ein Beispiel zur Veranschaulichung. Das Dashboard zeigt 412 Bestellungen für den 3. September. Die Quelldatenbank zeigt 398. Die Rohtabelle im Warehouse: 398. Das bereinigte Bestellmodell: 398. Die Reporting-Tabelle: 412. Die 14 zusätzlichen Bestellungen entstehen also in der letzten Transformation. Bei genauerem Hinsehen sind es durchweg Bestellungen mit zwei Lieferungen, und das Reporting-Modell verknüpft Bestellungen per Join mit Lieferungen. Ein Nachmittag und ein paar Abfragen. Kein neues Tool.

Zwei praktische Hinweise. Machen Sie die Rückverfolgung gemeinsam mit jemandem, der den Geschäftsprozess kennt, denn “Zählt dieser Datensatz mit?” ist eine fachliche Frage. Und speichern Sie jede Abfrage, die Sie unterwegs schreiben. Daraus werden später Ihre Tests.

Die fünf häufigsten Ursachen

Nach unserer Erfahrung entsteht die Abweichung fast immer aus einer dieser Ursachen.

1. Unterschiedliche Definitionen. Brutto oder netto. Mit oder ohne Mehrwertsteuer. Zählen Testkunden als Kunden oder nicht. Eine Seite schließt interne Konten und Testkonten aus, die andere nicht. Das ist die häufigste Ursache, und keine Technologie behebt sie allein.

2. Zeit. Zu welchem Datum gehört ein Datensatz: Anlage, Zahlung, Versand, Rechnung? In welcher Zeitzone? Eine Bestellung, die am letzten Tag des Monats um 23:30 Uhr in Berlin aufgegeben wird, landet im Folgemonat, wenn die Pipeline in UTC rechnet. Beim Monatsabschluss fällt das zuerst auf.

3. Aktualität und verspätete Daten. Das Dashboard liest eine Tabelle, die um 6:00 Uhr aktualisiert wurde. Der Export der Buchhaltung stammt von 11:00 Uhr. Oder eine Quelle liefert verspätet, eine Gutschrift kommt drei Tage nach der Bestellung, und niemand verarbeitet den früheren Zeitraum neu. Beide Zahlen waren zum Zeitpunkt ihrer Erhebung korrekt.

4. Joins, die Zeilen verdoppeln oder verlieren. Wie im Beispiel oben: Ein Join mit einer Tabelle, die mehrere Zeilen pro Bestellung hat, vervielfacht die Bestellungen. Das Gegenteil kommt auch vor: Ein Inner Join mit den Kundenstammdaten entfernt stillschweigend alle Bestellungen, deren Kunde fehlt. Die Summen verschieben sich, und es gibt keine Fehlermeldung.

5. Logik, die im Dashboard versteckt ist. Ein Filter im BI-Tool, ein berechnetes Feld, das jemand letztes Jahr angelegt hat, ein zwischengespeicherter Extrakt, der nicht mehr aktualisiert wird. Diese Logik ist vom Warehouse aus unsichtbar. Das Pipeline-Team sieht sie nicht, und das Dashboard-Team hat vergessen, dass es sie gibt.

Eine sechste Ursache ist seltener, aber schmerzhafter: Die Quelle selbst hat sich geändert. Ein neuer Bestellstatus, ein umbenanntes Feld, ein Produkt, das in ein anderes Abrechnungsmodell gewechselt ist. Die Pipeline läuft weiter und liefert stillschweigend eine andere Zahl.

Was hilft: eine Definition plus ein Test

Wenn die Ursache gefunden ist, ist dieser eine Fehler schnell behoben. Die eigentliche Arbeit besteht darin, den nächsten abzufangen, bevor ihn jemand auf eine Folie schreibt.

Schreiben Sie die Definition auf. Ein kurzer Absatz pro Kennzahl: was zählt, was ausgeschlossen ist, welches Datum, welche Zeitzone, welche Währung, wer verantwortlich ist. Legen Sie ihn neben das SQL, das die Kennzahl berechnet, unter Versionskontrolle, damit Dokument und Code sich gemeinsam ändern. Liegt die Definition in einem Wiki und die Logik im BI-Tool, laufen beide früher oder später auseinander.

Holen Sie die Logik aus dem Dashboard. Filter und berechnete Felder, die eine Kennzahl definieren, gehören in die modellierten Tabellen, wo sie versioniert und testbar sind. Das Dashboard soll Zahlen nur anzeigen.

Machen Sie aus der Rückverfolgung Tests. Die Abfragen, die Sie bei der Suche geschrieben haben, sind genau die Tests, die Sie brauchen. Typische Beispiele:

• Die Reporting-Tabelle hat genau eine Zeile pro Bestellung (ein Eindeutigkeitstest auf der erwarteten Granularität).
• Die Summe in der Reporting-Tabelle stimmt für den Vortag mit der Summe im Quellsystem überein, innerhalb einer vereinbarten Toleranz.
• Jede Bestellung hat einen passenden Kunden, oder die fehlenden werden gezählt und gemeldet.
• Jede Quelltabelle wurde innerhalb des erwarteten Zeitfensters aktualisiert.

Werkzeuge wie dbt machen solche Tests leicht zu schreiben und bei jedem Build auszuführen, die Dokumentation zu Data Tests ist ein guter Einstieg. Einfache SQL-Prüfungen, die ein Scheduler startet, funktionieren ebenfalls. Entscheidend ist, dass ein fehlgeschlagener Test bei einer Person ankommt, die handeln kann, genau wie ein fehlgeschlagener Health Check bei einem Produktivsystem.

Benennen Sie eine verantwortliche Person oder ein Team. Jede zentrale Kennzahl braucht jemanden, der entscheidet, was sie bedeutet, wenn sich das Geschäft ändert. Ohne diese Zuständigkeit veraltet die Definition, und die Diskussion kommt zurück.

Wann dieser Rat falsch ist

Wenn die Abweichung keine Rolle spielt. Unterscheiden sich die beiden Zahlen nur geringfügig und würde sich keine Entscheidung ändern, dokumentieren Sie den Grund und machen Sie weiter. Bei einer Kennzahl, die nichts steuert, der letzten Einheit hinterherzulaufen, ist schlecht investierte Zeit.

Wenn die Quelle der rechtlich maßgebliche Beleg ist. Beim Umsatz zählt die Buchhaltung. Sie ist das, was Steuerberatung, Wirtschaftsprüfung und Finanzamt sehen. Weicht das Dashboard davon ab, ist das Dashboard per Definition falsch, und die Aufgabe ist, es anzugleichen oder die Differenz zu erklären.

Wenn es ein Dashboard und eine Analystin oder einen Analysten gibt. Baut eine einzige Person die Pipeline und das Diagramm und liest beides selbst, ist ein formaler Definitionskatalog Overhead. Beheben Sie den Fehler, ergänzen Sie ein oder zwei Tests und machen Sie weiter. Formalisieren Sie, sobald ein zweites Team die Zahl zitiert.

Wenn das eigentliche Problem ist, dass niemand hinsieht. Manchmal überlebt eine Abweichung monatelang, weil keine der beiden Zahlen eine Entscheidung steuert. Dann ist der richtige Schritt vielleicht, eine davon abzuschaffen.

FAQ

Warum stimmen die Zahlen im Dashboard nicht mit der Datenbank überein?

Meist wegen einer abweichenden Definition, einer anderen Datumslogik, unterschiedlicher Aktualisierungszeitpunkte, fehlerhafter Joins oder Filter im BI-Tool. Verfolgen Sie einen Tag an Daten durch jede Schicht und vergleichen Sie auf jeder Stufe Summe und Zeilenanzahl, um die Stelle zu finden, an der sie auseinanderlaufen.

Sollten wir ein Data-Observability-Tool kaufen?

Nicht als ersten Schritt. Solche Tools helfen, wenn Sie wissen, was geprüft werden soll, und viele Tabellen überwachen müssen. Solange nicht schriftlich festgehalten ist, was Ihre wichtigsten Kennzahlen bedeuten, warnt Sie ein Tool vor den falschen Dingen. Beginnen Sie mit Definitionen und einigen SQL-Tests.

Wer sollte für die Definition einer Kennzahl verantwortlich sein?

Das Team, das mit ihr Entscheidungen trifft, bei allem rund um Umsatz in der Regel zusammen mit der Buchhaltung. Das Datenteam setzt die Definition um und testet sie. Die Fachseite entscheidet, was sie bedeutet.

Wie wir daran arbeiten

Dieses Problem liegt genau an der Grenze zwischen Infrastruktur und Analyse, deshalb bearbeiten wir beides mit einem Team. Wir verfolgen Ihre zentralen Zahlen von der Quelle bis zum Dashboard, beheben die Stellen, an denen sie abweichen, und hinterlassen Definitionen und Tests in Ihrem Repository. Liegt die Lücke in den Pipelines, ist das unsere Arbeit an Datenplattformen und Pipelines. Liegt sie in Definitionen und Dashboards, sehen Sie sich Datenanalyse und KPI-Dashboards an.