Power BI: Überblick und Vergleich mit Tableau und QlikPower BI: Overview and Comparison with Tableau and Qlik

Von der Idee zu einem Operations Dashboard

Dieses Projekt begann mit einer einfachen Überlegung: Wie würde ich ein Operations Dashboard aufbauen, wenn ich alle Freiheiten hätte? Welche Architektur würde ich wählen? Welche Tools und Prozesse hätten für mich Priorität?

Was auf dem Papier wie ein klassisches BI-Projekt aussieht – Ticketsystem auswerten, KPIs visualisieren – ist für mich gleichzeitig eine Spielwiese für moderne Ansätze in Analytics und Planung. Statt nur zurückzublicken, möchte ich mit diesem Setup perspektivisch auch Pläne und Forecasts abbilden – also in Richtung XP&A denken.

Was treibt mich an diesem Projekt?

Drei Fragen haben mich immer wieder beschäftigt:

• Architektur: Wie kann ich Datenflüsse so aufsetzen, dass sie sauber skalieren – sowohl technisch als auch fachlich?
• Integration von Ist & Plan: Wie kann ich historische Daten (Ist) mit Plänen, Forecasts und „Was-wäre-wenn"-Szenarien kombinieren?
• Selbstständiges Lernen: Wie kann ich mit realen Daten und echten Anforderungen arbeiten, aber in einer Umgebung, die ich vollständig kontrolliere?

Aus diesen Fragen ist eine erste Skizze entstanden:

1. Datenschicht

• Eine relationale Datenbank auf meinem eigenen Server,
• Tabellen für Tickets, Teams, Projekte und Kalender,
• klar definierte Felder und Beziehungen.

2. Modell- & Business-Schicht

Standardisierte Kennzahlen (KPIs):

• Ticketvolumen, Bearbeitungsdauer, SLA-Quote, Backlog-Größe, Workload pro Team,
• später auch einfache Forecasts für das Ticketvolumen.
• Eine saubere Trennung von Rohdaten und Auswertungsebene – eine kleine „Single Source of Truth" für dieses Szenario.

3. Visualisierungs- & Planungsschicht

• Ein Power-BI-Dashboard für Reporting und Visualisierung,
• perspektivisch eine Anbindung an eine Planungsplattform (board),
• um das Szenario in Richtung XP&A zu erweitern: Ist-Daten, Forecasts und einfache Planungsideen miteinander zu verknüpfen.

An der Stelle habe ich zum ersten Mal gemerkt, wie sehr mich diese Architekturlandschaft fasziniert: Daten fließen von der Entstehung (Incidents, Projekte) über modellierte Strukturen in Kennzahlen, die wiederum als Grundlage für Forecasts, Planung und Entscheidungen dienen.

Technische Umsetzung: Power BI mit PostgreSQL

Datenbankstruktur

Die Basis bildet eine PostgreSQL-Datenbank mit folgenden Tabellen:

Tabelle	Beschreibung	Wichtige Felder
ops_fact_ticket	Fakten-Tabelle für Tickets	ticket_id, created_date, resolved_date, priority, team_id
ops_dim_team	Dimensions-Tabelle für Teams	team_id, team_name, department
ops_dim_date	Kalender-Dimension	date_key, year, quarter, month, week
ops_dim_user	User-Dimension	user_id, full_name, role, team_id

Power BI Integration

Die Verbindung zu PostgreSQL erfolgt über den nativen Connector. Wichtige Schritte:

1. DirectQuery für Live-Datenverbindung
2. Beziehungen zwischen Fakten- und Dimensions-Tabellen definieren
3. DAX-Measures für KPI-Berechnungen erstellen
4. Dashboard-Design mit klarer Informationsarchitektur

---

KPI-Beispiele

Folgende Kennzahlen werden im Dashboard visualisiert:

• Ticketvolumen: Anzahl erstellter vs. gelöster Tickets pro Zeitraum
• Durchschnittliche Bearbeitungszeit: Zeit von Erstellung bis Lösung
• SLA-Quote: Anteil der Tickets, die innerhalb der SLA-Zeit gelöst wurden
• Backlog-Entwicklung: Trend offener Tickets über Zeit
• Team-Workload: Verteilung der Tickets nach Team und Priorität

Ausblick: XP&A und Planungsszenarien

Der nächste Schritt ist die Integration einer Planungsebene. Die Idee:

Historische Ist-Daten mit Plan- und Forecast-Szenarien kombinieren, um „Was-wäre-wenn"-Analysen zu ermöglichen.

Geplante Erweiterungen

• Anbindung von board (Planungsplattform) an dieselbe PostgreSQL-Datenbank
• Modellierung von Planwerten (geplantes Ticketvolumen, geplante FTE)
• Ist-vs-Plan-Analysen direkt in Power BI
• Simulationen für Kapazitätsplanung und Ressourcenallokation

Warum dieser Ansatz?

Dieser Aufbau erlaubt mir:

1. Eine konsistente Datenbasis für Ist- und Plandaten
2. Flexibilität bei der Tool-Wahl (Power BI für Viz, board für Planung)
3. Skalierbarkeit für weitere Datenquellen und Use Cases
4. Vollständige Kontrolle über Architektur und Datenqualität

---

Fazit

Dieses Projekt ist mehr als ein Dashboard – es ist eine Lernplattform für moderne Analytics- und Planungsarchitekturen. Der Fokus auf saubere Datenmodellierung, klare KPI-Definitionen und erweiterbare Strukturen macht es zu einem echten „Production-Grade"-Setup – auch wenn es auf meinem eigenen Server läuft.

From Idea to Operations Dashboard

This project started with a simple consideration: How would I build an operations dashboard if I had complete freedom? Which architecture would I choose? Which tools and processes would be my priority?

What looks like a classic BI project on paper – analyzing a ticketing system, visualizing KPIs – is simultaneously a playground for modern approaches in analytics and planning. Instead of just looking backward, I want to eventually model plans and forecasts with this setup – thinking in the direction of XP&A.

What drives me in this project?

Three questions have kept me engaged:

• Architecture: How can I set up data flows that scale cleanly – both technically and functionally?
• Integration of Actuals & Plan: How can I combine historical data (actuals) with plans, forecasts, and "what-if" scenarios?
• Independent Learning: How can I work with real data and real requirements, but in an environment I fully control?

From these questions, an initial sketch emerged:

1. Data Layer

• A relational database on my own server,
• Tables for tickets, teams, projects, and calendar,
• clearly defined fields and relationships.

2. Model & Business Layer

Standardized metrics (KPIs):

• Ticket volume, processing time, SLA quota, backlog size, workload per team,
• later also simple forecasts for ticket volume.
• A clean separation of raw data and analysis layer – a small "Single Source of Truth" for this scenario.

3. Visualization & Planning Layer

• A Power BI dashboard for reporting and visualization,
• prospectively a connection to a planning platform (board),
• to extend the scenario toward XP&A: linking actual data, forecasts, and simple planning ideas.

At that point, I realized for the first time how much this architecture landscape fascinates me: data flows from origin (incidents, projects) through modeled structures into metrics, which in turn serve as a basis for forecasts, planning, and decisions.

Technical Implementation: Power BI with PostgreSQL

Database Structure

The foundation is a PostgreSQL database with the following tables:

Table	Description	Key Fields
ops_fact_ticket	Fact table for tickets	ticket_id, created_date, resolved_date, priority, team_id
ops_dim_team	Dimension table for teams	team_id, team_name, department
ops_dim_date	Calendar dimension	date_key, year, quarter, month, week
ops_dim_user	User dimension	user_id, full_name, role, team_id

Power BI Integration

The connection to PostgreSQL is made via the native connector. Key steps:

1. DirectQuery for live data connection
2. Define relationships between fact and dimension tables
3. Create DAX measures for KPI calculations
4. Dashboard design with clear information architecture

---

KPI Examples

The following metrics are visualized in the dashboard:

• Ticket Volume: Number of created vs. resolved tickets per period
• Average Processing Time: Time from creation to resolution
• SLA Rate: Percentage of tickets resolved within SLA time
• Backlog Trend: Trend of open tickets over time
• Team Workload: Distribution of tickets by team and priority

Outlook: XP&A and Planning Scenarios

The next step is integrating a planning layer. The idea:

Combine historical actual data with plan and forecast scenarios to enable "what-if" analyses.

Planned Extensions

• Connect board (planning platform) to the same PostgreSQL database
• Model planning values (planned ticket volume, planned FTE)
• Actual-vs-plan analyses directly in Power BI
• Simulations for capacity planning and resource allocation

Why this approach?

This setup allows me to:

1. Maintain a consistent data foundation for actual and plan data
2. Have flexibility in tool choice (Power BI for viz, board for planning)
3. Scale for additional data sources and use cases
4. Maintain complete control over architecture and data quality

---

Conclusion

This project is more than a dashboard – it's a learning platform for modern analytics and planning architectures. The focus on clean data modeling, clear KPI definitions, and extensible structures makes it a true "production-grade" setup – even though it runs on my own server.