Power BI Zammad: Ticket-KPIs, SLA und Ursachen im Blick
Wir verbinden Zammad-Ticketdaten mit Asset- und Campus-Daten, damit du Servicequalität und Störungen endlich sauber steuern kannst.
- Erstreaktion, Lösungsdauer, SLA je Gruppe
- Kanal-Vergleich: E-Mail, Telefon, Web, Chat
- Tickets verknüpft mit Gerätetyp und Alter
Wenn Zammad-Reporting endet, fängt Steuerung erst an
Das Zammad-Standard-Reporting zeigt dir Ticketzahlen je Gruppe und Zeitraum. Aber die Fragen, die wirklich wehtun, hängen an Daten aus anderen Systemen: Gerätebestand, Organisationseinheiten, Semesterverlauf.
Wenn du halbjährlich per Excel zusammenkopierst, entscheidet die Hochschulleitung am Ende nach Eindruck – nicht nach Ticketlage, SLA-Verstößen und echten Ursachen.
Typische Stolpersteine im Zammad-Reporting
Die Daten sind da – aber ohne Modell und klare Definitionen bleiben KPI-Diskussionen, blinde Flecken und manuelle Berichte.
KPIs sind nicht eindeutig
„Erstreaktion“, „Lösungsdauer“ und „SLA-Erfüllung“ werden je Team anders gelesen. Ohne einheitliche Logik sind Vergleiche zwischen Gruppen und Kanälen kaum belastbar.
Tickets bleiben in Silos
Zammad läuft getrennt von Asset-Verwaltung und Campus-Verwaltungssystem. Damit fehlen dir Zusammenhänge wie Ticketaufkommen nach Gerätetyp, Altersklasse oder Organisationseinheit.
Wöchentliche Steuerung wird Excel-Arbeit
Wenn Berichte manuell halbjährlich entstehen, sind Trends zu spät sichtbar: Tickets ohne Zuweisung, steigende Wiedereröffnungsquote oder Wartezeiten auf Rückmeldung.
Ehrliche Partnerschaften führen zu erfolgreichen Datenprojekten.
Seit Jahren realisieren wir skalierbare Lösungen mit Microsoft Power BI, Fabric und Copilot.
Zertifizierungen
Projekte
zufriedenheit
Für wen lohnt sich Power BI mit Zammad besonders?
Für IT-Leitungen, Gruppenleitungen und Verantwortliche im Service-Management, die wöchentlich steuern wollen – nicht nur rückblickend berichten.
Vor allem dann, wenn du zusätzlich Asset-Daten (Geräte, Alter, Typ) oder Organisationsdaten (Einheiten, Studierenden-/Mitarbeiterbezug) brauchst, um Ursachen zu finden und Beschaffung sowie Personalbedarf zu begründen.
Was steckt im Paket?
Ein klar abgegrenzter Einstieg, der euch schnell auf Kurs bringt – und danach sauber skalierbar bleibt.
KPI-Definitionen & Datenmodell
Wir definieren gemeinsam Erstreaktion, Lösungsdauer, SLA-Erfüllung, Wiederholungsticket und Tickets ohne Zuweisung – und gießen das in ein belastbares Modell für Gruppe, Kanal, Status, Priorität und Anliegenart.
Datenanbindung: Zammad + relevante Quellen
Anbindung der Zammad-Datenbasis (z. B. PostgreSQL) und – wenn sinnvoll – Ergänzung durch Asset-Verwaltung und Campus-Daten. Ziel: Aus Tickets wird Steuerungswissen.
Dashboards für Service-Steuerung
Power BI Dashboards für IT-Leitung und Gruppenleitungen: wöchentliche Sicht auf Ticketvolumen je Kanal, SLA, Erstreaktion, Lösungsdauer, Wartezeit auf Rückmeldung und Wiedereröffnungsquote – inkl. Gruppe-gegen-Gruppe-Vergleich.
Störungsursachen & Geräte im Fokus
Monatliche Analysen für Beschaffung und Betrieb: Tickets je Gerätetyp, Tickets je 100 Geräte, Wiederholungstickets je Gerät, Entwicklung im Semesterverlauf – mit Drilldown bis zur Altersklasse.
Hol dir einen klaren Fahrplan für Power BI mit Zammad
- Gemeinsamer Scope: KPIs, Nutzer, Taktung
- Datenquellen-Check: Zammad, Assets, Campus
- Erstes Dashboard als belastbarer Startpunkt
Gemeinsam erzielte Ergebnisse.
Zwei Beispiele aus der Praxis – typische Ausgangslagen, typische Ergebnisse.
IT-Service an Hochschule: SLA- & Gruppensteuerung wöchentlich
Ausgangslage
- Zammad-Reporting nur nach Gruppe/Zeitraum nutzbar
- KPIs zu Erstreaktion und Lösungsdauer uneinheitlich
- Tickets ohne Zuweisung fallen zu spät auf
- Wöchentliche Steuerung erfolgte per Excel-Export
Ergebnis
- Einheitliche KPI-Definitionen für Erstreaktion, SLA, Lösungsdauer
- Power BI Dashboard: Gruppe-gegen-Gruppe und Kanalvergleich
- Früherkennung für unzugewiesene Tickets und Wiedereröffnungen
- Standardisierter Wochenrhythmus für Team-Reviews
Geräte & Störungen: Ticketdaten mit Asset-Bestand verbunden
Ausgangslage
- Asset-Verwaltung getrennt vom Zammad-Helpdesk
- Beschaffung hatte keine belastbaren Störungsursachen
- Gerätealter nicht mit Ticketaufkommen verknüpfbar
- Monatsberichte wurden manuell zusammengebaut
Ergebnis
- Verknüpfung von Tickets mit Gerätetyp und Altersklasse
- KPIs: Tickets je Gerätetyp und Tickets je 100 Geräte
- Transparenz über Wiederholungstickets je Gerät
- Governance über Datenkatalog/Definitionen für Kennzahlen
Unser Ansatz: In vier Phasen zum Erfolg
Strukturiert vorgehen, schnell liefern, sauber skalieren – damit ihr nicht im Reporting-Gebirge stecken bleibt.
Erstgespräch
Wir klären Use Cases, Nutzerrollen (IT-Leitung, Gruppenleitungen, Beschaffung) und eure KPI-Definitionen: Erstreaktion, Lösungsdauer, SLA, Kanal, Wiederholungsticket. Ergebnis: klarer Scope statt Tool-Bastelei.
Setup
Wir bauen Datenmodell und Datenflüsse für Zammad und eure angebundenen Systeme. Fokus: saubere Dimensionen (Gruppe, Kanal, Status, Anliegenart, Zeitachsen) und ein Bericht, der wirklich steuerbar ist.
Training
Wir nehmen eure Key User mit: Wie liest man die KPIs, wie drillt man von Gruppe auf Anliegenart, und wie macht ihr aus einem Dashboard konkrete Maßnahmen im Wochenrhythmus.
Skalierung
Wenn der Polarstern steht, erweitern wir gezielt: zusätzliche Kennzahlen, weitere Organisationseinheiten, mehr Datenquellen und Governance, damit das Setup wartbar bleibt.
Vom Helpdesk-Export zur echten Service-Steuerung
So fühlt sich der Weg an, wenn du Zammad-Daten in Power BI als Steuerungsquelle aufsetzt.
- KPIs wie SLA und Erstreaktion werden diskutiert
- Excel-Reports halbjährlich und manuell
- Keine Verbindung zu Asset- und Campus-Daten
- Tickets ohne Zuweisung werden zu spät erkannt
- Beschaffung entscheidet ohne Ursachenbild
- Einheitliche KPI-Definitionen für alle Teams
- Wöchentliche Dashboards für Gruppen und Kanäle
- Störungsursachen nach Gerätetyp und Alter sichtbar
- Transparenz zu Wiedereröffnungen und Wartezeiten
- Reporting als Grundlage für Personal und Budget
Wir lassen unsere Kunden für uns sprechen
SANHA GmbH & Co. KG
Ausgangssituation:
- Absatz- und Produktionsplanung auf Basis von Erfahrung statt Daten
- Unzureichende Transparenz über Nachfrageentwicklung am Markt führte zu Planungsunsicherheit
Ergebnis:
- KI-basierte Absatzprognosen als Grundlage für die Produktionssteuerung
- Effiziente Ressourcennutzung und frühzeitig erkennbare Nachfrageentwicklung
GBG Unternehmensgruppe
Ausgangssituation:
- Fragmentierte BI-Landschaft mit Tools wie Snowflake und Tableau
- Strategischer Wunsch nach Microsoft-Integration zur Vereinheitlichung
Ergebnis:
- Integration in das Microsoft-Ökosystem reduziert Systembrüche und vereinfacht die Datenarchitektur
- Unternehmensweite Migration von Tableau und Snowflake zu Power BI und Fabric
EW GROUP GmbH
Ausgangssituation:
- Daten aus zahlreichen internationalen Tochtergesellschaften waren verteilt und schwer vergleichbar
- Management hatte keinen konsolidierten Überblick über zentrale KPIs der einzelnen Gesellschaften.
Ergebnis:
- Zentrale Daten- und Reportingplattform schafft Transparenz über Kennzahlen aller Gesellschaften.
- Fundierte Managemententscheidungen auf Basis konsolidierter Daten statt isolierter Einzelreports.
Pakete, die aus Zammad-Reporting eine Steuerungsbasis machen
Der genaue Umfang hängt von euren Datenquellen und den Use Cases ab – wir schneiden das im Austausch sauber zu.
- Use Cases und Nutzerrollen klären
- KPI-Definitionen (SLA, Erstreaktion, etc.)
- Quellen-Check: Zammad & Co.
- Dashboard-Skizze inkl. Dimensionen
- Datenmodell für Gruppe, Kanal, Zeit
- Anbindung Zammad-Datenbasis
- Dashboard für Service-Steuerung
- Enablement für Key User
- Zusätzliche Quellen: Assets, Campus-Daten
- Monats- und Wochensteuerung kombiniert
- Governance/Definitionen skalierbar aufbauen
- Betriebs- und Weiterentwicklungssetup
Hol dir einen klaren Fahrplan für Power BI mit Zammad
- Gemeinsamer Scope: KPIs, Nutzer, Taktung
- Datenquellen-Check: Zammad, Assets, Campus
- Erstes Dashboard als belastbarer Startpunkt