Power BI für Znuny: Tickets richtig steuern
Wir bringen deine Znuny-Daten aus PostgreSQL in Power BI, damit du Bearbeitungsdauern (inkl. Wartezeit-Logik), SLA-Quoten und Ursachen sauber auswertest.
- Netto- und Bruttozeiten je Queue
- Reaktionsvorgaben, Eskalation, Wiedereröffnung
- Störungsarten und Netzgebiete analysieren
Wenn Znuny-Statistiken nicht reichen, wird Excel zum Flaschenhals
Das Znuny-Statistikmodul liefert Ticketzahlen je Queue und Monat – aber keine belastbaren Aussagen zu Erstreaktion, Bearbeitungsdauer netto/brutto oder offenen Tickets nach Alter.
Am Ende klebt jemand Exporte zusammen, baut eine Monatsübersicht in Excel und alle diskutieren über Zahlen, die Wartezeiten auf Rückmeldungen mitrechnen.
Diese 3 Fragen entscheiden, ob dein Service wirklich steuerbar ist
Wenn du sie nicht schnell beantworten kannst, fehlt dir im Alltag die Sicht auf Engpässe, Zielverfehlungen und Ursachen.
Wie lang dauert ein Ticket wirklich?
Ohne Rekonstruktion von Statuswechseln fehlt die Trennung zwischen Bearbeitungszeit und Wartezeit. Das verzerrt Kennzahlen und macht Vergleiche zwischen Queues unfair.
Welche Queues verfehlen deine Reaktionsvorgaben?
Erstreaktionszeit, Anteil innerhalb der Vorgabe und Eskalationen müssen täglich sichtbar sein – nicht erst, wenn der Monatsreport fertig ist.
Welche Störungsarten treiben dein Volumen?
Wenn benutzerdefinierte Felder wie Störungsart, Netzgebiet oder Zählernummer nicht ausgewertet werden, bleibt Ursachenarbeit liegen und das Ticketaufkommen steigt.
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 Znuny besonders?
Für Teams, die Znuny als zentrales Ticketsystem nutzen und mehr brauchen als Ticketzahlen pro Queue.
Typisch: IT-Leitung, Leitung Kundenzentrum, Teamleitungen, Netzbetrieb und Qualitätsmanagement – mit einem wöchentlichen Steuerungsreport plus täglicher Sicht auf offene Tickets.
Was steckt im Paket?
Klarer Scope, sauberer Datenweg, KPIs die du verteidigen kannst.
Datenmodell aus Znuny + PostgreSQL
Wir bauen ein Modell entlang deiner Dimensionen: Queue, Team, Status/Statustyp, Priorität, Zeitpunkte (Erstellung, Erstreaktion, Statuswechsel, Schließung) und deine benutzerdefinierten Felder.
Logik für Wartezeit & Nettozeiten
Bearbeitungsdauer brutto und netto sind nicht „ein Feld“, sondern eine Logik. Wir rekonstruieren Statuswechsel, definieren Wartezeiten und machen Regeln transparent.
Power BI Dashboards für Steuerung
Queues vergleichen, offene Tickets nach Alter, Wiedereröffnungsquote, Eskalationsanteil, Ticketvolumen je Wochentag – plus Drilldowns nach Störungsart und Netzgebiet.
Betrieb, Rollen & Reporting-Rhythmus
Wer schaut täglich, wer wöchentlich, wer monatlich? Wir definieren Views, Berechtigungen und einen Reporting-Rhythmus, der im Alltag wirklich genutzt wird.
In 30 Minuten klären wir, ob eure Znuny-KPIs belastbar werden
- Use Cases und KPIs gemeinsam abgrenzen
- Sauberer Weg von PostgreSQL zu Power BI
- Nächste Schritte mit klarem Scope
Gemeinsam erzielte Ergebnisse.
Zwei Beispiele aus der Praxis, wie Znuny-Daten zu Steuerung werden.
Kundenzentrum & IT: Queue-Vergleich mit Nettozeiten
Ausgangslage
- Znuny-Queues historisch gewachsen, ähnliche Bedeutung
- Monatsübersicht in Excel aus Statistik-Exporten
- Bearbeitungsdauer wirkte zu hoch durch Wartezeiten
- SLA-Verfehlungen nur gefühlt, nicht messbar
Ergebnis
- Power BI Dashboard je Queue: Erstreaktion, Eskalation, Wiedereröffnung
- Bearbeitungsdauer netto/brutto aus Statuswechseln abgeleitet
- Tägliche Sicht auf offene Tickets nach Alter
- Vergleiche: Queue vs. Queue, Vorjahr, Zielvorgabe
Netzbetrieb: Störungsarten und Netzgebiete sichtbar machen
Ausgangslage
- Benutzerdefinierte Felder gepflegt, aber kaum ausgewertet
- Keine Trendanalyse nach Störungsart und Netzgebiet
- Wiederholungen je Standort/Zählernummer nicht transparent
- Qualitätsmanagement musste manuell nacharbeiten
Ergebnis
- Monatliches Reporting: Tickets je Störungsart und Netzgebiet
- Drilldown auf Wiederholungsquote je Standort
- Auslastung je Team und Nachrichten je Ticket im Überblick
- Governance für Felder & Definitionen in Purview dokumentiert
Unser Ansatz: In vier Phasen zum Erfolg
Strukturierter Weg vom Ticketbestand zum Steuerungs-Cockpit.
Erstgespräch
Wir klären deine KPI-Definitionen (Erstreaktion, Wartezeit, Eskalation, Statustyp) und grenzen Use Cases sauber ab: tägliche Steuerung vs. monatliche Ursachenanalyse.
Setup
Wir verbinden Znuny/PostgreSQL, bauen das Datenmodell und setzen die Logik für Statuswechsel sowie Netto-/Bruttozeiten so um, dass sie nachvollziehbar bleibt.
Training
Wir gehen mit IT-Leitung, Kundenzentrum und Teamleitungen durch die Dashboards, definieren Drilldowns und sorgen dafür, dass jeder die Kennzahlen gleich interpretiert.
Skalierung
Danach erweitern wir schrittweise: weitere Queues konsolidieren, neue Dimensionen ergänzen (z.B. Netzgebiet), und das Modell für Self-Service stabil betreiben.
So verändert sich eure Ticket-Steuerung mit Power BI
Weniger Diskussionen über Zahlen. Mehr Klarheit, wo du ansetzen musst.
- Excel-Report aus Exporten zusammengebaut
- Bearbeitungsdauern verzerrt durch Wartezeiten
- Queues schwer vergleichbar, Definitionen unklar
- Störungsarten/Netzgebiete bleiben ungenutzt
- Offene Tickets nach Alter nicht im Blick
- Zentrale Power BI Sicht auf Queues und Teams
- Netto- und Bruttodauer nachvollziehbar definiert
- SLA-/Reaktionsvorgaben als Steuerungs-KPI
- Ursachenanalyse nach Störungsart und Netzgebiet
- Täglich: offene Tickets nach Alter und Priorität
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: vom ersten Znuny-Dashboard bis zur Plattform
Du startest klein – und skalierst nur, wenn der Nutzen steht.
- Scope-Workshop für Use Cases
- PostgreSQL-Anbindung und Basis-Modell
- 1 Dashboard: Queue-Steuerung
- KPI-Definitionen dokumentiert
- Statuswechsel-Logik für Wartezeit/Nettozeit
- Mehrere Seiten: SLA, Offene Tickets, Trends
- Vergleiche: Queue, Vorjahr, Zielvorgabe
- Enablement für Teamleitungen
- Bereichsübergreifendes Modell (Kundenzentrum/Netzbetrieb)
- Ursachenanalyse: Störungsart, Netzgebiet, Standort
- Governance/Glossar mit Purview optional
- Betriebs- und Rollenkonzept für Wachstum
In 30 Minuten klären wir, ob eure Znuny-KPIs belastbar werden
- Use Cases und KPIs gemeinsam abgrenzen
- Sauberer Weg von PostgreSQL zu Power BI
- Nächste Schritte mit klarem Scope
Häufige Fragen
Geht das mit Znuny überhaupt sauber – oder nur per Export?
Sauber ist, wenn du direkt an die Znuny-Daten in PostgreSQL gehst und die notwendigen Ereignisse (Erstellung, Erstreaktion, Statuswechsel, Schließung) modellierst. Exporte eignen sich eher als Übergang – für Steuerung sind sie meist zu brüchig.
Wie bekommt man Bearbeitungsdauer netto ohne Wartezeiten hin?
Über die Rekonstruktion der Statuswechsel und klare Regeln, was als Wartezeit zählt (z.B. „Warten auf Rückmeldung“). Daraus entsteht neben der Bruttodauer auch eine Netto-Bearbeitungszeit, die Teams fair messbar macht.
Können wir unsere benutzerdefinierten Felder wie Störungsart und Netzgebiet auswerten?
Ja – genau dafür lohnt sich Power BI mit Znuny. Wir nehmen die Felder ins Datenmodell auf, prüfen Wertequalität und bauen Auswertungen wie Tickets je Störungsart, Trend über Monate und Vergleiche zwischen Netzgebieten.
Was müssen wir intern beitragen?
Du brauchst jemanden für Fachdefinitionen (KPIs, Statustypen, Reaktionsvorgaben) und jemanden für den Datenzugang (PostgreSQL, ggf. AD-Gruppen/Berechtigungen). Ohne diese Inputs wird es sonst ein Ratespiel – und das vermeiden wir.