Power BI wirkt heute zugänglicher denn je: Mit KI-Tools lassen sich in kurzer Zeit Reports, Measures und sogar ganze Datenmodelle „zusammenbauen“.
Genau dadurch steigt jedoch das Risiko, Kompetenz mit Oberfläche zu verwechseln. Dieser Artikel verdichtet zehn praxisnahe Indikatoren, mit denen Entscheider, Controller und BI-Verantwortliche belastbar beurteilen können, ob ein Power-BI-Entwickler wirklich versteht, was er tut – oder nur Ergebnisse reproduziert.
Die neue Realität: „Sieht gut aus“ ist kein Qualitätsnachweis mehr
Noch vor wenigen Jahren war ein sauberes Dashboard ein relativ starkes Signal. Wer überzeugende Visuals liefern konnte, galt schnell als „Power BI Entwickler“.
Inzwischen ist diese Heuristik unsicher geworden.
KI kann Standard-Patterns in DAX generieren, Visuals vorschlagen und Datenmodelle skizzieren – oft innerhalb von Minuten.
Das Problem: Die Qualität eines BI-Systems zeigt sich nicht in der Demo, sondern im Betrieb. Spätestens wenn Datenqualität schwankt, Anforderungen sich verändern, Performance kritisch wird oder Governance greift, trennt sich die Spreu vom Weizen.
Für Entscheider bedeutet das: Recruiting, Freelancer-Auswahl und Projektbesetzung brauchen andere Kriterien als Zertifikate, Buzzwords oder hübsche Screenshots.
Die zentrale Frage lautet nicht mehr: „Kannst du ein Dashboard bauen?“
Sondern: „Verstehst du, was du da baust – und warum?“
________________________
Zehn Indikatoren für echte Power-BI-Kompetenz
1) Kann der Entwickler sein Datenmodell erklären – in fünf Minuten?
Ein guter Entwickler kann die Struktur seines Modells klar begründen:
- Was sind Faktentabellen, was Dimensionen?
- Warum sind Beziehungen genau so gewählt?
- Wo werden Berechnungen umgesetzt – in Power Query, im Modell oder in DAX?
- Welche fachlichen Annahmen stecken dahinter?
Ein schlechter Entwickler „repariert“ Fehlermeldungen, statt Ursachen zu verstehen.
Besonders auffällig wird das bei Beziehungsproblemen: Wenn Many-to-many oder bidirektionale Filterungen eingesetzt werden, nur weil „dann ging’s“, ist das selten ein Zeichen von Expertise – eher von Trial-and-Error.
Prüffrage im Interview:
„Gib mir die Architektur deines Modells – und erkläre mir, welche Entscheidungen du warum getroffen hast.“
2) Kann er komplexe Anforderungen in DAX umsetzen – jenseits von Standard-Patterns?
KI kann Year-over-Year, Moving Averages oder einfache KPI-Logiken häufig gut. Entscheidend wird es dort, wo Businesslogik nicht generisch ist: gewichtete Segmentierungen, dynamische Schwellwerte, kombinierte Bewertungsmodelle, kundenspezifische Ausnahmen.
Echte Kompetenz zeigt sich in der Fähigkeit, Anforderungen sauber in Berechnungslogik zu übersetzen:
- logische Struktur (Zwischenschritte, Variablen, klare Semantik),
- Performance-Bewusstsein (Storage Engine vs. Formula Engine, Reduktion unnötiger Iterationen),
- Debug-Fähigkeit (Methodik statt „Try & Hope“).
Prüffrage:
„Nimm diese Businessregel – wie modellierst du sie? Welche DAX-Strategie wählst du und warum?“
________________________
3) Dokumentiert und strukturiert er seine Arbeit – so, dass sie wartbar bleibt?
BI ist kein Einmalprojekt. Modelle werden erweitert, übergeben, geprüft, neu priorisiert. Dokumentation ist daher nicht „nice to have“, sondern Risikomanagement.
Gute Entwickler:
- kommentieren komplexe Measures,
- verwenden konsistente Benennungen,
- nutzen Ordner-/Display-Folder-Strukturen,
- dokumentieren Annahmen und Definitionen,
- machen ihre Logik für Dritte nachvollziehbar.
Schlechte Entwickler hinterlassen Blackboxes. Das Ergebnis: Sobald die Person das Unternehmen verlässt, entsteht ein Rebuild-Risiko – nicht, weil nichts funktioniert, sondern weil niemand versteht, warum es funktioniert.
Prüffrage:
„Wie stellst du sicher, dass ein Kollege in sechs Monaten deine Lösung übernimmt, ohne sie neu bauen zu müssen?“
________________________
4) Versteht er den Business-Kontext – und kann er Anforderungen challengen?
Power BI ist kein Selbstzweck. Entscheidend ist, ob der Entwickler in Entscheidungen denkt – nicht in Visuals.
Gute Entwickler fragen:
- „Welche Entscheidung soll damit getroffen werden?“
- „Welche Nutzergruppe braucht das – und wofür?“
- „Welche KPI ist wirklich führend – und welche ist nur Dekoration?“
- „Gibt es eine bessere, fokussiertere Darstellung?“
Schlechte Entwickler bauen exakt das, was „bestellt“ wird – auch wenn es unklar, überladen oder fachlich nicht sinnvoll ist. Das Ergebnis sind Dashboards mit 20 KPIs auf einer Seite, ohne Priorisierung, ohne Storyline, ohne Handlungsorientierung.
Prüffrage:
„Welche Fragen stellst du, bevor du anfängst zu bauen?“
5) Wie reagiert er auf Feedback, Fehler und Korrekturen?
Kompetenz ist nicht nur Wissen – sondern Haltung. In einem schnelllebigen Ökosystem wie Power BI kann niemand alles wissen. Gute Entwickler sind lernfähig, reflektiert und offen für Alternativen.
Achte darauf, ob jemand:
- defensiv wird („funktioniert doch“),
- Schuld verschiebt („User müssen besser filtern“),
- oder neugierig bleibt („zeig mir den Case, lass uns verbessern“).
In der Praxis ist diese Reaktion entscheidend, weil BI-Qualität durch Iteration entsteht – nicht durch einmaliges „Fertigstellen“.
Prüffrage:
„Erzähl mir von einem Fall, in dem du deine Lösung nach Kritik fundamental verbessert hast.“
6) Kann er zwischen Lösungsansätzen abwägen – und Trade-offs begründen?
Für nahezu jedes Problem gibt es mehrere Wege.
Kompetenz zeigt sich darin, Alternativen zu kennen und bewusst zu entscheiden:
- Welche Time-Intelligence-Funktion passt zu welcher Datumstabelle?
- Wann Calculation Groups, wann klassische Measures?
- Wann Modellierung, wann DAX?
- Wann Import, wann DirectQuery, wann Composite?
Schlechte Entwickler kennen oft nur den letzten funktionierenden Weg – oder den, den KI vorgeschlagen hat. Das funktioniert bis zum ersten Sonderfall.
Prüffrage:
„Welche Alternativen hast du erwogen – und warum hast du dich so entschieden?“
8) Hat er wiederverwendbare Komponenten – oder startet er jedes Mal bei null?
Professionelle Teams bauen nicht jedes Projekt neu.
Sie entwickeln Bausteine: Standard-Measure-Libraries, Datumstabellen, Patterns, Templates, geprüfte Visual-Konfigurationen.
Das reduziert Aufwand, steigert Qualität und sorgt für Konsistenz. Besonders sichtbar ist das bei mehreren Projekten: Haben KPIs einheitliche Namen? Wiederholen sich Strukturprinzipien? Gibt es dokumentierte Standards?
Schlechte Entwickler arbeiten „aus dem Gedächtnis“ und kopieren situativ aus alten Reports – ohne System. Das skaliert schlecht und produziert Inkonsistenzen.
Prüffrage:
„Welche Standards bringst du mit, damit Projekte schneller und stabiler werden?“
________________________
9) Erkennt er Datenqualitätsprobleme früh – und kommuniziert sie aktiv?
Ein starker Entwickler schaut kritisch auf Daten, bevor er baut:
- Dubletten, fehlende Werte, ungültige Schlüssel,
- Inkonsistenzen in Kategorien,
- unerwartete Granularitäten,
- referenzielle Brüche zwischen Tabellen.
Wichtig: Gute Entwickler nutzen „Shit in, shit out“ nicht als Ausrede, sondern als Anlass für Transparenz. Sie bauen Checks, dokumentieren Annahmen und schlagen Lösungswege vor. Dadurch entsteht Vertrauen – auch wenn Daten nicht perfekt sind.
Schlechte Entwickler entdecken Qualitätsprobleme erst, wenn Fachbereiche Zahlen anzweifeln. Dann beginnt hektisches Debugging – unter politischem Druck.
Prüffrage:
„Welche Data-Quality-Checks baust du typischerweise ein – und wie gehst du damit im Report um?“
10) Kennt er die Grenzen von Power BI – und schlägt Alternativen vor?
Power BI ist stark – aber nicht für jeden Use Case ideal.
Gute Entwickler erkennen, wann Workarounds langfristig teurer sind als eine passende Alternative, z. B. bei komplexen Planungsszenarien mit Writeback, hohen Interaktionsanforderungen oder spezialisierten Funktionen.
Schlechte Entwickler versuchen, alles in Power BI zu erzwingen – weil es „geht“. Das Ergebnis ist häufig ein wartungsintensives Konstrukt, das langfristig mehr kostet als es nutzt.
Prüffrage:
„Wann würdest du Power BI bewusst nicht einsetzen – und was würdest du stattdessen empfehlen?“
Was du aus den zehn Indikatoren ableiten solltest
Nicht jeder Entwickler muss jede Dimension in Perfektion beherrschen. Entscheidend ist das Gesamtbild: Denkweise, Methodik, Kommunikationsfähigkeit und Verständnis für Zusammenhänge.
Wenn du kritische BI-Projekte besetzt, ist „Dashboard bauen“ die Eintrittskarte – nicht das Qualitätsmerkmal. Der echte Unterschied wird sichtbar, sobald:
- etwas nicht funktioniert,
- Anforderungen nicht in Standard-Patterns passen,
- Debugging notwendig wird,
- Datenqualität oder Governance das Modell herausfordert.
Genau dort zeigt sich Professionalität.
________________________
Takeaway
Im KI-Zeitalter ist Output billig geworden – Verständnis bleibt selten.
Wer Power BI nur „zusammenklickt“, wirkt kompetent bis zur ersten Abweichung vom Standard.
Wer die Mechanik dahinter beherrscht, liefert robuste Systeme, die Entscheidungen tragen – auch wenn Daten chaotisch sind und Anforderungen sich ändern.
Die beste Interview-Frage ist deshalb nicht: „Welche Reports hast du gebaut?“
Sondern: „Erklär mir, warum du sie so gebaut hast – und was du anders machen würdest, wenn sich der Kontext ändert.“
