Bahlsen Group: Ein Data-&-AI-Estate übernommen, das niemand kartiert hatte

Im Juli 2026 habe ich als Interim Head of Data & AI eine Plattform übernommen, die ich nicht gebaut habe. Darunter lag jahrelange Arbeit von internen Kolleginnen und Kollegen und externen Partnern: eine Cloud-Landing-Zone, ein Warehouse auf BigQuery, eine Transformationsschicht in dbt, darüber die BI-Schicht, eine selbst betriebene Runtime, die jeden geplanten Job ausführt, und eine Schublade voller interner Anwendungen.

Technisch war das überwiegend solide. Was fehlte, war ein Dokument, das erklärt, wie es zusammenhängt. Die Namenskonventionen waren wirklich gut — und nirgends aufgeschrieben. Onboarding hieß: den Fluss von den Quellsystemen bis ins Dashboard aus einzelnen Repository-READMEs rekonstruieren.

Das Erste, was ich geliefert habe, war deshalb kein Feature. Ich habe jedes Repository des Estates in einen Read-only-Spiegel gezogen und das Orientierungsdokument geschrieben, das es nicht gab: die Layer-Karte, die Konventionen, den Deploy-Contract, den End-to-End-Datenfluss und eine ehrliche Inventur, welche Repositories tragend sind und welche nur Stubs oder Kopien.

Bei der Zuschreibung will ich präzise sein: Diese Plattform habe ich nicht gebaut. Meine Aufgabe war, sie in einem Kopf halten zu können — und dann zu entscheiden, was damit passiert.

Ich habe das Estate durch drei getrennte Reviews laufen lassen und alles nach Severity sortiert: eine Strategie-Lens auf Wetten und Klumpenrisiken, eine Architektur-Lens auf Failure Modes und Security, und eine Developer-Experience-Lens auf die Frage, wie es sich tatsächlich anfühlt, hier eine Änderung auszuliefern.

Der nützliche Teil war, dass die Findings Cluster gebildet haben.

• Ein Keystone, mitten im Austausch. Jeder geplante Workload lief auf einer einzigen selbst betriebenen Runtime, und die Organisation war auf halbem Weg zu einem zweiten Deployment. Ein Keystone, den man gerade halb ersetzt hat, ist das größte strategische Risiko auf dem Board.
• Keine schichtübergreifende Observability. Fehler wurden über Webhooks pro Repository sichtbar. Nichts erzwang, dass die Ingestion fertig ist, bevor die Transformation startet. Veraltete Dashboards fielen einer Analystin auf, nicht einem Alert.
• Uneinheitliche Security- und Betriebshygiene im Estate. Die Details bleiben intern; das Severity-Ranking hat die kritischsten Punkte an die Spitze der Remediation-Queue gesetzt.
• Überhaupt kein Orientierungsdokument auf Estate-Ebene — das billigste und wirksamste Artefakt, das dem Team fehlte, und genau das, was das Audit selbst produziert hat.

Ein Finding habe ich komplett aus der Roadmap gezogen und als Incident behandelt. Manche Dinge bekommen kein Quartal.

Das Modernisierungs-Assessment deckte die ganze Kette ab: Ingestion, Transformation, Orchestrierung, Serving. Jede Schicht kam schlecht weg, und die Versuchung bei so einer Scorecard ist ein Neubau.

Die Plattform brauchte keinen Neubau. Sie brauchte eine Reihenfolge.

Die Ingestion lief als Full Load, append-only, ohne Merge Key, und die meisten Transformationsmodelle deduplizieren beim Lesen nicht. Wiederholte Läufe haben also still doppelte Zeilen in nachgelagerte Kennzahlen getragen — falsche Zahlen auf echten Dashboards, heute, ganz ohne Orchestrator. Die Testabdeckung über die Modellschicht lag weit unter dem, was eine derart tragende Plattform braucht.

Die Sequenzierung war deshalb: zuerst Idempotenz und Observability schließen, weil beides keine neue Infrastruktur braucht. Dann das Orchestrierungs-Backbone. Dann die Ingestion modernisieren. Ein Orchestrator-Programm über mehrere Monate darf den Dedup-Fix nicht blockieren, der diese Woche aufhört, falsche Zahlen auszuliefern.

Das aufzuschreiben war wichtiger als die Zielarchitektur. Eine Roadmap, die mit der teuren Sache beginnt, erreicht die billige nie.

Das AI-Use-Case-Portfolio kam so an, wie diese Dinge immer ankommen: als Dokument. Jede Abteilung hatte Kandidaten eingereicht, jeder Kandidat war über ein Dutzend Dimensionen bewertet, und im Steering-Termin war das unbrauchbar, weil die Frage „was hat keinen Owner" hieß, das Ding von vorn bis hinten zu lesen.

Ich habe daraus eine interne Webanwendung gebaut, durchgehend zugriffsgeschützt — die zugrunde liegenden Daten sind sensibel.

• Ein Command Center mit den zwei Zahlen, auf die eine Führungskraft reagiert: wie viele Fälle auf niemandes Namen laufen und wie viele Quick Wins bereitstehen. Dazu ein Feed, was sich in den letzten sieben Tagen bewegt hat.
• Eine Delivery Map, eine sortierbare Tabelle und eine Impact/Effort-Matrix mit konfigurierbaren Achsen — alle lesen denselben Filterzustand aus der URL. Der Drilldown aus einer Kachel verengt die Ansicht, in der man gerade ist, statt die Filter zu verwerfen. Jede gefilterte Ansicht ist ein Link, den man weiterschicken kann.
• Eine Abteilungs-Scorecard: jedes Team auf einer Seite, mit Bedarf, Horizont-Split, Evidenzabdeckung, Quick Wins, Ownership-Lücken und offenen Follow-ups — und jede Zahl klickbar bis auf die Fälle dahinter.
• Ein Action Board, das alle offenen Follow-ups des Portfolios in einer Liste sammelt, damit niemand hunderte Detailseiten öffnet, um sie zu finden.
• Shortlists, Exporte und Präsentationsmodus. Fälle bildschirmübergreifend auswählen, Ansicht oder Auswahl als CSV in drei Detailtiefen exportieren, oder beides als Foliendeck bzw. einseitiges Briefing ausgeben, das direkt als PDF druckt.

Am meisten freut mich das Autorisierungsmodell, weil es der Teil ist, der auch nach mir noch stimmt. Zugang und Rolle sind zwei verschiedene Fragen, und beide werden in reviewtem Code beantwortet, nicht in der App: Eine Mitgliedschaftsänderung geht als kleiner Merge Request raus, den die App selbst für einen rendert. Die App schreibt nichts — der Merge ist die Autorität. Berechtigungen werden pro Request aufgelöst; eine Änderung greift sofort und nicht erst, wenn irgendeine Session abläuft.

Die zweite Lücke war visuell. Jede interne Anwendung hatte ihre eigene Palette, ihre eigenen Buttons und ihre eigene Vorstellung davon, wie ein Chart auszusehen hat.

Ich habe ein Framework-neutrales Design System als Monorepo gebaut: geschichtete Design Tokens, zugängliche Controls als native Custom Elements und dünne, typisierte Wrapper, damit dieselben Komponenten in React, Svelte und im E-Learning-Framework der Schulungen angenehm nutzbar sind. Ein Storybook-Katalog, eine feste semantische Version über alle publizierten Pakete, ein Changeset für jede konsumentensichtbare Änderung.

Die Accessibility-Arbeit ist dabei die Substanz, nicht die Zierleiste. Getestete Farbpaarungen, Kontrastschwellen und Chart-Encoding-Metadaten liegen als Daten neben den Tokens, sodass ein Consumer dagegen prüfen kann. Jede Serie in einem Chart trägt eine Form zusätzlich zur Farbe, und die Legende wiederholt die Form neben dem Namen — damit die Charts Graustufendruck, Farbfehlsichtigkeit und Forced-Contrast-Modus überstehen. Die eine Kontrastpaarung, die ich innerhalb eines Design-System-Releases nicht lösen konnte, habe ich als offenen Punkt mit den gemessenen Verhältnissen dokumentiert, statt sie still auszuliefern.

Drei kleinere Arbeiten, alle gegen dasselbe Problem: institutionelles Wissen, das existiert, aber nicht abfragbar ist.

Ich habe interne Wikis in auditierbare, maschinenlesbare Form archiviert, mit Zugriffslisten pro Dokument daneben, und daraus ein Konfliktregister gebaut: widersprüchliche Aussagen aus verschiedenen Quellen nebeneinander, mit Evidenz, verantwortlichem Owner, Verifikationstest und Akzeptanzkriterien. So wird aus einem Widerspruch ein Ticket statt einer Diskussion.

Und ich habe einen Knowledge Graph über Meeting-Transkripte als Navigationshilfe gebaut, mit Communities, schichtübergreifenden Hub-Knoten und den Fragen, die genau dieser Graph beantworten kann. Ausgeliefert mit einem Coverage-Warnhinweis ganz oben, weil die Extraktion lückenhaft war — und eine Navigationshilfe, die Vollständigkeit suggeriert, ist schlechter als gar keine.

Infrastruktur und Anwendung liegen in getrennten Repositories mit eigenen Pipelines. Änderungen gehen als reviewte Pull Requests raus, meine eigenen eingeschlossen. Findings werden mit Severity, Dateipfad und Fixvorschlag aufgeschrieben, damit jemand anderes handeln kann, ohne dass ich im Raum bin.

Genau das ist der Punkt eines Interim-Mandats. Alles, was hier entstanden ist — Estate-Karte, Audit, Roadmap, Portfolio-App, Design System — ist ein Artefakt, das jemand anderes aufnehmen und weiterbetreiben kann.