Die Excel-Show ist abgesetzt - Bühnenbericht von der TDWI

Zehn Minuten vor einem leeren Saal

Der Vortrag vor unserem Slot hatte leicht überzogen. Danach leerte sich der Saal erstmal, und ich stand da, vorne vor der Leinwand, Laptop angesteckt, und schaute auf leere Stuhlreihen. Zehn Minuten, bis es losging.

Nervös war ich nicht direkt. Aber die Fragen liefen natürlich im Kopf: Kommen viele Leute, oder findet das Thema wenig Anklang? Wer kommt da überhaupt - Leute, die nachher Fragen stellen, oder welche, die nebenbei am Handy surfen? Es war mein erstes Mal auf der TDWI, und gleich mit eigenem Vortrag im Track Data Architecture: „Von der Excel-Show zur Data Prime Time bei lead link”, gemeinsam mit Ilona Tag von QUNIS.

Wir schossen noch zwei, drei Fotos. Dann kamen langsam die Leute. Und der Saal füllte sich, zum Glück gut.

Kurz vor Showbeginn: einmal tief durchatmen, Beats im Kopf sortieren

„Ist das nicht etwas, was tausende Firmen machen?”

Die Idee zum Vortrag kam von Ilona. Sie hatte mich gefragt, ob ich Lust hätte, unsere Geschichte gemeinsam zu erzählen, weil das, was wir bei lead link gebaut haben, für ein Fachpublikum spannend sei. Meine erste Reaktion war ehrlich gesagt Skepsis: Puh, ist das nicht etwas, was tausende Firmen jeden Tag machen? Ein paar Quellen anbinden, etwas Businesslogik, Prozesse automatisieren?

Scheinbar nicht. Wir haben ein kurzes Pitch-Doc geschrieben und bei der TDWI-Jury eingereicht. Ein paar Wochen später kam die Zusage.

Rückblickend war meine Skepsis genau der Denkfehler, den ich sonst bei Leuten sehe, die nicht tief im Thema sind: „Wie schwer kann es sein, zwei, drei CSVs abzuholen? Warum braucht es dafür mehr als einen Werkstudenten?” Data-Profis wissen, dass der Teufel im Detail steckt. Dass „Daten werden angeliefert” noch weit weg ist von „Daten werden sauber angeliefert” - und das wieder weit weg von „Daten werden sauber ingested und geladen”. Es rennt eben nicht jede Mittelstandsfirma mit einem Lakehouse in Fabric, 50 Datenquellen und vollautomatisierten Datenprozessen rum. Viele kämpfen noch mit Excel - so wie wir früher, als bei uns mehr Excel-Logik als Kampagnen-Logik im Einsatz war.

Genau das war unsere Story: eine mittelständische Firma, Hidden Champion in ihrer Nische, die sich von Excel verabschiedet und dabei ein richtig gutes System gebaut hat. Erzählt als Serie, in Staffeln - von der Excel-Show zur Data Prime Time. Und erzählt im Dialog: Ilona mit dem technischen Blick auf Architektur und Umsetzung, ich mit der Business- und Kundenperspektive. Dass der Vortrag selbst aus zwei Blickwinkeln bestand, war dabei kein Zufall. Es ist unser erstes Learning in Aktion.

Learning 1: Warum Fachlichkeit und Architektur zusammengehören

Technisch ist fast alles möglich. Aber für ein sauberes System darf man eben nicht alles machen. Die Frage muss immer lauten: Wie ist das transparent und sinnvoll systematisierbar? Fachlich sind oft schnelle Lösungen gewünscht: „mach doch einfach: wenn Sender X, dann Verarbeitung Weg B statt Weg A”. Aber Sonderlocken im Code führen fast immer später zu Chaos. Ein System muss klar sein und beherrschbar.

Der zweite Teil ist Kommunikation. Ich habe mal im Spaß zu einer Kollegin gesagt, die verzweifelt war, warum die Technik nicht einfach umsetzt, was sie will: „90 % des Jobs ist Übersetzungsarbeit.” Die Zahl ist übertrieben, der Kern nicht. Data Engineers schauen aus ihrem technischen Blickwinkel auf ein Thema, die Fachkollegen aus ihrem - und beide denken komplett unterschiedlich.

Ein kleines Beispiel, das tausendfach so passiert: Die Fachseite braucht eine Spalte mit einer bestimmten Info. Die Technik baut die Info stattdessen elegant ins Auswahl-Dropdown ein: weniger Spalten, bei der Auswahl sieht man genau, was man nimmt. Die Fachseite ist frustriert: „Warum nicht meine Spalte? Total unübersichtlich!” Die Technik versteht die Welt nicht mehr: „Die Info ist doch super ersichtlich?” Aufgelöst hat es erst das Verständnis des Prozesses: Die Info war gar nicht bei der Auswahl wichtig, sondern beim Bearbeiten der Übersicht danach. Deshalb half das Dropdown niemandem. Am Ende hilft immer dasselbe: verstehen, erklären, reden.

Und es geht in beide Richtungen. Wir haben etwas etabliert, es funktioniert - und dann kommt die Fachseite und sagt: „Genau hier funktioniert es so aber doch nicht.” Ich habe dazu mal in einem Meeting einen Satz geprägt, der bei den Leuten hängen geblieben ist: Wir hangeln uns von Edge Case zu Edge Case. Das beschreibt ziemlich genau, wie so eine Entwicklung wirklich abläuft. Die Standards sind schnell aufgesetzt - der Teufel steckt im Detail.

Learning 2: Stammdaten früh ernst nehmen (weil ohne sie alles nichts ist)

Auf der Bühne habe ich es so erzählt: Das Architekturkonzept stand, die Technik war klar. Und dann wurde uns klar - die Technik ist nur die halbe Miete.

Was heißt das konkret? Drei Beispiele von der Bühne:

Was ist ein Spot? Klingt banal. Sagt mir jemand „Ich hab letzten Monat 100.000 Spots für Kunde A gebucht”, ist mir sofort klar: 100.000 Ausstrahlungen. Sagt ein anderer „Ich hab drei unterschiedliche Spots für Kunde B gebucht”, ist genauso klar: drei Werbemittel. Menschen erschließen das mühelos aus dem Kontext. Systeme nicht. Für ein System muss eindeutig definiert sein, was ein Spot ist.

Berechnungslogik. Ist ja easy, wir haben ja alle dieselben Zahlen? Weit gefehlt. Kollege A rechnet mit zwei Nachkommastellen, sind ja Euro-Beträge. Kollege B rechnet mit allen Nachkommastellen, ist ja genauer. Kollege C rundet komplett weg, ist ja übersichtlicher. Und jetzt addiere mal 100.000 Spots mit unterschiedlich gerundeten Beträgen und versuche, auf dieselbe Ergebniszahl zu kommen.

Wie Dinge heißen. Kollege A nennt ein neues Produkt „xy”. Kollege B trägt es als „xy_DE” in seine Excel ein, ist ja fürs deutsche Geschäft. Kollege C übernimmt das als „xy DE”. Schon heißt dieselbe Sache intern dreimal anders. Und da reden wir noch nicht von extern, wo jeder Vermarkter das Produkt anders schreibt: einer in Großbuchstaben, einer gekürzt auf acht Zeichen, weil sein System nicht mehr hergibt, der nächste mit Buchstabendreher. Am Ende muss es aber eine Wahrheit geben, wie das Produkt tatsächlich heißt.

Deshalb war Stammdaten bei uns Staffel 1 und kein Nebenschauplatz: Bevor es mit dem System weitergehen konnte, brauchte es das Fachsystem, das vorgibt, wie Dinge heißen, wie gerechnet wird - und was überhaupt was ist.

Learning 3: Metadaten als Steuerungsmechanismus

Das war auf der Bühne Ilonas Part, und ich sage ganz offen: Ich bin zu wenig Data Engineer, um mich hier absolut sattelfest zu fühlen - genau deshalb standen wir ja zu zweit da. Aus meiner Business-Perspektive ist der Kern aber einfach zu erklären: Die Metadaten beschreiben, wie Quellen verarbeitet werden. Quellen werden beschrieben, Verarbeitungsregeln zentralisiert, Ladeprozesse standardisiert - und die Steuerung läuft automatisiert. Damit muss keine Schnittstelle mehr individuell gelöst werden. Eine neue Quelle ist kein neues Projekt mehr, sondern im Kern ein neuer Eintrag.

Konkret gesteuert wird damit der komplette Weg einer Lieferung: erkennen, laden, prüfen, standardisieren, strukturieren. Die Unterschiede zwischen den Quellen - Format, Ablageort, Lieferweg, Frequenz - werden früh abgefangen, statt sich durch die ganze Pipeline zu ziehen. Wie konkret das wird, zeigt unser Data Dictionary: 717 Zeilen, in denen für jedes Feld jeder Quelle steht, aus welchem System und welcher Tabelle es kommt, welchen Datentyp es hat, ob es ein Schlüssel ist, was inhaltlich drinsteht und in welcher Zieltabelle es unter welchem Namen im DWH landet. Das ist ehrliche Fleißarbeit - aber genau sie macht die Automatisierung steuerbar. Das System muss nicht raten, was eine Spalte bedeutet. Es steht da.

Bei 50 Datenquellen, 12 REST-API-Endpoints, 15 Schnittstellen und 7 Mail-Postfächern, die viermal täglich aktualisiert in einem Datenstrom zusammenlaufen, ist das keine akademische Eleganz - es ist die einzige Art, wie drei Data Engineers (und laut Folie 99+ Tassen Kaffee) so ein System betreiben können, ohne darin zu ertrinken.

Im Q&A sorgte das übrigens für ein schönes Missverständnis: Ilona hatte an einer Stelle eine SQL-Datenbank erwähnt, und ein Zuhörer stutzte - läuft die metadatengetriebene Anbindung etwa auf einer klassischen SQL-Datenbank statt auf einem Lakehouse? Nein: Die SQL-Datenbank gehört zum Stammdatensystem. Das DWH selbst ist ein Lakehouse. Zwei Systeme, zwei Jobs.

Learning 4: Standards etablieren heißt Standards verteidigen

Skalierbare Standards klingen auf einer Folie selbstverständlich. In der Praxis werden sie ständig auf die Probe gestellt. Immer wieder kommt der Moment, in dem die schnelle Lösung lockt: Hauen wir diese eine Ausnahme halt in den Code, fertig. Genau da muss man durchhalten und sich die unbequemere Frage stellen: Gibt es einen Weg, diese Quelle trotzdem zu standardisieren - oder die Lösung so zu bauen, dass sie selbst ein Standard wird?

Ilona hat dabei als eiserne Hüterin des Standards fungiert und konsequent hinterfragt: Braucht es hier wirklich eine Sonderlösung? Was die Fachabteilungen nicht immer cool fanden - die hätten oft lieber die schnelle Lösung gehabt. Aber in Summe haben wir eigentlich immer einen sinnvollen Weg gefunden.

Mein Lieblingsbeispiel dafür: Mehrere Vermarkter liefern Einschaltpläne über das standardisierte EDI-Format. In der Theorie super - alles genormt, mit Anleitung. In der Praxis legt jeder den Standard leicht anders aus. Die Auftragsbezeichnung steht bei Vermarkter A im Feld WERBE_FORM, bei B in AUFTR_TIT2, bei C in INT_AUFTR_SCHL. Königsklasse: Bei manchen ist sie über mehrere Spalten verteilt, und dieselben Spalten werden anderswo für ganz andere Infos genutzt. Was machst du jetzt?

Die Lösung kam wieder über Abstraktion: Wie ein Sender seine Auftragsbezeichnung anliefert, ist selbst ein Teil der Senderstammdaten. Die Abweichung landet also nicht als Sonderfall im Code. Sie wird zum Datum und lässt sich damit pflegen wie jedes andere Stammdatum auch.

Der eigentliche Wow-Moment kam nach der letzten Folie

Der Vortrag lief erstaunlich rund durch - nicht selbstverständlich für einen frei gesprochenen Wechselvortrag, den wir erst am Tag davor gemeinsam proben konnten: Ilona reiste erst am Vortag an, und bei mir hatten dringende Themen die Vorbereitungszeit gefressen. Aber Generalprobe und Testpublikum-Durchlauf liefen gut, also los.

Auf einer unserer Folien steht „Der Wow-Moment: Alles lief zusammen” - gemeint ist der Moment im Projekt, als rund 90 % des manuellen Aufwands im Reporting wegfielen und wir plötzlich über Kampagnen sprachen statt über Excel-Dateien. Auf der Bühne gab es diesen Moment auch. Er kam nur nicht, während wir sprachen.

Wir hatten bewusst rund 15 Minuten für Q&A gelassen. Da zeigt sich gnadenlos, ob die Leute dabei waren oder längst am Handy. Es kamen so viele Fragen von so unterschiedlichen Leuten, dass wir die Zeit komplett ausgereizt haben.

Ob uns bei Fabric auch mal die Capacity abgeraucht sei? Ja, kam vor. Welche Capacity zu den eigenen Needs passt, muss man schlicht testen. Welche Alternativen zu Fabric im Rennen waren und welche Rolle Kosten spielten? Fabric war auf dem Papier ein guter Fit, das Gesamtpaket passte. Mut gab uns außerdem, dass wir mit dbt systemagnostisch gebaut haben: Wenn wirklich alles abraucht, wechseln wir die Plattform. Ein Take, der sich vermutlich schwer verkaufen lässt, aber uns ruhig schlafen lässt.

Jemand kämpfte noch mit Faxen und wollte wissen, wie wir das gelöst hatten. Faxe haben wir zwar nicht mehr, aber für PDFs einen n8n-Workflow mit OCR und LLM-Unterstützung, der sie in die Datenbank überführt. Und eine Frage haben wir länger besprochen: Was tun, wenn Daten einfach nicht in der gebrauchten Form oder nicht konstant geliefert werden? Da hilft am Ende vor allem Kommunikation mit den Datenlieferanten: intern wie extern erklären, warum es das braucht und warum es für alle ein Vorteil ist, wenn es richtig kommt. Abseits der Technik gibt es generell viele Dinge, die man nicht unterschätzen darf.

Selbst danach war noch nicht Schluss: Im Flur kam eine Zuhörerin auf mich zu, die eine spezifische Frage vertiefen wollte.

Was mir erst beim Vorbereiten klar wurde

Auf der Bühne selbst ist übrigens kein Raum für große Reflexion - die eigentlichen Erkenntnisse passieren vorher, beim Strukturieren, beim Auswählen der Anekdoten, beim Verknüpfen von Einzelbeispielen zu einer großen Story. Einen Vortrag vorzubereiten ist, so gesehen, die beste Retrospektive, die du deinem eigenen Projekt gönnen kannst.

Drei Dinge sind mir dabei nochmal richtig bewusst geworden. Wie oft wir die Sauberkeit des Systems verteidigt haben, statt den einfachen Ausweg zu nehmen. Wie intensiv die Zusammenarbeit wirklich war: wie viele Stunden wir die Köpfe zusammengesteckt und Dinge durchgegangen sind, bis sie saßen - dass unser Vortrag als Dialog funktionierte, war nur die logische Fortsetzung davon. Und wie viel der frühe Plan wert war. Klar weicht man unterwegs ab, weil man bessere Lösungen findet. Aber es ist bis heute immer klar, wo die Reise hingeht und was die nächsten Schritte sind.

Was ich beim nächsten Mal anders machen würde

Ehrlicherweise: Inhaltlich lief es gut, die Stolpersteine waren Konferenz-Handwerk. Aber die ärgern mich trotzdem.

Der größte: Es gibt kein wirklich gutes Foto vom Vortrag mit Publikum. Wir haben vorher zwei, drei Bilder vor leerem Saal gemacht, und ein Kollege von QUNIS hat aus dem Publikum ein paar Aufnahmen geschossen - aber die sind alle weit weg, und wir stehen ungünstig. So ein Moment kommt nicht wieder. Beim nächsten Mal ziehen wir das bewusster auf: vorher absprechen, wer wann von wo fotografiert. Kleinigkeit Nummer zwei: Auf unserer Kontaktfolie waren drei QR-Codes zu nah beieinander: Ilona, ich, Feedback-Bewertung. Wer aus dem Publikum gezielt einen scannen wollte, hatte vermutlich seinen Spaß. Und eine Sache weiß ich schlicht bis heute nicht: ob die TV-Metapher mit den Staffeln wirklich gezündet hat. Ich glaube ja, sie hat den Vortrag gut getragen - aber explizit gesagt hat dazu niemand etwas. Beim Q&A fragt eben keiner nach der Dramaturgie.

Wenn du dir nur eine Sache merkst

Auf der Bühne habe ich es so gesagt: Wenn ihr euch genau eine Sache merkt - und ich hoffe, ihr merkt euch viele, aber wenn es nur eine ist - dann die: Die Basis ist das Allerwichtigste. Wenn die Datenbasis sauber, nachvollziehbar und strukturiert ist, klappt auch der Rest. Wenn nicht, wird auch der Rest nichts.

Das ist deshalb so wichtig, weil solche Projekte fast nie von der Basis her getrieben werden. Niemand aus dem Business wünscht sich ein tolles Stammdatensystem. Gewünscht werden schöne Dashboards, Reports, mehr Automatisierung. Aber all das ist die Folge davon, am Anfang die Hausaufgaben zu machen.

Und das Zweite: Der Teufel steckt immer im Detail. Auch du wirst dich von Edge Case zu Edge Case hangeln und dich fragen, wie du dir das jemals leichter vorstellen konntest. Und am Ende wird es sich trotzdem lohnen.

Und falls du mich lieber auf einer Bühne siehst statt liest: Bei ADZINE gibt es eine frei abrufbare Aufzeichnung von mir zu einem anderen Datenthema - wie man Werbewirkung über TV, CTV und Co. hinweg vergleichbar macht. Spoiler: Wirkung misst man beim Kunden, nicht auf der Plattform.

Warst du auch auf der TDWI - oder sitzt du gerade selbst vor deiner Excel-Show? Schreib mir auf LinkedIn, ich bin gespannt auf deine Geschichte.

P.S.: Frei vor Publikum sprechen funktioniert bei mir wie ein gutes RPG: Ich speichere die Beats als Save Points im Kopf ab - und was zwischen den Speicherpunkten passiert, wird live gespielt. Klingt riskant, aber genau da entstehen die besten Momente.