Microsoft Fabric einführen: Der ehrliche Leitfaden für den Mittelstand

Du hast von Microsoft Fabric gehört — aus einer Demo, vom Microsoft-Partner, oder weil Power BI sich plötzlich anders anfühlt. Die Frage, die du dir wirklich stellst, ist nicht „Was kann Fabric?", sondern: Lohnt sich der Aufwand für uns, mit unserer Datenmenge, unserem Team, unserem Budget?

Dieser Artikel beantwortet das ohne Marketing-Folien. Annahme: Mittelstand — 30 bis 800 Mitarbeitende, ein paar Quellsysteme (ERP, CRM, vielleicht ein Webshop), ein BI-Setup, das gewachsen statt geplant ist.

1. Was Microsoft Fabric eigentlich ist (in einem Absatz)

Fabric packt alles für Analytics in ein Produkt: Datenintegration (Data Factory), Data Lake (OneLake), Data Engineering (Spark), Data Warehouse (SQL), Echtzeit-Analytics und Power BI — abgerechnet über eine gemeinsame Kapazität. Statt fünf Azure-Dienste einzeln zu betreiben, kaufst du eine SKU und bekommst die ganze Kette. Ob das für dich aufgeht, hängt von Details ab, die in keiner Demo vorkommen.

Wenn der Unterschied zu reinem Power BI noch nicht klar ist, lies zuerst den Pillar-Vergleich Microsoft Fabric vs. Power BI. Dieser Artikel setzt die Richtung „Fabric" voraus und konzentriert sich auf das Wie.

2. Phase 1 — Bestandsaufnahme, bevor du irgendetwas migrierst

Der teuerste Fehler passiert vor der ersten technischen Entscheidung: Niemand schreibt auf, was da ist. Bevor du eine Pipeline baust, brauchst du drei Listen.

Erstens: Quellsysteme. Welche Datenbanken, APIs, Dateien, SaaS-Tools fließen ins Reporting? Notiere Volumen, Aktualisierungsfrequenz und Zuständigkeit. Im Mittelstand sind das 4 bis 12 Quellen — nicht 200 wie im Konzern.

Zweitens: bestehende Reports. Liste jeden Power-BI-Report, jede Pivot-Excel, jeden „der Robert schickt das montags"-Prozess. Markiere, was wirklich genutzt wird. Erfahrungsgemäß sind 40 bis 60 Prozent tot — nicht migrieren, abschalten. Das ist der größte Hebel der ganzen Einführung.

Drittens: Skills im Team. Wer kann SQL? Python/Spark? DAX? Das entscheidet über den Lakehouse- oder Warehouse-Pfad. Sei ehrlich — „der könnte sich einarbeiten" ist kein Skill, sondern ein Risiko.

Diese Phase dauert zwei bis vier Wochen, kostet fast nichts außer Aufmerksamkeit — und entscheidet, ob ihr in drei Monaten produktiv seid oder im Pilot festhängt.

3. Phase 2 — Der eine Pilot, der wirklich zählt

Wähle einen Use Case, nicht zwei. Kriterien für einen guten Piloten:

Klarer Owner im Fachbereich, der den Report wirklich braucht.
Nicht die schwierigste Quelle (kein 15 Jahre altes, undokumentiertes ERP als erstes Projekt).
Messbares Ergebnis: „Der Vertriebsleiter sieht die Pipeline morgens aktuell statt freitags manuell zusammengetragen."

Im Piloten baust du die Kette einmal sauber durch: Quelle → OneLake → Modellierung → Report → Verteilung. Du lernst alles Relevante: Refresh-Performance, Kapazitätsauslastung, Akzeptanz im Fachteam.

Hier klärt sich auch die Modellierungsentscheidung — Lakehouse (Spark, gut bei Python-Skills) oder Warehouse (T-SQL, gut bei SQL-starkem Team). Diese Frage ist so wichtig, dass wir ihr einen eigenen Artikel gewidmet haben: Lakehouse vs. Warehouse — was passt für den Mittelstand?. Triff sie nicht im Vorbeigehen.

4. Phase 3 — Skalieren, ohne den Überblick zu verlieren

Wenn der Pilot trägt, wollen plötzlich alle einen Report. Jetzt brauchst du Governance — leichtgewichtig, nicht das Konzern-Framework, sondern drei Regeln, die dein Team auch einhält:

Naming-Konvention für Workspaces, Lakehouses, Datasets — nach sechs Monaten der Unterschied zwischen Ordnung und Chaos.
Dev/Test/Prod-Trennung über Workspaces und Deployment Pipelines. Fabric bringt das mit — nutzt es ab Tag 1 von Phase 3.
Ein Verantwortlicher pro Datenprodukt — eine Person, die weiß, woher die Zahlen kommen.

Parallel führst du Kostentransparenz ein. Fabric rechnet über Capacity Units ab, und in Phase 3 wächst die Last — wer das nicht beobachtet, bekommt am Monatsende eine Überraschung. Welche SKU für welche Last sinnvoll ist, steht in Microsoft Fabric: Kosten und Lizenzen ehrlich erklärt.

5. Phase 4 — Betrieb ist kein Projekt, sondern ein Zustand

„Live gegangen" ist keine Ziellinie. Der Betrieb braucht dauerhaft drei Dinge: Monitoring der Kapazität, FinOps (passt die SKU noch zur Last?) und Enablement (wer baut Reports selbst, statt jede Änderung als IT-Ticket?).

Der letzte Punkt entscheidet über den ROI. Eine Plattform, bei der jede Änderung ein IT-Ticket ist, liefert nie den Wert aus den Folien. Self-Service ist kein Feature, sondern eine Frage von Schulung und sauberen Modellen.

6. Wann du Fabric NICHT einführen solltest

Ehrlichkeit gehört dazu. Lass die Finger von Fabric, wenn:

Deine Datenmengen klein und stabil sind. Besteht dein Reporting aus drei sauberen Power-BI-Datasets, die täglich aus einer SQL-Datenbank aktualisieren, reicht Power BI Pro plus eine ordentliche Azure SQL DB — zum Bruchteil der Kosten. Mehr im Vergleich Fabric vs. Power BI.
Niemand Datenmodellierung kann und ihr keinen Partner wollt. Fabric verzeiht schlechte Modellierung nicht — es macht sie teurer.
Es kein echtes fachliches Problem gibt. „Mal was mit Daten machen" ist kein Use Case.
Das Budget für den laufenden Betrieb fehlt. Nicht die Lizenz ist das Problem, sondern die kontinuierliche Betreuung. Eine Plattform ohne Betreiber verfällt.

Hast du dagegen mehrere Quellen, wachsende Datenmengen und ein Team an der Excel-Grenze: Dann ist Fabric eine ernsthaft gute Wahl — vorausgesetzt, du gehst die vier Phasen diszipliniert durch.

7. Der Mittelstands-Realismus: Mit oder ohne Partner?

Du musst Fabric nicht mit externer Hilfe einführen. Die ehrliche Frage: Hat dein Team Zeit zusätzlich zum Tagesgeschäft, und schon einmal eine Datenplattform aufgebaut? Wenn ja — mach es selbst, günstiger und das Wissen bleibt im Haus. Wenn nicht, lohnt ein Partner vor allem für Phase 1 und 2, gefolgt von einer ehrlichen Übergabe. Ein Partner, der dich dauerhaft abhängig macht, ist der falsche — wie sinnvolle Begleitung aussieht, steht in Power-BI-Beratung für den Mittelstand.

Den größeren Rahmen — Fabric ist Teil eines Microsoft-Datenökosystems — liefern der Leitfaden Microsoft Power Platform für den Mittelstand und der Microsoft-Dataverse-Leitfaden.

Fazit

Microsoft Fabric einzuführen ist kein Technologie-, sondern ein Disziplinprojekt. Die Plattform belohnt Fokus und bestraft Big-Bang-Ehrgeiz. Mach die Bestandsaufnahme, schalte tote Reports ab, migriere einen Use Case sauber statt zehn halb, führe Governance und Kostentransparenz früh ein. Und sei ehrlich, ob ihr den laufenden Betrieb stemmen könnt. Wer die vier Phasen ernst nimmt, ist in einem Quartal produktiv — wer sie überspringt, steckt in einem Jahr noch im Pilot.