Datenstrategie-Framework aufbauen, das sich umsetzen lässt

Ein Datenstrategie-Framework ist die Abfolge von Schichten, die aus Rohdaten Entscheidungen macht: woher die Daten kommen, wer sie steuert, wo sie liegen, wie ihre Bedeutung einmal festgelegt wird und wie Menschen sie nutzen. Es funktioniert, wenn jede Schicht einen benannten Verantwortlichen und eine klare Schnittstelle zur Nachbarschicht hat. Es funktioniert nicht, wenn es eine Folie bleibt, die „Vision und Ziele“ beschreibt.

Dieser Beitrag behandelt die Struktur selbst. Wie Sie Geschäftsziele auf dieser Struktur in messbare KPIs übersetzen, zeigt unser Leitfaden zum Aufbau einer Analytics-Strategie. Wie Sie die Arbeit in Phasen planen, lesen Sie in So entwickeln Sie eine Roadmap für die Datenstrategie.

Die Schichten eines Datenstrategie-Frameworks

Ein Datenstrategie-Framework hat fünf Schichten. Jede baut auf der darunterliegenden auf, und jede braucht einen Verantwortlichen, der geradesteht, wenn sie ausfällt.

Am häufigsten scheitert ein Framework daran, dass die semantische Schicht fehlt. Ohne sie können zwei Reports auf denselben Quelldaten „Umsatz“ unterschiedlich definieren. Das fällt erst in einem Meeting auf, in dem zwei Zahlen nicht übereinstimmen.

Quellen: Daten einbinden, ohne Logik zu duplizieren

Jedes Framework beginnt mit einer Bestandsaufnahme der Quellsysteme: CRM, ERP, Finanzexporte, Ereignislogs der Produkte. Entscheidend ist nicht, welche Systeme es gibt, sondern welches Team jedes besitzt und wen Sie anrufen, wenn ein Feld seine Form ändert.

In Fabric läuft die Ingestion über Pipelines oder Dataflows Gen2, beide geplant, beide landen die Daten in OneLake. Ein Shortcut kann auf Daten verweisen, die bereits an anderer Stelle liegen, etwa in einem bestehenden Azure-Data-Lake-Storage-Konto, ohne sie zu kopieren. So bleibt ein Datensatz an einem Ort, statt für jeden Report, der ihn braucht, ein Duplikat anzulegen.

Plattform: eine Speicherschicht unter allem

OneLake ist die einheitliche Speicherschicht von Fabric. Lakehouses und Warehouses legen ihre Tabellen dort als Delta-Tabellen ab. Spark, SQL und Power BI lesen dieselben Tabellen, statt dass jedes Tool eine eigene Kopie hält.

Das macht den Rest des Frameworks erst möglich. Eine Vertraulichkeitsbezeichnung auf einem Element erben die Elemente, die darauf aufbauen. Ein Report auf einem gekennzeichneten Semantic Model trägt die Bezeichnung also ebenfalls. Ein Semantic Model im Direct-Lake-Modus liest diese Delta-Tabellen direkt, ohne Importschritt und ohne eine eigene DirectQuery-Verbindung, die Sie verwalten müssten.

Governance: Regeln, die mit den Daten wandern

Governance ist kein Richtliniendokument. Sie ist ein Satz durchgesetzter Regeln: wer welche Zeilen sehen darf, welche Felder sensibel sind und welche Namen was bedeuten.

Row-Level Security ist der Punkt, an dem Governance für Report-Leser sichtbar wird. Eine Rolle im Semantic Model filtert eine Tabelle anhand des angemeldeten Benutzers:

[Region] =
LOOKUPVALUE (
    'UserRegionMap'[Region],
    'UserRegionMap'[Email], USERPRINCIPALNAME ()
)

Ein Vertriebsleiter in der Region Berlin öffnet denselben Report wie ein Kollege in München und sieht nur die eigenen Zeilen. Für jeden muss kein eigener Report gebaut werden. Microsoft Purview weitet das über Power BI hinaus aus und wendet Vertraulichkeitsbezeichnungen und einen gemeinsamen Katalog auf jeden Fabric-Workload an. Unser Leitfaden zur Data-Governance-Strategie zeigt ausführlicher, wie Sie diese Regeln aufsetzen.

Semantische Schicht: ein Modell, überall wiederverwendet

In der semantischen Schicht bekommt ein Geschäftsbegriff seine eine Definition. „Aktiver Kunde“ sollte im Executive-Dashboard dasselbe bedeuten wie im Wochenreport des Vertriebsteams. Das stellt ein gemeinsames Power-BI-Semantic-Model sicher, das einmal gebaut und von mehreren Reports genutzt wird.

Active Customers (12 Months) =
VAR MaxDate = MAX ( 'Date'[Date] )
RETURN
CALCULATE (
    DISTINCTCOUNT ( Sales[CustomerID] ),
    DATESINPERIOD ( 'Date'[Date], MaxDate, -12, MONTH )
)

Jeder Report, der sich an dieses Modell anschließt, erbt dasselbe Measure, dieselbe Filterlogik und dieselbe Row-Level Security. Ändern Sie die Definition einmal, aktualisiert sich jeder Report, der sie nutzt.

Nutzung: Reports, die Menschen tatsächlich öffnen

In der Nutzungsschicht zahlen sich die anderen vier Schichten aus oder bleiben ungenutzt. Eine Power-BI-App bündelt die Reports, die ein Team braucht, an einem Ort, und die Row-Level Security des Semantic Models gilt weiter für jeden, der sie öffnet. E-Mail-Abonnements bringen die Zahlen nach Zeitplan zu den Menschen, sodass niemand daran denken muss, nachzusehen.

Ein Framework mit sauberer semantischer Schicht, aber ohne Workspace-Struktur scheitert auch hier, weil niemand den richtigen Report findet. Dieser Schicht einen Verantwortlichen zuzuweisen, meist dem Fachteam, dem die Entscheidung gehört, die der Report stützt, ist so wichtig wie bei der Governance.

FAQs

Wozu dient ein Datenstrategie-Framework?

Es gibt jedem Teil der Datenarbeit einer Organisation, von der Erfassung der Daten bis zum Reporting, einen definierten Verantwortlichen und eine definierte Schnittstelle zur Nachbarschicht. Ohne diese Struktur entsteht Datenarbeit ad hoc, ein Projekt nach dem anderen, ohne gemeinsame semantische Schicht darunter. Was eine Beratung über das Framework selbst hinaus umfasst, lesen Sie in unserem Leitfaden zur Beratung für Datenstrategie.

Wie oft sollte ich mein Datenstrategie-Framework überprüfen?

Überprüfen Sie es, wenn sich ein Quellsystem ändert, wenn ein neuer Report einem bestehenden widerspricht, oder mindestens einmal im Jahr. Ein Framework, das nie überarbeitet wird, driftet, wenn sich die Quellsysteme darunter verändern, und die semantische Schicht passt nicht mehr zur Realität.

Welche Rolle spielt Technologie in einem Datenstrategie-Framework?

Technologie setzt das Framework durch, statt es nur zu beschreiben. OneLake erzwingt eine Speicherschicht, Row-Level Security erzwingt die Governance-Regeln, und ein gemeinsames Semantic Model erzwingt eine Definition pro Geschäftsbegriff. Ohne diese Durchsetzung ist das Framework ein Dokument, das niemand prüft.

Quellen

• OneLake shortcuts - Microsoft Learn

• Direct Lake overview - Microsoft Learn

• Microsoft Purview and Fabric governance - Microsoft Learn