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 gut und nirgends aufgeschrieben. Onboarding hieß: den Fluss von den Quellsystemen bis ins Dashboard aus einzelnen Repository-READMEs rekonstruieren.

Meine erste Lieferung war deshalb ein Orientierungsdokument. Ich habe jedes Repository des Estates in einen Read-only-Spiegel gezogen und aufgeschrieben, was 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 ist, hier eine Änderung auszuliefern.

Die Findings bildeten Cluster.

• 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. Das habe ich als größtes strategisches Risiko eingestuft.
• 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, die zufällig hinsah.
• 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 Artefakt, das dem Team fehlte, und das, was das Audit selbst produziert hat.

Ein Finding habe ich aus der Roadmap gezogen und als Incident behandelt.

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.

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

Also: 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.

Diese Reihenfolge aufzuschreiben war wichtiger als die Zielarchitektur.

Das AI-Use-Case-Portfolio kam als Dokument an. 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 Dokument von vorn bis hinten zu lesen.

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

• 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 behält die Filter und verengt die Ansicht. 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, 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 auch nach mir noch stimmt. Zugang und Rolle sind zwei getrennte Fragen, und beide werden in reviewtem Code beantwortet. Eine Mitgliedschaftsänderung geht als kleiner Merge Request raus, den die App selbst für einen rendert; die App schreibt nichts, und der Merge ist die Autorität. Berechtigungen werden pro Request aufgelöst, eine Änderung greift sofort, auch für bereits offene Sessions.

Die zweite Lücke war visuell. Jede interne Anwendung hatte ihre eigene Palette und eigene Buttons, und eine 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 Barrierefreiheit ist der Teil, der sich zu beschreiben lohnt. 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; so überstehen die Charts Graustufendruck, Farbfehlsichtigkeit und Forced-Contrast-Modus. Die eine Kontrastpaarung, die ich innerhalb eines Design-System-Releases nicht lösen konnte, ist als offener Punkt mit den gemessenen Verhältnissen dokumentiert.

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. Jeder Widerspruch ist jetzt ein Ticket mit einem Namen dran.

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 gut beantworten kann. Ausgeliefert mit einem Coverage-Warnhinweis ganz oben, weil die Extraktion lückenhaft war und Leser wissen müssen, wo die Karte aufhört.

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.

Ein Interim-Mandat endet. Alles, was hier entstanden ist, Estate-Karte, Audit, Roadmap, Portfolio-App, Design System, ist ein Artefakt, das jemand anderes aufnehmen und weiterbetreiben kann.