Vom Support-Ticket zum Dashboard

Ich habe drei Jahre lang Support gemacht. Das heisst: fremde Systeme lesen, unter Zeitdruck, mit einer Fehlerbeschreibung, die selten das eigentliche Problem trifft. Wer das lange genug macht, entwickelt einen bestimmten Reflex. Nicht raten. Erst reproduzieren, dann eingrenzen, dann anfassen.

Genau dieser Reflex ist es, der mir heute bei Datenmodellen am meisten hilft. Ein kaputtes Measure ist nichts anderes als ein Ticket: Jemand sagt, die Zahl stimmt nicht. Was gemeint ist, muss man herausfinden.

Was drei Jahre Support wirklich beibringen

Der Reflex hat drei Teile, und alle drei übertragen sich eins zu eins auf Datenarbeit:

• Reproduzieren vor reparieren. Wenn ich nicht zeigen kann, wann die Zahl falsch wird, weiss ich auch nicht, ob ich sie repariert habe.
• Die Frage hinter der Frage. «Der Umsatz ist zu tief» heisst manchmal, dass Retouren fehlen, und manchmal, dass jemand einen anderen Zeitraum im Kopf hat als das Filterpanel.
• Eine Änderung pro Schritt. Wer drei Dinge gleichzeitig anpasst und es geht wieder, weiss danach nicht, warum.

Das klingt unspektakulär. Es ist aber der Unterschied zwischen einem Modell, das zufällig funktioniert, und einem, dem man Zahlen glauben kann.

Der Fehler, über den ich am häufigsten stolpere

Wenn ein Bericht bei mir landet, weil die Vorjahresvergleiche nicht stimmen, liegt es fast immer an derselben Stelle: Es gibt keine eigene Datumstabelle, oder sie ist nicht als solche markiert.

Dieses Measure ist auf den ersten Blick korrekt:

Umsatz VJ =
CALCULATE (
    [Umsatz],
    SAMEPERIODLASTYEAR ( 'Datum'[Datum] )
)

Es liefert trotzdem leere Werte oder falsche Summen, sobald eine dieser drei Bedingungen fehlt: Die Tabelle 'Datum' muss eine lückenlose Datumsreihe enthalten, sie muss in Power BI als Datumstabelle markiert sein, und – das wird am häufigsten übersehen – die Visuals müssen über die Datumstabelle filtern, nicht über das Datumsfeld der Faktentabelle.

Der letzte Punkt erklärt das typische Symptom: Im Testvisual stimmt alles, im fertigen Bericht nicht. Die Zeitintelligenz-Funktionen arbeiten auf dem Filterkontext der Datumstabelle. Kommt der Filter von woanders, greifen sie ins Leere.

Warum das Sternschema kein Selbstzweck ist

Die zweite Baustelle sind Modelle, in denen alles mit allem verbunden ist. Meist ist irgendwann eine Beziehung auf bidirektional gestellt worden, weil ein einzelner Filter sonst nicht durchschlug. Danach funktioniert dieser eine Filter – und drei andere Zahlen sind still kaputt.

Ein Sternschema ist keine Formalität, sondern eine Entscheidung darüber, in welche Richtung Filter fliessen dürfen: von den Dimensionen zur Faktentabelle, in eine Richtung, ohne Umwege. Das macht Ergebnisse eindeutig und nebenbei schneller.

Und der günstigste Ort, um Daten in diese Form zu bringen, ist nicht Power BI, sondern die Datenbank. Was ich dort schon aggregiere, muss später niemand mehr durch die Engine schieben:

SELECT
    d.jahr_monat,
    SUM(f.betrag) AS umsatz
FROM   fakt_verkauf AS f
JOIN   dim_datum    AS d
       ON d.datum_id = f.datum_id
GROUP  BY d.jahr_monat;

Was in SQL nicht geht, mache ich in Power Query. Was auch dort nicht geht, erst in DAX. Diese Reihenfolge einzuhalten, spart auf Dauer mehr Zeit als jeder Optimierungstrick im fertigen Bericht.

Warum ich das öffentlich dokumentiere

Zwei Gründe. Erstens lerne ich schneller, wenn ich etwas so aufschreibe, dass es jemand anderes verstehen könnte. Halbe Erklärungen halten dieser Prüfung nicht stand.

Zweitens ist es die ehrlichste Form von Referenz, die ich anbieten kann. Wer überlegt, mit mir zu arbeiten, kann hier nachlesen, wie ich an Probleme herangehe – statt einer Liste von Schlagworten auf einer Profilseite.

Was hier als Nächstes kommt

• Eine Datumstabelle von Hand bauen – und warum ich sie lieber in SQL als in DAX erzeuge
• Power Query: die Schritte, die ich in jedem unsauberen Export zuerst mache
• Wie ich ein gewachsenes Modell aufräume, ohne den bestehenden Bericht zu zerlegen

Wenn dir dabei eine Frage kommt oder du ein Modell hast, das sich merkwürdig verhält: Schreib mir. Die interessantesten Beiträge entstehen aus echten Fällen.