In Folge 343 von MY DATA IS BETTER THAN YOURS (MDIBTY) spricht Jonas Rashedi mit Eva Schreyer (Teamlead Analytics & Prozessmanagement, auxmoney) über Wie auxmoney zum zweiten Mal in vier Jahren die Datenplattform wechselt. Konkret: Eine Migration ist die seltene Gelegenheit, bewusst auszusortieren. Erst Bestandsaufnahme, was migriert werden muss — und ausdrücklich auch, was nicht — dann mit etwas Leichtem anfangen statt mit dem Dringendsten.
3 Erkenntnisse aus dieser Folge
- 01
Eine Migration ist die seltene Gelegenheit, bewusst auszusortieren. Erst Bestandsaufnahme, was migriert werden muss — und ausdrücklich auch, was nicht — dann mit etwas Leichtem anfangen statt mit dem Dringendsten.
- 02
Dashboards taugen als Hygienefaktor, nicht als Begründung. Was fehlt, sind definierte Ober- und Untergrenzen: ab wann ist eine Schwankung saisonal und ab wann ein Geschäftsproblem?
- 03
Das Team hätte die alten SAS-Skripte per Agent nach Snowflake übersetzen können — und hat es bewusst nicht getan, weil eine Migration die Chance ist, den Prozess selbst zu verbessern statt ihn zu konservieren.
Worum es in dieser Folge geht
Vor über vier Jahren habe ich mit Marius von auxmoney über eine Migration gesprochen: weg von der alten Welt, hin zu Exasol, dazu Sisense als Visualisierungstool. Jetzt sitzt mir Eva Schreyer gegenüber und erzählt, dass sie genau das wieder ablösen — auf Snowflake, bei der Visualisierung hatte Tableau Sisense schon vorher ersetzt. Und mit SAS zieht auch das Statistik-Tool in dieselbe Plattform um.
Eva ist Teamlead Analytics und Prozessmanagement bei auxmoney und verantwortet die operativen Datenprozesse rund um Customer Management und Customer Service — Lastschriften, Mahnstufen, Kundenansprache. Ihr Team umfasst mit ihr vier Personen, im gesamten Datenbereich arbeiten rund 50. Sie ist noch nicht lange dabei und hat sich für dieses Gespräch bewusst viel Hintergrund von Marius geholt.
Was diese Folge für mich besonders macht: Eva sagt an mehreren Stellen offen, was sich heute noch nicht belegen lässt.
Die Storyline
Warum viele Dashboards nichts erklären
Eva ist in der Bubble bekannt für eine klare Position: zu viele Dashboards, zu wenig Klarheit. Die hat sich auch im operativen Job nicht geändert.
Dashboards sind super für Hygienefaktoren. Ich glaube, dass sie ganz oft dafür verwendet werden, Sachen zu begründen — und das ist zu kurz gegriffen.
Ihr Beispiel ist aus dem eigenen Alltag: Man sieht im Dashboard, wie sich zurückgerufene Lastschriften entwickeln. Warum sie sich so entwickeln, sieht man nicht. Dafür braucht es die Tiefenanalyse — und die dauert deutlich länger, als ein Dashboard zu bauen. Genau davor, sagt sie, scheuen Firmen zurück.
Was ihr in der Praxis am häufigsten fehlt, sind definierte Ober- und Untergrenzen. Nicht die Frage, ob eine Kennzahl von 35 auf 30 auf 25 Prozent fällt, sondern die Frage, ab wann reagiert werden muss und was noch normale Saisonalität ist. Dazu passt der Treiberbaum mit einem North Star, den sie aus einer früheren Firma kennt: gute Idee, schwer umzusetzen — aber der Kern stimmt, nicht alle KPIs stehen auf derselben Stufe.
Die Migration: erst aufräumen, dann anfangen
Auf meine Frage nach einer Blaupause kommt eine Antwort, die ich so schon lange nicht mehr gehört habe: Jahresbasis.
Der Ablauf im Team ist trotzdem beschreibbar. Erst Bestandsaufnahme: Was muss überhaupt migriert werden — und, mindestens genauso wichtig, was nicht. Eine Migration ist für Eva die Gelegenheit, endlich mal auszusortieren. Dann der Einstieg, und zwar bewusst nicht beim Dringendsten.
Ich bin immer ein Fan davon, dass man nicht mit dem Dringendsten und Komplexesten anfängt, sondern mit etwas Leichtem, damit man schon ein bisschen Learning hat.
Angefangen haben sie deshalb mit Monitoring-Prozessen — Prozessen, die überwachen, dass Kundinnen und Kunden korrekt behandelt werden, etwa beim Rutschen in die nächste Mahnstufe. Einer davon lief im Altsystem rund vier Stunden. In Snowflake dauert er zehn Minuten, bei gleicher Datenmenge — wobei Eva fairerweise dazusagt, dass nebenbei auch ein bisschen optimiert wurde.
Der eigentliche Gewinn ist für sie nicht die Zahl, sondern die Flexibilität: Der Prozess lässt sich jederzeit ausführen, statt darauf zu warten, dass jemand vier Stunden nebenher ein Programm laufen lässt.
Die Stelle, an der ich zu früh gefragt habe
Ich habe nachgebohrt: Gibt es eine Baseline vorher-nachher, mit der sich das belegen lässt? Vier Stunden auf zehn Minuten ist schneller, aber als Unternehmen spare ich dadurch nicht automatisch Geld.
Noch ist es bei uns im Team schwierig zu sagen, weil wir die großen Prozesse erst migrieren. Wir wissen effektiv noch nicht, wie schnell es ist.
Das ist die ehrlichste Antwort der Folge. Ihr eigenes Fazit dazu ist ebenso nüchtern: Für die operative Arbeit ist es ein Traum, schnell die richtigen Daten zu haben — für C-Level ist das noch nicht genug.
Die Argumentation, die sie stattdessen anbietet, dreht die Frage um. Nicht: Was bringt die Migration? Sondern: Was wäre heute nicht möglich, hätten wir sie nicht gemacht? Die Antwort liegt im Datenmodell. Die zentralen Teams stellen die Tabellen jetzt strikt im Star-Schema bereit — keine Redundanzen mehr, keine Tabelle, die etwas anderes sagt als die nächste.
Der Weg, den sie bewusst nicht gegangen sind
Das Team hätte es sich leicht machen können. Prozesse eins zu eins nehmen, die alten SAS-Skripte durch ein Modell schicken, fertig — Agenten dafür waren sogar gebaut.
Bei Prozessen, die im sechs- oder siebenstelligen Bereich Geld einbringen, macht es keinen Sinn, das 1000-Zeilen-SAS-Skript einfach durch die KI zu schmeißen.
Stattdessen arbeiten sie eng mit den Data Engineers, modularisieren, schreiben testbaren Code — und nehmen in Kauf, dass es länger dauert. Das Management hat ihnen dafür ausdrücklich die Freiheit gegeben, nicht nur schnell, sondern gut zu migrieren. Der Plan steht auf Ende des Jahres, dann wären es gut zwei Jahre.
Nebenbei bestätigt Eva das Bild, das ich aus vielen Folgen kenne: Die Organisation ist in vier Jahren vom zentralen Modell in eine Hub-and-Spoke-Struktur gewachsen. Data Infra und BI bauen zentral die Pipelines, die Fachbereiche sitzen als Spokes dran und werden zunehmend zu den Anforderern. Für mich ist das mein liebstes Reifegrad-Indiz überhaupt.
KI im Customer Service — und wo sie aufhört
Neben der Migration läuft der Alltag weiter, und da arbeitet auxmoney längst mit KI: Intent Recognition auf eingehenden E-Mails, von denen es monatlich mehrere tausend bis zehntausende gibt, damit die richtigen Leute die richtigen Mails sofort in die Queue bekommen. Dazu der Self-Service-Gedanke in der eigenen App.
Der Prozess, den Eva am liebsten beschreibt, ist ein anderer: Kundinnen und Kunden, die eine Lastschrift zurückgezogen haben, möglichst schnell erkennen und an die Telefonie übergeben — bevor sie in die nächste Mahnstufe rutschen. In über 30 Prozent der Fälle lässt sich das gemeinsam lösen. Das ist in diesem Markt richtig gut, und es ist ein Fall, in dem Effizienz und guter Service dasselbe sind.
Wo sie die Grenze zieht, deckt sich mit dem, was wir bei FALKE im Customer Service gelernt haben: erst die einfachen, klar abgrenzbaren Anfragen automatisieren, dann tiefer gehen. Und akzeptieren, dass Kundinnen und Kunden nicht prompten können.
Gerade wenn man nicht im technischen Bereich arbeitet, kann man nicht erwarten, dass Kunden perfekte Prompts stellen.
Die ersten 90 Tage
Zum Schluss habe ich Eva gefragt, was sie einer Kollegin mitgeben würde, die gerade als Teamlead in einem operativen Bereich anfängt. Ihre Antwort hat nichts mit Technik zu tun.
Erstens: die Prozesse wirklich im Detail verstehen. Als Analystin springt man im Lauf einer Karriere durch Branchen — und Customer Management bei einer Kreditvermittlung hat sehr eigene Prozesse, die man als Kundin eben nicht kennt.
Zweitens: herausfinden, was die Prozesse, die das Team betreut, an Geld einbringen. Das macht Priorisierung entscheidbar, auch wenn man noch nicht jede Entscheidung im Unternehmen nachvollziehen kann.
Wirklich bewusst zu sagen, nee, erst mal will ich das verstehen — das ist eine Herausforderung.
Warum mich das besonders umtreibt
Zwei Dinge nehme ich aus dieser Folge mit. Das eine ist die Frage, die für mich in jeder Migrationsdiskussion fehlt: Ab wann muss ich eigentlich die Technik nachziehen, weil sich die Organisation verändert hat? Bei auxmoney war nicht die Plattform kaputt. Die Organisation ist über das Datenmodell hinausgewachsen, das vor vier Jahren richtig war. Das ist ein gutes Zeichen, kein Versagen — und es ist ein Argument, das ich in Budgetrunden viel zu selten höre.
Das andere ist Evas Ehrlichkeit an der Stelle, an der ich nachgebohrt habe. Ich habe mit vielen Leuten über Migrationen gesprochen, und fast immer bekomme ich eine Zahl. Hier bekomme ich ein "noch nicht, frag mich in einem Jahr". Ich glaube, wir wären als Community weiter, wenn mehr Menschen das so sagen würden — weil sonst genau die Business Cases entstehen, an die hinterher niemand mehr glaubt.
Deshalb bleibe ich bei meiner These: Irgendwann müssen wir Data-Infrastruktur behandeln wie IT-Security oder den Laptop im Onboarding. Ein Minimum, über das man nicht mehr diskutiert. Wenn ihr das in eurem Haus gerade anders erlebt, widersprecht mir gerne — da lerne ich am meisten.