Use-Case-first-Datenarchitektur

Kurzantwort

Wer KI-Vorhaben mit einem mehrjährigen Datenplattform-Programm beginnt, bezahlt vorab für Anforderungen, die noch niemand kennt. Der belastbarere Weg dreht die Reihenfolge um. Ein messbares Geschäftsergebnis bestimmt das Datenminimalset, ein Datenkontrakt sichert Qualität und Rechte, geliefert wird nur dieser Pfad. Wiederholt sich ein Muster beim zweiten Use Case, wird es zum Standard. So entsteht Architektur aus Beweisen. Die Plattform kommt am Ende trotzdem — aber gedeckt durch reale Anforderungen statt durch Annahmen.

Die Kernaussagen

• Der Plattform-zuerst-Pfad kostet vor dem ersten Nutzen; Use-Case-first kostet erst, wenn ein Outcome benannt ist.
• Datenqualität ist relativ zum Zweck. Gut genug für den Use Case ist die einzige belastbare Schwelle.
• Wiederverwendbare Bausteine entstehen nach dem zweiten ähnlichen Use Case, nicht vor dem ersten.
• Zwei bis drei Treiber-Use-Cases mit Baseline schlagen jedes Vorab-Inventar aller Wunschdatenquellen.
• Plattformbudget wird an Use-Case-Meilensteine gekoppelt, nicht pauschal für zwei Jahre freigegeben.
• Qualitätsschwellen ohne Stopprecht sind Dekoration. Wer den Use Case nicht anhalten darf, steuert nichts.

Warum die Frage jetzt zählt

Die Ausgangslage ist unbequem. Nach der MIT-Studie „The GenAI Divide“ (2025) erreichen nur fünf Prozent der unternehmensspezifischen KI-Werkzeuge den Produktivbetrieb; 95 Prozent der Organisationen sehen keinen messbaren Ergebnisbeitrag. Gleichzeitig verdoppelte sich die KI-Nutzung im deutschen Mittelstand: 36 Prozent der Unternehmen setzen KI ein, nach 20 Prozent im Vorjahr (Bitkom 2025). Der Druck zu liefern steigt also genau in dem Moment, in dem viele Häuser über ein großes Datenfundament nachdenken. Gartner (2024) liefert die Warnung dazu: 80 Prozent der Data-Governance-Initiativen werden bis 2027 scheitern, weil der Bezug zu priorisierten Geschäftsergebnissen fehlt. Die Reihenfolge der Investition entscheidet damit über mehr als Eleganz. Sie entscheidet, ob das Datenbudget Lernwert erzeugt oder Warteschlangen.

Zwei Pfade, zwei Kostenkurven

Beide Pfade führen nominell zum selben Ziel: verlässliche Daten für KI-Anwendungen. Ihre Kostenkurven unterscheiden sich fundamental. Der Plattform-zuerst-Pfad investiert in Infrastruktur, Lizenzen, Integrationen und ein zentrales Datenmodell, bevor der erste Anwendungsfall läuft. Die Ausgaben sind hoch und früh. Der Nutzen ist spät und ungewiss. Der Use-Case-first-Pfad investiert klein und wiederholt. Jede Ausgabe hängt an einem benannten Outcome mit Baseline, also einem dokumentierten Ist-Wert vor dem Start.

Kostendimension	Plattform zuerst	Use-Case-first
Anfangsinvestition	Hoch: Infrastruktur, Lizenzen, Integration vor dem ersten Nutzen	Begrenzt: nur Datenprodukte für den ersten Nutzenpfad
Zeit bis zum ersten messbaren Ergebnis	Quartale bis Jahre	Wochen bis wenige Monate
Risiko der Fehlinvestition	Hoch: Anforderungen beim Bau unbekannt	Begrenzt: jeder Euro hängt an einem Outcome
Governance-Aufwand	Vorab für alle Domänen gleichzeitig	Pro Use Case, wächst mit der Evidenz
Lernwert je ausgegebenem Euro	Gering bis zum ersten Anwendungsfall	Hoch: jede Lieferung erzeugt Messdaten
Folgekosten bei Kurswechsel	Hoch, weil versenkte Kosten drohen	Begrenzt, weil Bausteine klein und austauschbar sind

Die Daten stützen die Skepsis gegenüber dem Vorratsbau. Schon vor der generativen KI stellte die Seagate/IDC-Studie „Rethink Data“ (2020) fest, dass 68 Prozent der verfügbaren Unternehmensdaten ungenutzt bleiben. Wer zuerst alles sammelt und harmonisiert, veredelt also überwiegend Bestände ohne Abnehmer. Die MIT-Zahlen von 2025 zeigen die Kehrseite auf der Anwendungsebene: Nicht Modellqualität trennt erfolgreiche von gescheiterten Vorhaben, sondern die Passung zum konkreten Arbeitsablauf. Genau diese Passung liefert nur ein Use Case, nie ein Datenmodell.

Ein Data Lake ohne benannten ersten Nutzer ist keine Infrastruktur. Er ist ein Kostenversprechen an eine Zukunft, die niemand bestellt hat.

Ein wichtiger Einwand verdient eine ehrliche Antwort. Über fünf Jahre können sich die Gesamtkosten beider Pfade angleichen, weil Use-Case-first später konsolidieren muss. Der Unterschied liegt im Risiko- und Zeitprofil. Beim Plattform-Pfad ist das Kapital gebunden, bevor die erste Hypothese geprüft ist. Beim Use-Case-Pfad kann Führung nach jedem Meilenstein umsteuern, stoppen oder verstärken. Das ist keine technische Feinheit. Es ist der Unterschied zwischen einer Wette und einer Investitionsserie mit Abbruchoption.

Vier Datenreife-Mythen, die Budgets binden

Der Plattform-zuerst-Reflex speist sich aus wiederkehrenden Überzeugungen. Vier davon begegnen der Redaktion in fast jedem Entscheidergespräch. Alle vier klingen vernünftig. Alle vier sind in dieser Pauschalform falsch.

Mythos eins: „Erst müssen unsere Daten sauber sein.“ Sauber ist keine Eigenschaft von Daten, sondern eine Beziehung zwischen Daten und Zweck. Eine Materialstammdatei kann für die Disposition unbrauchbar und für einen Dokumentenassistenten völlig ausreichend sein. Wer Qualität ohne Zweck misst, erzeugt ein Programm ohne Endpunkt und ohne Abnahmekriterium.

Mythos zwei: „Ohne zentralen Data Lake keine KI.“ Die meisten produktiven KI-Anwendungen im Mittelstand greifen auf wenige Quellsysteme zu: ein ERP, ein Dokumentenablage-System, ein Ticketsystem. Dafür braucht es gezielte Anbindungen mit geklärten Rechten, keinen Vorab-Umzug aller Bestände. Der Fachbegriff Datenprodukt beschreibt genau das: ein bewirtschafteter, zweckgebundener Datenausschnitt mit Verantwortlichem, Schnittstelle und Qualitätszusage (Dehghani 2019).

Mythos drei: „Datenreife lässt sich als eine Zahl fürs ganze Haus messen.“ Reifegradmodelle liefern nützliche Landkarten, aber keine Investitionsentscheidung. Ein Unternehmen kann in der Buchhaltung reif und im Service unreif sein. Entscheidbar ist nur die Frage pro Nutzenpfad: Reichen diese Felder, in dieser Frische, mit diesen Rechten, für dieses Ergebnis?

Mythos vier: „Die Plattform amortisiert sich über die vielen späteren Use Cases.“ Das Argument setzt voraus, dass die späteren Use Cases die heutigen Annahmen bestätigen. Die Gartner-Prognose von 2024 zu scheiternden Governance-Initiativen beschreibt exakt diesen Fehlschluss: Programme ohne verbundenes Geschäftsergebnis verlieren Rückhalt, bevor der versprochene Skaleneffekt eintritt. Amortisation braucht Nachfrage. Nachfrage beweist man mit gelieferten Use Cases, nicht mit Architekturbildern.

Das Vorgehensmodell in sechs Schritten

Use-Case-first ist kein Verzicht auf Architektur. Es ist eine Reihenfolge, in der Architektur entsteht. Das Modell hat sechs Schritte, jeder mit einem prüfbaren Artefakt.

Schritt eins: Outcome und Baseline festlegen. Der Use Case bekommt ein Geschäftsergebnis mit Zahl und Datum, etwa eine kürzere Angebotsdurchlaufzeit. Die Baseline dokumentiert den heutigen Ist-Wert. Ohne Baseline ist jeder spätere Erfolgsclaim rhetorisch. Owner ist der Fachbereich, nicht die IT.

Schritt zwei: Datenminimalset und Rechte klären. Welche Felder aus welchen Systemen trägt der Outcome wirklich? Wer darf sie sehen, und gilt das auch für das KI-System? Die Rechteklärung vor dem Prototyp ist billiger als jede Nachrüstung. Sie ist zudem die datenschutzrechtlich saubere Reihenfolge, denn die DSGVO verlangt Zweckbindung und Datenminimierung als Grundsatz (Artikel 5).

Schritt drei: Datenkontrakt schreiben. Der Kontrakt hält Schema, Aktualisierungsfrequenz, Qualitätsschwellen und Verantwortliche fest, eine bis zwei Seiten, versioniert, für Fachbereich und IT verbindlich. Entscheidend ist das Stopprecht: Unterschreitet die Quelle die vereinbarte Schwelle, wird der Use Case angehalten, nicht leise weiterbetrieben.

Schritt vier: Liefern und messen. Das Datenprodukt geht in Betrieb, der Use Case läuft gegen die Baseline. Gemessen wird das Geschäftsergebnis, nicht die Systemaktivität. Nutzungsstatistiken schmeicheln; Durchlaufzeiten und Fehlerquoten entscheiden.

Schritt fünf: Muster extrahieren. Nach der Lieferung dokumentiert das Team, was wiederverwendbar ist: die Anbindung ans Quellsystem, die Berechtigungslogik, die Aufbereitungsschritte, das Evaluationsvorgehen. Dieses Dokument ist der Rohstoff der späteren Plattform.

Schritt sechs: Nach dem zweiten Fall standardisieren. Taucht ein Muster im zweiten Use Case wieder auf, wird es zum Standard erklärt und aktiv gepflegt. Vorher nicht. Die Regel klingt banal und ist das wirksamste Mittel gegen vorauseilende Generalisierung.

Standardisiert wird, was sich zweimal bewiesen hat. Alles andere ist Architektur auf Verdacht, und Verdacht ist die teuerste Bauweise.

Für die Auswahl der ersten zwei bis drei Treiber-Use-Cases gelten drei Kriterien. Strategische Relevanz: Das Ergebnis interessiert die Geschäftsführung auch in zwölf Monaten noch. Datengreifbarkeit: Die Quellen existieren, die Rechte sind klärbar. Messbarkeit: Baseline und Zielwert lassen sich in einer Kennzahl ausdrücken. Leuchtturmprojekte ohne Baseline erfüllen das dritte Kriterium nie und gehören aussortiert, so attraktiv die Demo wirkt.

Vom Muster zur Plattform, ohne Wildwuchs

Der häufigste Einwand gegen Use-Case-first lautet: Es entsteht Wildwuchs, jedes Team baut eigene Pipelines. Der Einwand trifft eine schlechte Umsetzung, nicht das Modell. Wildwuchs entsteht, wenn Schritt fünf und sechs fehlen, wenn also geliefert wird, ohne Muster zu extrahieren und zu standardisieren. Drei Mechanismen halten die Disziplin.

Erstens die Musterbibliothek. Ein leichtgewichtiges, zentral gepflegtes Verzeichnis der standardisierten Bausteine: Konnektoren, Berechtigungsmuster, Qualitätsprüfungen, Evaluationsroutinen. Jeder neue Use Case prüft zuerst die Bibliothek. Abweichungen sind erlaubt, aber begründungspflichtig.

Zweitens die Budgetkopplung. Plattformbudget wird in Tranchen freigegeben, jede Tranche an einen Use-Case-Meilenstein gebunden. Das Portfoliogremium sieht so bei jeder Freigabe, ob die Plattform reale Nachfrage bedient. Ein pauschal bewilligtes Zweijahresbudget entzieht sich genau dieser Kontrolle.

Drittens die Kontraktvererbung. Wird ein Datenprodukt wiederverwendet, wandern Kontrakt und Rechte mit. Kopieren ohne Kontrakt erzeugt zwei Wahrheiten im Haus, und die teurere von beiden gewinnt immer. Aktualität hat dabei laufende Kosten: Quellenpflege, Indexpflege, Evaluation. Diese Run-Kosten gehören von Anfang an in die Wirtschaftlichkeitsrechnung, sonst wird Aktualität zum unfinanzierten Versprechen.

Wo liegt die Grenze des Modells? Es gibt Vorhaben mit echtem Vorab-Infrastrukturbedarf, etwa wenn regulatorische Berichtspflichten ein konsolidiertes Datenfundament erzwingen oder wenn Sensordaten in großem Volumen anfallen, bevor der erste Use Case definiert ist. In diesen Fällen ist die Plattformentscheidung eine eigene Investitionsentscheidung mit eigenem Business Case. Sie sollte dann auch so behandelt werden (offen, mit Zahlen) und nicht als stillschweigende Voraussetzung in ein KI-Programm eingebaut werden.

Maßnahmen für die Geschäftsführung

Bis Tag 30:

• Zwei bis drei Treiber-Use-Cases im Führungskreis auswählen, je mit Outcome, Zielzahl und Datum. Owner: Geschäftsführung mit Fachbereichsleitung.
• Baseline je Use Case dokumentieren lassen: Ist-Wert, Messmethode, Stichtag. Owner: Fachbereichsleitung.
• Laufende Datenplattform-Initiativen inventarisieren: Budget, Stand, verbundene Use Cases. Owner: CIO.
• Rechte- und Datenschutzprüfung für den ersten Use Case beauftragen. Owner: CIO mit Datenschutzbeauftragtem.

Bis Tag 60:

• Ersten Datenkontrakt verabschieden, inklusive Qualitätsschwellen und Stopprecht. Owner: CIO.
• Datenminimalset für Use Case zwei und drei festlegen. Owner: Fachbereichsleitung mit IT.
• Budgetlogik umstellen: Plattformausgaben nur noch in Tranchen gegen Use-Case-Meilensteine. Owner: CFO.
• Musterbibliothek als Ablage anlegen, auch wenn sie zunächst fast leer ist. Owner: IT-Leitung.

Bis Tag 90:

• Erste Lieferung gegen die Baseline messen und im Führungskreis berichten. Owner: Fachbereichsleitung.
• Extrahierte Muster aus Use Case eins reviewen und Standardisierungskandidaten benennen. Owner: IT-Leitung.
• Entscheidung dokumentieren: fortsetzen, umsteuern oder stoppen, je Use Case, mit Begründung. Owner: Geschäftsführung.
• Review-Termin für die Plattformfrage nach dem dritten Use Case terminieren. Owner: CIO.

Was Führung jetzt entscheiden muss

Häufige Fragen (FAQ)

Was kostet der Use-Case-first-Einstieg im Vergleich zum großen Datenplattform-Programm?

Der Einstieg kostet einen Bruchteil, weil nur die Datenprodukte für den ersten Nutzenpfad gebaut werden. Ein Plattform-Programm bindet Infrastruktur, Lizenzen und Integrationsaufwand über Quartale, bevor der erste Anwendungsfall läuft. Beim Use-Case-first-Pfad hängt jede Ausgabe an einem benannten Outcome mit Baseline. Das begrenzt das Verlustrisiko auf den einzelnen Use Case. Die Gesamtkosten über mehrere Jahre können sich angleichen. Der Unterschied liegt im Zeitpunkt der Ausgabe und im Lernwert: Use-Case-first bezahlt gegen Evidenz, Plattform zuerst bezahlt gegen eine Annahme.

Sind unsere Daten überhaupt gut genug für KI, oder müssen wir erst aufräumen?

Diese Frage lässt sich nur pro Use Case beantworten, nicht für das ganze Unternehmen. Ein Angebotsassistent braucht saubere Artikel- und Preisdaten, aber keine perfekte CRM-Historie. Die pauschale Antwort „erst aufräumen“ führt in ein Programm ohne Endpunkt: Laut Seagate/IDC (2020) bleiben rund 68 Prozent der verfügbaren Unternehmensdaten ohnehin ungenutzt. Wer alles putzt, putzt überwiegend Daten ohne Abnehmer. Definieren Sie das Minimalset für den ersten Use Case, prüfen Sie dessen Qualität und starten Sie dort.

Was riskieren wir rechtlich, wenn wir Daten erst im Use Case erschließen statt zentral?

Rechtlich ist der Use-Case-Zuschnitt meist die sicherere Position, kein Zusatzrisiko. Die DSGVO verlangt in Artikel 5 Zweckbindung und Datenminimierung: verarbeitet wird, was für einen festgelegten Zweck erforderlich ist. Ein zentraler Speicher mit personenbezogenen Daten ohne definierte Zwecke ist schwerer zu rechtfertigen als ein begrenztes Datenprodukt. Klären müssen Sie pro Use Case: Rechtsgrundlage, Zugriffsrechte, Löschkonzept und bei Beschäftigtendaten die Mitbestimmung. Diese Prüfungen sind im kleinen Zuschnitt schneller und belastbarer als für einen unbegrenzten Datenbestand.

Womit fangen wir in den ersten 90 Tagen konkret an?

Mit der Auswahl von zwei bis drei Treiber-Use-Cases im Führungskreis, jeweils mit Outcome, Baseline und benanntem Owner. Danach folgt pro Use Case das Datenminimalset: Welche Felder, aus welchen Systemen, mit welchen Rechten. Der erste Datenkontrakt entsteht in Woche vier bis acht, die erste messbare Lieferung bis Tag 90. Parallel prüft die IT nur die Infrastruktur, die dieser Pfad wirklich braucht. Alles Weitere (Standards, Kataloge, Plattformausbau) wartet auf Evidenz aus dem zweiten Use Case.

Brauchen wir am Ende nicht doch eine zentrale Datenplattform?

Vermutlich ja, aber als Ergebnis, nicht als Voraussetzung. Nach drei bis fünf gelieferten Use Cases zeigen sich wiederkehrende Muster: Anbindungen, Berechtigungslogik, Qualitätsprüfungen, Evaluationsroutinen. Diese Muster zu standardisieren ist der eigentliche Plattformbau, und er ist dann durch reale Anforderungen gedeckt. Der Unterschied zum Vorab-Bau liegt im Risiko: Gartner (2024) erwartet, dass 80 Prozent der Data-Governance-Initiativen bis 2027 scheitern, weil der Geschäftsbezug fehlt. Eine Plattform aus belegten Mustern hat diesen Bezug per Konstruktion.

Evidenz und Grenzen

Belegt sind die zitierten Datenpunkte: die Produktivquote und ROI-Verteilung aus der MIT-Studie (2025), die Gartner-Prognose zu Governance-Initiativen (2024), der Anteil ungenutzter Unternehmensdaten aus Seagate/IDC (2020) und die deutschen Adoptionszahlen von Bitkom (2025). Redaktionelle Einschätzung sind die Kostenkurven-Gegenüberstellung, das Sechs-Schritte-Modell und die Zwei-Fälle-Regel für Standardisierung; sie verdichten dokumentierte Praxis aus produktorientierten Datenansätzen, sind aber keine kontrollierte Studie. Der Beitrag leistet keine Wirtschaftlichkeitsrechnung für ein konkretes Haus, keine Vendor- oder Werkzeugauswahl und keine Rechtsberatung. Die Kostenangaben sind bewusst qualitativ gehalten, weil belastbare branchenübergreifende Euro-Vergleiche der beiden Pfade nicht vorliegen.

Quellen und Methodik

1. MIT NANDA: „The GenAI Divide: State of AI in Business 2025“, Juli 2025, 95 Prozent der Organisationen ohne messbaren P&L-Effekt, 5 Prozent Produktivquote bei unternehmensspezifischen KI-Werkzeugen.
2. Gartner: „Gartner Predicts 80% of D&A Governance Initiatives Will Fail by 2027“, Pressemitteilung, Februar 2024, gartner.com.
3. Seagate/IDC: „Rethink Data“, 2020, 68 Prozent der verfügbaren Unternehmensdaten bleiben ungenutzt, seagate.com.
4. Bitkom Research: „Künstliche Intelligenz 2025“, repräsentative Befragung von 604 Unternehmen, 2025, 36 Prozent KI-Nutzung, Verdopplung gegenüber 2024, bitkom.org.
5. Dehghani, Z.: „How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh“, martinfowler.com, 2019, Datenprodukte und Domänenverantwortung.
6. Verordnung (EU) 2016/679 (DSGVO), Artikel 5, Zweckbindung und Datenminimierung als Verarbeitungsgrundsätze.

Methodik: Recherche und Erstfassung entstanden mit KI-Unterstützung; alle Zahlenangaben wurden gegen die genannten Primär- und Sekundärquellen geprüft. Aussagen ohne belastbare Quelle sind qualitativ formuliert oder als redaktionelle Einschätzung gekennzeichnet. Die menschliche Faktenprüfung und redaktionelle Freigabe erfolgen vor Veröffentlichung.

Änderungsprotokoll

Datum	Änderung
2026-07-23	Vollständige Neufassung nach Qualitäts-Spec: Web-verifizierte Quellen, Kostenvergleich der Pfade, Datenreife-Mythen, Sechs-Schritte-Vorgehensmodell, FAQ
2026-07-23	Erstfassung Launch-Korpus (Status: draft)

Das Entscheider-Briefing

Ein Briefing pro Woche: Entscheidungsfragen, eingeordnete Zahlen und Fristen. Ihre Adresse geben wir nicht weiter.

Website

E-Mail-Adresse

Briefing abonnieren

Ich möchte das Briefing per E-Mail erhalten und kann die Einwilligung jederzeit widerrufen. Die Datenschutzerklärung habe ich gelesen.

Sie erhalten zuerst eine E-Mail mit einem Bestätigungslink. Erst nach dem Klick nehmen wir Sie auf. Abmeldung mit einem Klick in jeder Ausgabe.