Ein Semantikmodell für ein Contact-Center-Dashboard in Power BI aufbauen

Wenn Sie schon einmal eine Power-BI-Datei übernommen haben, in der jedes Measure ein Gewirr verschachtelter IF-Anweisungen ist und zwischen den Registern nichts recht zusammenpasst, liegt das eigentliche Problem mit hoher Wahrscheinlichkeit nicht im DAX. Es liegt im Modell darunter.

Dieses Muster habe ich im Service- und Contact-Center-Reporting immer wieder gesehen. Jemand baut einen Report, indem er Felder direkt aus einem flachen Export zieht (Anrufe, Tickets, was das Quellsystem eben ausgibt), die ersten Visuals sehen gut aus, und drei Wochen später fragt jemand: „Warum sieht die durchschnittliche Bearbeitungszeit auf dieser Seite anders aus als auf jener?“, und niemand kann es erklären. Meist lautet die Antwort, dass das Modell nie wirklich ein Modell war. Es war eine breite Tabelle, die so tat, als wäre sie eines, und jedes Measure musste das für sich allein ausgleichen.

Bevor ich bei einem neuen Contact-Center-Dashboard eine einzige DAX-Formel anfasse, nehme ich mir deshalb Zeit für das Semantikmodell. So gehe ich vor.

Zuerst Fakten und Dimensionen trennen

Ein Contact-Center-Datensatz ist voll von Dingen, die sich täglich ändern (Anrufe, Tickets, Chats), und von Dingen, die weitgehend gleich bleiben (Agenten, Queues, Kanäle, SLA-Ziele). Sie gehören in verschiedene Tabellen.

Mein Ausgangspunkt ist fast immer:

• Eine Faktentabelle für Interaktionen: eine Zeile pro Anruf oder Ticket, mit Fremdschlüsseln zu Datum, Agent, Queue und Kanal, dazu die numerischen Felder, die Sie tatsächlich aggregieren (Bearbeitungszeit, Wartezeit, Lösungskennzeichen, CSAT-Wert, falls vorhanden).
• Eine Datumsdimension, sauber aufgebaut mit einem lückenlosen Kalender, nicht nur mit den Tagen, die zufällig in den Daten vorkommen.
• Eine Agentendimension mit Attributen wie Team, Betriebszugehörigkeit, Schicht und gegebenenfalls Standort.
• Eine Queue- oder Skill-Dimension, denn die meisten Contact Center routen nach Queue, und die Führung will Queues miteinander vergleichen.

Das ist ein Sternschema, und ja, es ist die langweilige Lehrbuchantwort, aber sie ist langweilig, weil sie funktioniert. Enthält Ihre Faktentabelle nur Zahlen und Schlüssel und Ihre Dimensionen nur beschreibende Attribute, verhalten sich Filtern und Aufschlüsseln so, wie Menschen es erwarten. Klicken Sie in einem Datenschnitt (Slicer) auf eine Queue, reagiert jedes Visual auf der Seite gleich, weil jedes Visual aus denselben Beziehungen schöpft, statt eine eigene private Logik auszuführen.

Die Granularität klären, bevor irgendetwas anderes

Die wichtigste Entscheidung in einem Contact-Center-Modell ist die Granularität der Faktentabelle, also was eine Zeile tatsächlich darstellt. Ist es eine Zeile pro Anruf? Pro Anrufsegment (wenn Anrufe weitergeleitet werden)? Pro Statusänderung eines Tickets?

Ich habe Dashboards scheitern sehen, weil jemand Granularitäten unbemerkt vermischt hat, zum Beispiel „eine Zeile pro Anruf“ und „eine Zeile pro Anrufereignis“ in dieselbe Tabelle geladen hat. Sobald Sie eine Spalte über gemischte Granularitäten summieren, entstehen Zahlen, die plausibel aussehen, aber falsch sind, und das ist schlimmer als offensichtlich falsche Zahlen, weil es niemand bemerkt.

Legen Sie die Granularität vorab fest, dokumentieren Sie sie irgendwo (und sei es nur ein Kommentar in Power Query) und halten Sie jede nachgelagerte Transformation konsistent damit. Brauchen Sie für eine bestimmte Analyse eine andere Granularität, etwa Anrufsegmente für die Analyse von Weiterleitungen, bauen Sie dafür eine eigene Faktentabelle, statt Ihre Haupttabelle zu verbiegen.

Immer eine richtige Datumstabelle bauen

Ich weiß, dass dies in jedem Power-BI-Artikel steht, der je geschrieben wurde, aber im Contact-Center-Reporting zählt es mehr als üblich, weil so vieles, was die Führung sehen will, zeitbezogen ist: Trends zum Vormonat, Muster nach Wochentag, Tagesvolumen in Halbstundenintervallen.

Einige Dinge nehme ich in diesem Kontext immer in die Datumstabelle auf:

• Eine Spalte für die Geschäftsperiode (Fiscal Period), wenn das Unternehmen nicht nach Kalendermonaten arbeitet.
• Ein Kennzeichen für Tagestyp oder Arbeitstag, denn Anrufvolumen und Personalpläne sind meist nur im Vergleich mit Arbeitstagen sinnvoll.
• Wenn die Analyse innerhalb des Tages wichtig ist, eine eigene Zeitdimension (in 15- oder 30-Minuten-Intervallen), statt Tageszeitlogik zur Abfragezeit in DAX zu zwängen.

Markieren Sie sie in Power BI als Datumstabelle (Als Datumstabelle markieren) und verknüpfen Sie alles darüber. Lassen Sie nicht jede Faktentabelle ihre eigene Ad-hoc-Datumslogik mitführen.

Beziehungen möglichst in eine Richtung halten

Contact-Center-Modelle sammeln schnell viele Beziehungen an: Interaktionen zu Agenten, Agenten zu Teams, Interaktionen zu Queues, Queues zu Kanälen, Interaktionen zu Datum. Es ist verlockend, alles bidirektional zu machen, damit das Filtern „einfach von jeder Seite funktioniert“. Widerstehen Sie.

Bidirektionale Beziehungen sind in bestimmten, bewussten Fällen nützlich (etwa eine Many-to-many-Brückentabelle zwischen Agenten und Skills, wenn Agenten mehreren Skill-Gruppen angehören können). Überall sonst hält ein Filter von der Dimension zur Faktentabelle in eine Richtung Ihr Modell berechenbar und viel leichter zu debuggen, wenn eine Zahl falsch aussieht. Muss sich ein Filter für ein bestimmtes Visual in die andere Richtung ausbreiten, lösen Sie das innerhalb eines Measures mit CROSSFILTER, statt es zum Standard des Modells zu machen.

Für die Measures entwerfen, die Sie wirklich brauchen

Das ist der Teil, den man gern überspringt. Bevor ich das Modell baue, schreibe ich (auf Papier oder in einer Notiz-App) die Liste der KPIs auf, die das Dashboard liefern soll: durchschnittliche Bearbeitungszeit, Service Level, Abbruchquote, Erstlösungsquote, Auslastung, was eben zutrifft. Dann prüfe ich, ob das Modell in dieser Form alle sauber tragen kann.

Manche KPIs brauchen mehr, als die Interaktions-Faktentabelle hergibt. Der Service Level etwa braucht meist sowohl eine Interaktionstabelle als auch eine eigene Tabelle mit Intervallzielen für Personal oder Volumen, denn „Anteil der Anrufe, die innerhalb von X Sekunden beantwortet werden“ vergleicht eigentlich zwei verschiedene Granularitäten. Planen Sie das nicht vorab ein, bauen Sie später eine zweite, unpassende Tabelle an und schreiben zunehmend umständliches DAX, um beide zusammenzubringen.

Vom KPI-Katalog rückwärts zum Modellentwurf zu arbeiten, erspart Ihnen, das Ganze nach drei Überarbeitungen von vorn zu bauen.

Ein Modell, das trägt

Nichts davon ist für sich genommen kompliziert. Sternschema, eine klare Faktentabelle pro Granularität, eine richtige Datumstabelle, bewusste Beziehungen und ein Modell, das um die KPIs herum entworfen ist, die Sie tatsächlich berichten müssen. Den Unterschied macht, dass Sie es tun, bevor Sie ein einziges DAX-Measure schreiben, und nicht erst, wenn das Dashboard halb gebaut ist und schon etwas nicht stimmt.

Bringen Sie zuerst das Modell in Ordnung, und die meisten Ihrer DAX-Formeln werden kürzer und offensichtlicher, als Sie erwarten. Das Measure muss die Fehler des Modells nicht ausgleichen, weil es keine gibt.

Starren Sie gerade auf eine Power-BI-Datei, in der die Zahlen zwischen den Seiten nicht zusammenpassen, lohnt es sich, das Modell zu prüfen, bevor Sie ein weiteres Measure anfassen. Meist liegt dort das eigentliche Problem.