Datenanalyse & Reporting

04 · Aus der Praxis

Drei Fälle aus der eigenen Datenanalyse.

Ein Verknüpfungsfehler in der Ladestrecke, und alle Berichte waren still falsch.

Zwei Marken auf derselben Plattform, getrennte Auswertung von Umsatz und Kosten je Marke. In der Aggregationstabelle wurden die Kosten aber nicht der Marke des Kunden zugeordnet, sondern der Marke der Gegenseite. Nichts daran sah kaputt aus: Die Summen über alles stimmten, nur jede Aufteilung nach Marke war schief, in Dashboards, in Berichten, in jeder Auswertung. Der Agent fand es beim Nachrechnen einer ganz anderen Frage, verfolgte es bis in die Füll-Prozedur des Data Warehouse und legte offen, dass die Ursache eine bewusste Änderung mit guter Absicht war. Es ist die Klasse von Fehler, die nur auffällt, wenn jemand zwei Wege zur selben Zahl rechnet und die Differenz erklärt.

Ein einzelner Karteninhaber, Dutzende Rückbuchungen, und das eigene Regelwerk schwieg.

Der Zahlungsdienstleister meldete eine Betrugsquote, die den Verlust der Zahlungsroute bedeuten konnte. Der Agent zog die Meldung gegen die eigene Datenbank und fand: Sämtliche Betrugsmeldungen und Rückbuchungen stammten von einer einzigen Karte. Ohne diesen einen Kunden lag die Quote im Normalbereich. Er legte die Tageslinie offen und beantwortete die Frage, die zählt: Hätte man es vorher sehen können? Ja, eine einfache Geschwindigkeitsregel hätte am ersten Tag gestoppt. Er stellte außerdem fest, dass die Rückbuchungen im Berichtswesen gar nicht ankamen. Der Schaden wurde in Stufen beziffert, von realisiert bis Worst Case, statt eine einzelne Zahl zu behaupten.

Bezahlte Käufe, die nie in der Auswertung ankamen.

Über fünf Monate hinweg gab es Vorgänge, bei denen der Zahlungsdienstleister kassiert und ausgezahlt hatte, im eigenen Berichtswesen aber keine passende Transaktion existierte. Beide Systeme sahen für sich plausibel aus. Erst der zeilenweise Abgleich zeigte die Lücke. Kein Geldverlust, aber das Berichtswesen war still unvollständig, und jede daraus abgeleitete Kennzahl war es auch. Der Agent benannte die wahrscheinlichste Ursache, stufte es ausdrücklich als nicht dringend ein und formulierte zwei offene Prüffragen an die Fachbereiche, statt sie selbst zu beantworten. Ein solcher Abgleich läuft, einmal gebaut, bei jedem Durchgang mit.

06 · Wer entscheidet was

Wer entscheidet was.

Frage stellen → Daten prüfen → auswerten → gegenprüfen → beziffern → Befund mit Empfehlung vorlegen → bewerten → entscheiden → umsetzen → Wirkung nachmessen

Bewerten und entscheiden liegt beim Menschen. Der Agent liefert die Entscheidungsvorlage, nicht die Entscheidung, und markiert ausdrücklich, was seine Daten nicht hergeben, statt die Lücke zu überspielen.

Dass diese Aufteilung hält, ist über die vergebenen Rechte gesetzt: Der Zugang zur Datenbank ist lesend. Ein Analyse-Agent, der Daten verändern kann, ist kein Analyse-Agent. Jede Aktion landet mit Zeitstempel im Aktivitätsprotokoll, jede Auswertung wird mit ihrer Abfrage abgelegt. Das ist die Prüfspur, an der ein Ergebnis jederzeit nachvollzogen oder widerlegt werden kann.

08 · Grenzen

Was Sie dafür brauchen, und was nicht.

Nicht nötig: ein neues Data Warehouse, ein Werkzeugwechsel, ein Datenmodell-Projekt. Der Agent arbeitet lesend auf Ihrer bestehenden Datenhaltung, egal ob die Ladestrecke von einem Werkzeug oder von Hand gebaut ist. Ihre Auswertungsoberfläche bleibt, wo sie ist. Der Agent ersetzt sie nicht, er beantwortet die Fragen, für die sie nicht gebaut wurde.

Nötig: Lesezugriff auf die relevanten Datenquellen, jemanden auf Ihrer Seite, der die Fachlogik kennt und gegenlesen kann, und die Bereitschaft, die ersten Befunde ernsthaft zu prüfen statt sie durchzuwinken. Der Aufwand auf Ihrer Seite ist gering, aber er ist nicht null.

Zur Vertraulichkeit: Für eine Auswertung sind Kennzahlen, Kohorten und Aggregate nötig, keine personenbezogenen Daten. Ein Pilot lässt sich auf vollständig anonymisierten Daten aufsetzen. Wo ein Fall doch auf Einzelsätze führt, genügt eine interne Kennung ohne Personenbezug.