Wie Fanatics den Wert seiner Datenplattform bezifferte und den Vorstand dafür gewann

Fanatics, der Gigant für lizenzierte Sportartikel, der inzwischen auch im Geschäft mit Sammelkarten und Sportwetten aktiv ist, hatte keine Schwierigkeiten, Datenprojekte im Grundsatz finanziert zu bekommen. Das schwierigere Problem kennt jeder CDO, der schon einmal in einem Budget-Review gesessen hat: Dem Vorstand war klar, dass Daten wichtig sind, aber ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → bewertete die Datenplattform genauso wie ein Server-Rack, also als Kosten, die man minimiert, und nicht als Fähigkeit, in die man investiert. Bis 2025, als das Unternehmen in drei eigenständigen Geschäftsbereichen unterwegs war (E-Commerce, Fanatics Collectibles und Fanatics Betting and Gaming), war die Wildwucherung von Data Pipelines, Transformationsschichten und inkonsistentem Reporting zu einem echten operativen Risiko geworden. Die Frage war nicht, ob modernisiert wird, sondern wie man den Wert einer Modernisierung so beziffert, dass ein CFO unterschreibt.

Was sie getan haben

Der erste Schritt des Datenteams war, die Plattform nicht mehr auf technischer Ebene zu verteidigen. Architekturdiagramme gewinnen keine Budgetschlachten. Stattdessen ordneten sie jedes Datenprodukt einem umsatzbringenden oder kostensenkenden Geschäftsprozess zu und stellten für jedes eine einfache Frage: Was bricht, was wird langsamer, was wird teurer, wenn dieses Datenprodukt nicht verfügbar oder falsch ist?

Diese Diagnose ergab eine priorisierte Liste geschäftskritischer Datenflüsse und veränderte die Diskussion sofort. Die Plattform war keine IT-Ausgabe. Sie war das, was Personalisierungsmodelle während der Verkaufsspitzen am Laufen hielt, was Inventarsignale über alle Lagerpartner hinweg korrekt hielt und was die Quotenberechnung im Gaming-Bereich mit den Reporting-Vorgaben der einzelnen Bundesstaaten konform hielt.

Auf der Transformationsseite setzte Fanatics dbt ein (entwickelt von dbt Labs, einem kommerziellen Anbieter mit offensichtlichem Interesse an dieser Darstellung), um die Transformationslogik zu zentralisieren und zu dokumentieren. Nach den eigenen Veröffentlichungen von dbt Labs vermischen viele Organisationen Entscheidungen über die Compute-Plattform mit Entscheidungen über die Transformationslogik, was zu Doppelarbeit und intransparenter Kostenzuordnung führt. Fanatics nutzte diese architektonische Trennung für eine saubere Kostenrechnung: Databricks übernahm das Compute, dbt definierte, was die Daten bedeuten und was wann neu gebaut wird. Diese Trennung machte es erstmals möglich zu messen, welche Modelle teuer im Betrieb waren und welche nachgelagerten Nutzer sie tatsächlich verwendeten.

Der zweite strukturelle Schritt war die Einführung des inkrementellen Build-Ansatzes von dbt, der nur die Modelle neu aufbaut, die von Änderungen weiter oben betroffen sind, statt bei jedem Lauf komplette Datensätze neu zu verarbeiten. Nach Angaben von dbt Labs (ein Anbieter, die Zahlen sind also als Richtwert und nicht als unabhängig geprüft zu behandeln) senkte Fanatics damit die Compute-Kosten im Warehouse deutlich. Das Unternehmen selbst hat keine konkrete prozentuale Reduktion veröffentlicht, jede genaue Zahl wäre also Spekulation. Belegbar ist, dass die Senkung der Compute-Kosten eine Position im ROIROIReturn on Investment: the ratio of net profit to the cost of an investment. A 300% ROI means each dollar invested returns $3.Vollständige Definition ansehen →-Case wurde und nicht ein vager Engineering-Vorteil blieb.

Der dritte Schritt war politisch der wichtigste: Datenqualitätsprobleme in Umsatzgrößen zu übersetzen. Das Team berechnete die Kosten eines schlechten Recommendation-Modells während eines großen Drop-Events (wenn ein Trikot oder eine Sammelkarte in limitierter Auflage erscheint und hohen Traffic erzeugt), ausgedrückt in abgebrochenen Warenkörben und entgangener Conversion. Ebenso berechneten sie die Kosten eines verzögerten Inventar-Syncs, ausgedrückt in Überverkäufen und dem dadurch entstandenen Aufwand im Kundenservice. Das waren keine theoretischen Zahlen. Sie kamen aus Incident-Post-mortems, die das Team seit zwei Jahren durchführte, aber nie zu einem Business Case zusammengefasst hatte.

Die Ergebnisse

Fanatics hat keine einzige konsolidierte ROI-Zahl für seine Datenplattform veröffentlicht, und jeder Artikel, der etwas anderes behauptet, erfindet sie. Dokumentiert ist Folgendes: Die Compute-Reduktion durch inkrementelle Model Builds war groß genug, um als geschäftliche Rechtfertigung für den Architekturansatz genannt zu werden (laut den veröffentlichten Case-Study-Materialien von dbt Labs, die erneut einen Anbieter-Bias haben). Das Datenteam kam von vierteljährlichen Budgetverhandlungen zu einer festen Jahreszuweisung, was selbst ein Governance-Ergebnis ist. Wenn sich das Budgetgespräch von „begründen Sie das noch einmal" zu „hier ist Ihre Baseline plus Wachstum" verschiebt, ist die interne Begründung geliefert.

Der klarste Erfolg war der Gaming-Bereich. Das regulatorische Reporting im Sportwettengeschäft verlangt korrekte, prüfbare Data LineageData LineageData lineage maps how data moves and transforms across systems, from origin to consumption, showing where it came from, what changed it, and where it goes.Vollständige Definition ansehen →. Die Investition in die Dokumentationsschicht von dbt, konkret die automatische Erzeugung von Lineage-Graphen und Beschreibungen auf Modellebene, verkürzte die Zeit für die Beantwortung von Prüfungen der Aufsichtsbehörden. Die eingesparte Zeit wurde gegen die Stundenkosten der beteiligten Juristen und Data Engineers gerechnet. Diese Zahl war, dem Vorstand präsentiert, konkret und belastbar.

Was übertragbar ist

Der Ansatz von Fanatics lässt sich auf vier wiederholbare Entscheidungen verdichten, auch wenn jede an den eigenen Kontext angepasst werden muss.

Erstens: Bauen Sie Ihren ROI-Case rückwärts aus Incidents auf, nicht vorwärts aus Fähigkeiten. Die glaubwürdigsten Zahlen in der internen Präsentation von Fanatics kamen aus dokumentierten Ausfällen, nicht aus prognostizierten Gewinnen. Jeder CDO hat Incident-Logs. Die meisten haben sie nicht aggregiert.

Zweitens: Trennen Sie in Ihrer Architektur Compute-Kosten von Transformationslogik, nicht als Selbstzweck, sondern weil das Kostenzuordnung ermöglicht. Sie kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen keinen ROI für etwas belegen, das Sie nicht messen können. Das Muster dbt plus Cloud-Compute (wobei dbt Labs erneut ein Anbieter mit kommerziellem Interesse an dieser Botschaft ist) schafft die buchhalterische Klarheit, die Gespräche auf Vorstandsebene erst möglich macht.

Drittens: Bewerten Sie Governance-Ergebnisse in Personalzeit, nicht in abstraktem Risiko. Regulatorische Bereitschaft, Reaktionszeit bei Audits und Datenqualitäts-SLAs haben alle Arbeitskosten. Diese Kosten stehen schon in der Gewinn- und Verlustrechnung. Die Frage ist, ob sie der Dateninfrastruktur zugeordnet oder im Overhead der Abteilungen versteckt sind.

Viertens: Erkennen Sie, wo sich die Situation von Fanatics von Ihrer unterscheidet. Sie hatten einen Zwang zum Handeln: drei Geschäftsbereiche mit wirklich unterschiedlichen Datenmodellen, ein laufendes Gaming-Produkt mit regulatorischem Risiko und genug Engineering-Kapazität, um eine moderne Transformationsschicht aufzubauen und zu betreiben. Ein mittelgroßer Finanzdienstleister oder ein Klinikverbund hat vielleicht das regulatorische Risiko, aber nicht die Engineering-Tiefe. Dann verändert sich die Make-or-Buy-Rechnung für die Transformationsschicht, und damit auch der Zeitrahmen, in dem glaubwürdige ROI-Zahlen entstehen.

Der Vorstand muss dbt oder Databricks nicht verstehen. Er muss eine Tabelle sehen, die zeigt, was Datenausfälle kosten, was die Plattforminvestition kostet und wie die Differenz aussieht. Fanatics ist dort angekommen, indem das Unternehmen seine Incident-Historie als Finanzdaten behandelte. Das ist die Methode, die sich zum Kopieren lohnt.