Power BI einführen: Die fünf Schritte, die wirklich tragen
Die Lizenzen sind gekauft, das erste Dashboard sieht gut aus, und drei Monate später klickt niemand mehr darauf. Warum das fast nie an der Technik liegt und in welcher Reihenfolge eine Einführung funktioniert.
Die Lizenzen sind gekauft. Jemand aus dem Controlling hat sich zwei Wochen eingearbeitet, das erste Dashboard sieht richtig gut aus. Drei Monate später klickt trotzdem niemand mehr darauf.
So enden auffällig viele Power-BI-Einführungen, und fast nie liegt es an der Technik. Es liegt an der Reihenfolge der Entscheidungen. Aus über 40 Einführungen im Mittelstand hat sich eine Abfolge herausgeschält, die trägt: fünf Schritte, von denen der letzte darüber entscheidet, ob am Ende etwas bleibt.
Lieber hören oder sehen? Die ganze Folge gibt es als Video auf YouTube und zum Anhören auf Spotify.
Die Tool-zuerst-Falle
Die meisten Einführungen starten mit einer Produktfrage. Welche Lizenz, welcher Funktionsumfang, welche Kosten pro Nutzer. Das sind berechtigte Fragen. Es sind nur nachgelagerte. Die eigentliche Frage lautet: Welche Entscheidungen wollen wir künftig schneller und sicherer treffen?
Wer mit dem Werkzeug beginnt, bekommt ein Ergebnis, das technisch sauber und fachlich belanglos ist. Der Bericht funktioniert. Er beantwortet nur keine Frage, die im Unternehmen wehtut. Auffällig wird das nicht in Woche zwei, sondern nach drei Monaten, wenn die Nutzung gegen null läuft.
Dazu kommen zwei Muster: Power BI wird wie ein größeres Excel behandelt, und das erste Projekt wird viel zu groß geschnitten. Beides endet in demselben Satz in der Geschäftsführung, nämlich „BI funktioniert bei uns halt nicht“. Das stimmt nicht. Es wurde nur in der falschen Reihenfolge gearbeitet.
Schritt 1: Erst das Zielbild, dann das Tool
Bevor jemand Power BI Desktop öffnet, steht eine Standortbestimmung an. Drei Dinge gehören dabei auf Papier.
Die Kernzahlen und ihre Empfänger. Wer braucht welche Zahl, wofür und in welchem Intervall? Diese Liste ist unspektakulär und legt den Scope fest, bevor er sich von selbst ausdehnt.
Eine Bewertung der Datenquellen. ERP, CRM, DATEV, verteilte Excel-Listen auf Netzlaufwerken. Was ist verlässlich, was ist nachvollziehbar, was ist bereits automatisiert abgreifbar? Markiere, was heute schon nutzbar ist. Das ist euer Startvorrat.
Eine verantwortliche Person. Jede Aufgabe im Unternehmen braucht Ownership. Eine Arbeitsgruppe drumherum ist sinnvoll, nach außen verantwortlich ist genau ein Name. Fehlt dieser Name, versandet die Einführung spätestens im dritten Monat zwischen IT und Fachbereich.
Nimm ein DIN-A4-Blatt und schreib die drei Fragen auf, bei denen ihr heute zu langsam oder zu unsicher seid. Die schmerzhafteste davon ist euer Startpunkt. Nicht die interessanteste, nicht die technisch eleganteste: die schmerzhafteste.
Zeitrahmen: Woche 1 bis 2. Wer ihn überspringt, baut am Nutzen vorbei und merkt es erst, wenn der Bericht fertig ist.
Schritt 2: Lizenzen und Architektur ohne Drama
Die Lizenzfrage ist für die meisten Mittelständler schnell beantwortet: Power BI Pro, rund 12 Euro pro Nutzer und Monat. Eine eigene Kapazität lohnt sich als Faustregel erst ab etwa 200 rein lesenden Nutzern. Darunter bekommst du diese Leistung kaum irgendwo günstiger.
Wichtiger als die Lizenzstufe ist der Zuschnitt der Arbeitsbereiche. Ob du nach Abteilungen, Bereichen oder Business Cases schneidest, hängt vom Unternehmen ab. Eine Trennung mache ich immer: Entwicklung, Test, Produktion. Sobald ein Bericht produktiv genutzt wird, willst du Änderungen nicht am offenen Herzen vornehmen, sondern in einer Umgebung, in der du ausprobieren und zurückspringen kannst.
Dann die Datenquellen. Liegt eine Excel-Datei in OneDrive, ist sie direkt erreichbar. Liegt dieselbe Datei auf einem Laufwerk im eigenen Netz, brauchst du ein Gateway, also die Brücke vom Power BI Service in euer Netzwerk.
Und schließlich die Spielregeln. Vor jedem Fußballspiel ist klar, wer pfeift und was bei einem Foul passiert. Im Power-BI-Betrieb fehlt diese Klärung erstaunlich oft. Schreib den Entwicklungszyklus eines Berichts einmal auf und hinterlege je Schritt eine Zuständigkeit: Backend, Frontend, Schulung, Stakeholder-Management. Eine halbe Seite reicht.
Der teuerste Fehler in diesem Schritt sind Lizenzen auf Zuruf. Zu viele gekauft, und es steht Geld im Regal. Zu wenige, und die Hälfte der Leser kommt gar nicht erst in den Bericht, weil der Bestellprozess zu aufwendig ist. Beides bremst eine Einführung härter als jede technische Hürde.
Zeitrahmen: Woche 2 bis 3, direkt im Anschluss an das Zielbild.
Schritt 3: Das Datenmodell ist das Fundament
Hier liegt der häufigste Denkfehler. In Excel arbeitest du auf Zeilenebene, sprichst Zelle B35 an und verbindest Tabellen per SVERWEIS. Wer diese Logik mitnimmt und eine breite Tabelle mit 300 Spalten in Power BI kippt, bekommt ein Modell, das eine Weile funktioniert und dann nicht mehr.
Power BI folgt einer anderen Logik, dem Sternschema. In der Mitte steht die Faktentabelle mit den Bewegungsdaten, also Verkäufe, Lagerbewegungen, Einkaufsvorgänge. Drumherum liegen die Dimensionen mit den Stammdaten: Kunden, Produkte, Zeit. Das Konzept stammt aus den 1990er Jahren und ist unverändert gültig. Es zahlt auf Wartbarkeit, Performance und Nachvollziehbarkeit ein, und spätestens wenn DAX ins Spiel kommt, entscheidet diese Trennung über jede einzelne Formel. Wie ein sauberes Modell konkret aussieht, zeigt der Beitrag Ein sauberes Star Schema.
Der zweite Teil des Fundaments ist nicht technisch, sondern fachlich. In fast jedem Unternehmen gibt es den Umsatz in mehreren Versionen: nach Auftragseingang, nach Rechnung, nach Zahlung. Drei Abteilungen, vier Definitionen, alle sagen Umsatz. Die Lösung ist unspektakulär: ein Kennzahlenglossar mit Definition, Formel und verantwortlicher Person. Ob das in einer Excel-Datei, einem Ticketsystem oder einem Master-Data-Service steht, ist zweitrangig. Zentral muss es sein, und es braucht jemanden, dem es gehört.
Dazu kommt die automatische Aktualisierung. Niemand hat Lust, morgens ins Büro zu kommen, einen Knopf zu drücken und zehn Minuten zu warten, bis Zahlen stehen. Das läuft nachts, im Hintergrund, ohne Zutun.
Ein sauberes Fundament sieht man einem Bericht nicht an. Man spürt es in der Verlässlichkeit der Zahlen und in der Geschwindigkeit. Die Zeit dafür nimmst du dir am Anfang, oder du bezahlst sie später beim Refactoring doppelt. Zeitrahmen: Woche 3 bis 6.
Schritt 4: Ein abgegrenzter Bericht, der schnell live geht
Der Fallstrick in diesem Schritt hat einen Namen: die eierlegende Wollmilchsau. Ein Projekt über zwölf Monate, alle Bereiche parallel, am Ende ein Management-Cockpit über alles. Was entsteht, ist ein halbfertiger Prototyp und ein Unternehmen, das Power BI ab jetzt für das Problem hält.
Nimm stattdessen einen klar abgegrenzten Bereich mit sichtbarem Erfolg. Controlling und Vertrieb sind die Klassiker: überschaubare Datenlage, hohe Relevanz, schnelle Wirkung. Bau den Bericht so, dass die Geschäftsführung die wichtigsten Zahlen in Sekunden findet, und gib ihn zuerst an eine kleine Nutzergruppe. Erst danach brichst du den Scope für die nächste Ebene weiter auf, mit dem Feedback aus der ersten Runde statt mit Annahmen.
Dass das kein Schönwetter-Zeitplan ist, zeigen zwei Projekte. Beim WDR war die Einführung nach vier Wochen live, bei DOLL Fahrzeugbau stand das Cockpit für die Geschäftsführung nach rund sechs Wochen produktiv. Möglich war das nur, weil die Schritte davor sauber gelaufen sind. Ein realistischer Rahmen für den ersten produktiven Bericht liegt bei Woche 8 bis 12.
Schritt 5: Befähigung entscheidet, ob etwas bleibt
Hier entscheidet sich, ob die Einführung ein Projekt war oder eine Fähigkeit. Es ist der Schritt, der am häufigsten gekürzt wird, und der Grund, warum Berichte nach einem Quartal in der Ablage verschwinden. Drei Dinge gehören dazu.
Am echten Datenmodell schulen. Keine Folien mit Dummy-Daten. Der Bereich darf klein sein, die Daten dürfen einfach sein, aber es müssen die eigenen sein. Mit fremden Beispieldaten lernen Menschen Klickwege. Mit den eigenen Zahlen lernen sie ihr Geschäft.
Interne Champions aufbauen. Keine Zuschauer, sondern Leute, die abgegrenzte Anforderungen selbst umsetzen. Der externe Experte gibt Leitplanken vor und greift korrigierend ein. Entwickelt wird intern, sonst wandert das Wissen am Projektende mit dem Dienstleister aus dem Haus.
Spielregeln dauerhaft festhalten. Es braucht einen Schiedsrichter, der klar sagt, was ein geprüfter Bericht für alle ist und was Spielwiese bleibt. Technisch löst du das über die getrennten Arbeitsbereiche und einen Freigabeprozess, bei dem Berichte nur im Vier-Augen-Prinzip produktiv gehen. Ohne diese Trennung entsteht innerhalb eines Jahres genau der Wildwuchs, vor dem beim Thema Self-Service immer gewarnt wird.
Danach rollst du Bereich für Bereich aus und betreibst internes Marketing. Am überzeugendsten sind dabei nicht Folien, sondern die Kollegen, die erzählen, was sie seitdem nicht mehr von Hand zusammensuchen.
- Neue Anforderungen setzt das interne Team selbst um.
- Es ist eindeutig, welcher Bericht die offizielle Wahrheit ist.
- Jede zentrale Kennzahl hat genau eine Definition und einen Verantwortlichen.
- Morgens drückt niemand mehr einen Aktualisieren-Knopf.
Der Fahrplan auf einen Blick
-
01
Standortbestimmung und Zielbild · Woche 1 bis 2
Kernzahlen, Empfänger, bewertete Datenquellen, eine verantwortliche Person. Fallstrick: mit dem Tool beginnen statt mit der Frage.
-
02
Lizenzen und Architektur · Woche 2 bis 3
Power BI Pro, Arbeitsbereiche für Entwicklung, Test und Produktion, Gateway, schriftliche Spielregeln. Fallstrick: Lizenzen auf Zuruf.
-
03
Datenmodell als Fundament · Woche 3 bis 6
Sternschema aus Fakten und Dimensionen, Kennzahlenglossar mit Ownership, automatische Aktualisierung. Fallstrick: Power BI als größeres Excel.
-
04
Erster produktiver Bericht · Woche 8 bis 12
Ein abgegrenzter Bereich, sichtbarer Erfolg, Feedback vor dem Ausbau. Fallstrick: alles auf einen Schlag abbilden.
-
05
Befähigung und Skalierung · laufend
Schulung am echten Modell, interne Champions, Freigabe im Vier-Augen-Prinzip, Rollout Bereich für Bereich. Fallstrick: das Wissen bleibt beim Dienstleister.
Fazit
Eine Power-BI-Einführung ist kein Technikprojekt mit Schulungsanhang. Sie ist eine Kette von Entscheidungen, deren Reihenfolge über das Ergebnis bestimmt. Erst die Frage, dann das Werkzeug. Erst das Fundament, dann der Bericht. Erst ein abgegrenzter Erfolg, dann die Breite.
Wer so vorgeht, hat nach wenigen Wochen einen Bericht, dem die Geschäftsführung vertraut, und ein Team, für das Power BI keine Blackbox ist. Der eigentliche Prüfstein kommt danach, und er ist unbequem für jeden Dienstleister: Eine gelungene Einführung erkennst du daran, dass ihr den externen Partner nicht mehr braucht. Wie wir das im Projekt aufsetzen, steht auf der Seite Power BI Einführung.
Wer mit dem Tool beginnt, bekommt ein Dashboard. Wer mit der schmerzhaftesten offenen Frage beginnt, bekommt eine Entscheidungsgrundlage.
Eine Einführung ist erst dann gelungen, wenn ihr euren Dienstleister nicht mehr braucht. Alles davor ist ein verlängerter Testlauf.