top of page
Suche

Von Excel Logik zu Datenprodukt

Aktualisiert: 17. Apr.

Wer Excel migrieren will, kopiert oft zuerst Dateien. Nach SharePoint. In Teams. Ins Data Lakehouse. Nach Fabric. Hauptsache raus aus der alten Ablage, rein in die neue Plattform. Nur: Genau dort scheitern viele Vorhaben. Denn das eigentliche Problem sitzt selten im Dateiformat. Es sitzt in der Denkweise. In Unternehmen ist Excel oft nicht nur ein Werkzeug, sondern ein stilles Betriebssystem für Planung, Forecasting, Kalkulation, KPI-Logik und Ausnahmen. Wer nur .xlsx-Dateien verschiebt, hat noch gar nichts migriert. Er hat nur den Speicherort geändert.


Und das ist der Punkt, den viele Teams zu spät merken: Die relevante Migrationsfrage lautet nicht „Wohin mit den Dateien?“, sondern „Welche Entscheidungslogik steckt darin – und wie machen wir daraus etwas, das wiederverwendbar, verständlich und verlässlich ist?“



Excel ist nicht das Problem. Excel ist der Hinweis.

Excel ist in vielen Fällen schlicht der Ort, an dem Business Know-how zuerst sichtbar wird. Fachbereiche bauen dort nicht nur Tabellen. Sie bauen Denkmodelle. Sie definieren, wie Umsatz gerechnet wird. Welche Buchungen ausgeschlossen werden. Was als aktiver Kunde gilt. Wann ein Forecast als plausibel gilt. Welche Ausnahme „diesmal aber wirklich“ berücksichtigt werden muss.


Das Problem ist also nicht, dass Excel existiert. Das Problem ist, dass diese Logik oft personengebunden, dokumentationsarm, schwer testbar und kaum wiederverwendbar ist. Genau deshalb bringt eine reine Datei-Migration so wenig. Sie konserviert nur den bisherigen Zustand – inklusive Wildwuchs, Medienbrüchen und implizitem Wissen.


In der Praxis stecken in Excel-Dateien meist fünf Dinge gleichzeitig:

  • Daten

  • Geschäftslogik

  • Definitionen und Begriffe

  • Prozessschritte

  • Vertrauen


Und genau diese Mischung macht die Sache so heikel. Denn Daten kann man relativ leicht verschieben. Vertrauen und Definitionen nicht.


Der eigentliche Sprung: von der Datei zum Datenprodukt

Wenn wir von Datenprodukten sprechen, meinen wir nicht einfach eine schöne Tabelle in der Cloud. Ein Datenprodukt ist mehr als gespeicherte Daten. Es ist ein klar beschriebenes, nutzbares, verantwortetes und für einen konkreten Zweck gebautes Artefakt. In der Data-Mesh- und Produktlogik beginnt das nicht bei der Quelle, sondern beim Anwendungsfall: Wer braucht was, für welche Entscheidung, in welcher Qualität, mit welchem Rhythmus und mit welcher Verantwortung? Genau dieses vom Use Case rückwärts denken ist ein zentraler Unterschied zur klassischen Excel-Migration.


Das ist aus unserer Sicht der erste mentale Umbau: Nicht mehr „Wir brauchen die Datei auch in Fabric“, sondern „Wir brauchen ein verlässliches Produkt für Forecast, Vertriebssteuerung oder Working Capital“. Das klingt ähnlich, ist aber komplett anders.


Denn plötzlich ändern sich die Fragen:

  • Wer ist der Nutzer?

  • Welche Entscheidung wird damit unterstützt?

  • Welche Kennzahlen müssen eindeutig definiert sein?

  • Wie aktuell müssen die Daten sein?

  • Wer trägt fachliche Verantwortung?

  • Woran erkennen Nutzer, dass sie dem Ergebnis vertrauen können?


Sobald diese Fragen sauber beantwortet sind, wird aus einer Datei langsam ein Produkt. Vorher bleibt es nur digitalisierte Improvisation.


Formeln migrieren reicht nicht. Du musst Semantik migrieren.

Der nächste Denkfehler folgt direkt danach: Viele Teams extrahieren Excel-Logik 1:1 und bauen sie in Power Query, SQL, DAX oder Notebooks nach. Technisch ist das oft möglich. Fachlich ist es häufig zu kurz gedacht.


Denn in Excel steckt selten nur Rechenlogik. Dort steckt Semantik. Also: Was bedeutet Deckungsbeitrag wirklich? Was ist ein aktiver Kunde? Zählt Storno vor oder nach Monatsabschluss? Welche Version gilt bei Abweichungen zwischen Finance und Vertrieb?


Genau deshalb sind gemeinsame semantische Modelle so wichtig. Microsoft beschreibt Managed Self-Service BI ausdrücklich als Modell, bei dem möglichst viele Berichtsersteller auf wenige, zentral bereitgestellte und wiederverwendbare Semantic Models zugreifen. Der Kern ist die Trennung von Modell und Bericht: Das Modell wird gezielt für Wiederverwendung gebaut, Berichte nutzen es per Live-Verbindung weiter. Ziel ist ausdrücklich nicht ein neues Modell pro Report, sondern ein sinnvolles Gleichgewicht mit möglichst wenigen, gut gepflegten Modellen.


Für die Migration aus Excel heißt das konkret: Nicht jede Arbeitsmappe braucht ein eigenes Zielsystem. Oft brauchen zehn Excel-Dateien in Wahrheit nur ein gemeinsames semantisches Fundament, auf das mehrere Reports, Analysen und Planungsprozesse zugreifen.

Das ist anfangs unbequemer, weil man Begriffe klären muss. Langfristig ist es aber genau der Unterschied zwischen Reporting-Basteln und echter Datenarbeit.


Excel darf bleiben – aber in einer anderen Rolle

Hier wird es wichtig, nicht ideologisch zu werden: In vielen Organisationen muss Excel gar nicht verschwinden. Es sollte nur seine Rolle ändern.


Microsoft unterstützt genau dieses Ziel inzwischen recht klar. Excel kann live auf Power-BI-Semantikmodelle zugreifen. Anwender können in Excel mit PivotTables oder Tabellen auf zentral bereitgestellte Modelle arbeiten, statt wieder eigene Schattenmodelle zu bauen. Auch endorsed content wird in Power BI und an Stellen wie Excel sichtbar gemacht, damit vertrauenswürdige Inhalte leichter auffindbar sind.


Das ist ein wichtiger Unterschied. Excel als Eingabe-, Analyse- oder Erklärungsoberfläche? Völlig legitim. Excel als heimliches System of Record für kritische KPIs? Genau dort wird es teuer.

Anders gesagt: Excel darf Werkbank sein. Es sollte nur nicht mehr Lager, Produktionsstraße und Qualitätsmanagement in Personalunion sein.


Ownership schlägt Technik

Der vielleicht wichtigste Schritt in der ganzen Migration hat nichts mit Fabric, Power BI oder SQL zu tun. Er heißt: Ownership. Solange niemand fachlich für ein Ergebnis geradesteht, bleibt jede technische Migration halb fertig. Moderne Datenarbeit braucht klare Verantwortlichkeiten dafür, wer Inhalte baut, pflegt, erklärt und weiterentwickelt. Microsoft unterscheidet in seiner Fabric-/Power-BI-Guidance bewusst zwischen business-led self-service, managed self-service und enterprise ownership. Besonders spannend ist der Mittelweg: Daten und Kernlogik werden zentral gemanagt, während Fachbereiche Verantwortung für Berichte und Anwendungsnähe behalten. Genau diese Mischung aus Disziplin im Kern und Flexibilität am Rand ist in vielen mittelständischen und föderalen Organisationen deutlich realistischer als entweder totale Zentralisierung oder völlige Freiheit.


Auch auf Datenprodukt-Seite ist das klar: Ein Datenprodukt braucht einen klaren Owner und sollte nicht mehreren Domänen gleichzeitig gehören, weil sonst Verantwortlichkeit verwässert und Qualitätsdiskussionen schnell im Kreis laufen. Genau deshalb sind Fabric-Domains interessant. Sie organisieren Daten entlang von Geschäftsdomänen und unterstützen verteilte Governance, weil bestimmte Tenant-Einstellungen an Domain-Admins delegiert werden können. Domains sind damit kein Selbstzweck, sondern ein Strukturmittel: fachliche Nähe vorne, Plattformstandards hinten.


Migration wirkt, wenn Wiederverwendung einfacher ist als Kopieren

Der wahre Reifegrad zeigt sich nicht daran, dass Daten in der Cloud liegen. Er zeigt sich daran, ob Menschen in der Organisation ohne Kopieren arbeiten können. Und genau dort kommen Discoverability, Endorsement und Katalogisierung ins Spiel. Fabric positioniert den OneLake Catalog als zentrale Stelle, um Daten und Inhalte zu finden, zu verstehen und zu nutzen. Der Katalog ist zudem in Teams, Excel und Copilot Studio eingebettet. Parallel helfen Promotion und Certification dabei, vertrauenswürdige Inhalte sichtbar zu machen. Für Shared Semantic Models ist Discoverability explizit ein Mittel, damit andere Autoren vorhandene Inhalte finden und wiederverwenden, statt neue Parallelmodelle zu bauen.


Das klingt nach Governance. Ist es auch. Aber gute Governance ist eben nicht nur Kontrolle. Gute Governance macht das Richtige leichter. In einem guten Zielbild passiert deshalb Folgendes: Ein Fachbereich sucht nicht mehr die richtige Datei, sondern findet ein zertifiziertes Modell. Er fragt nicht mehr den einen Kollegen aus Finance, welche Zahl nun gilt, sondern sieht Definition, Owner und Aktualität direkt am Artefakt. Und er baut keinen achten Umsatzreport auf eigener Datenbasis, sondern nutzt das bestehende Fundament weiter.


Ein pragmatischer Migrationsfahrplan

In Projekten hat sich ein einfacher Grundsatz bewährt: Inventarisiere nicht zuerst Dateien. Inventarisiere Entscheidungen.


Ein pragmatischer Ablauf sieht so aus:

  1. Entscheidungen identifizieren

    Welche Excel-Dateien steuern wirklich etwas? Forecast, Pricing, Budget, Vertriebssteuerung, Bestände, Marge, Bonuslogik.

  2. Logik sichtbar machen

    Nicht nur Tabs und Formeln dokumentieren, sondern Begriffe, Ausnahmen, Freigaben, Datenquellen, Aktualisierungsrhythmen und bekannte Schwachstellen.

  3. Use Cases priorisieren

    Zuerst dort migrieren, wo die Kombination aus Business-Wert, Risiko und Wiederverwendbarkeit am höchsten ist.

  4. Semantik zentralisieren

    KPI-Definitionen, Hierarchien, Zeitlogik und Berechtigungslogik gehören in wiederverwendbare Modelle – nicht in jeden Bericht einzeln.

  5. Excel neu einordnen

    Wo Excel als Oberfläche sinnvoll bleibt, sollte es auf ein zentrales semantisches Fundament zugreifen statt eigene Datenlogik zu hosten.

  6. Ownership und Governance festziehen

    Domain, Owner, Qualitätskriterien, Freigabestatus, Monitoring und Nutzungsbeobachtung müssen von Anfang an mitgedacht werden. Activity Logs und Auditing helfen dabei, Wiederverwendung, Nutzung und Governance nicht nur zu fordern, sondern auch sichtbar zu machen.


Die häufigsten Fehler in solchen Vorhaben

Was fast nie gut funktioniert:

  • Alles migrieren. Nicht jede Excel-Datei ist ein künftiges Datenprodukt. Manche sind einfach nur persönliche Hilfsmittel.

  • 1:1 nachbauen. Wer die alte Tabellenlogik nur technisch übersetzt, übernimmt meistens auch ihre Schwächen.

  • Excel politisch verbieten. Das führt selten zu besserer Datenarbeit, sondern oft nur zu neuen Schattenlösungen.

  • Governance erst später regeln. Später heißt in der Praxis oft nie.

  • Keinen fachlichen Owner benennen. Dann bleibt das neue System technisch hübsch, aber fachlich heimatlos.

Fazit: Gute Migrationen verschieben Verantwortung nach vorne

Die reiferen Projekte erkennt man nicht daran, dass sie am schnellsten Dateien umgezogen haben. Sondern daran, dass sie Begriffe geklärt, Ownership benannt und Wiederverwendung organisiert haben.


Excel-Logik zu migrieren heißt deshalb nicht, Formeln in ein anderes Tool zu kopieren. Es heißt, implizites Wissen explizit zu machen. Es bedeutet, aus individueller Tabellenkunst ein gemeinsames, verlässliches Produkt zu bauen. Und es heißt, Technologie wieder in die richtige Rolle zu bringen: als Enabler für bessere Entscheidungen, nicht als Ersatz für fehlende Klarheit.

Microsoft Fabric, Power BI, Domains, Semantic Models und der OneLake Catalog können dabei sehr viel helfen. Aber sie lösen das Problem nicht automatisch. Die eigentliche Transformation beginnt früher – nämlich in der Frage, ob du weiter Dateien verwalten willst oder endlich Entscheidungen produktivierst.


Für einen starken Datenstack ist das eine der wichtigsten Unterscheidungen überhaupt:

Migriere nicht zuerst Excel-Dateien. Migriere das Denken dahinter.

Der nächste sinnvolle Schritt

Power BI entfaltet seinen Nutzen erst dann vollständig, wenn Dashboards sauber aufgebaut, Datenmodelle durchdacht und Kennzahlen klar definiert sind.Genau diese Grundlagen entscheiden darüber, ob Berichte genutzt oder ignoriert werden.


Wenn du Power BI strukturiert aufsetzen oder bestehende Lösungen verbessern willst, unterstützen wir dich mit:


So wird aus einem funktionierenden Bericht eine belastbare Analytics-Lösung.

bottom of page