NexTool Solutions

Eine gute Kennzahl ist eine, deren Herkunft Sie in der Datenbank zeigen können. Dieser Leitfaden zeigt, welche Service-Desk-KPIs sich im GLPI wirklich zu verfolgen lohnen, aus welcher Tabelle und Spalte jede Zahl stammt, welche Richtwerte wir verwenden und welche Fallstricke in den Umgebungen, die wir für Kunden betreuen, bereits Entscheidungen verzerrt haben.

Vor dem KPI: das Datenmodell

Der Fehler, den wir bei der Übernahme eines bestehenden GLPI am häufigsten sehen, ist das Messen „von oben“: rohe Datumswerte zu vergleichen, statt die Felder zu nutzen, die GLPI bereits selbst berechnet. Jedes Ticket in der Tabelle glpi_tickets enthält fertige statistische Spalten, dieselben, die das Statistikmodul verwendet:

• takeintoaccount_delay_stat - Sekunden bis zur ersten Kenntnisnahme (Grundlage der Reaktionszeit / TTO).
• solve_delay_stat - Sekunden bis zur Lösung, bereits abzüglich der Zeit in „Wartend“ und angepasst an den Arbeitskalender der Einheit (Grundlage der mittleren Lösungszeit / TTR).
• waiting_duration - Gesamtzahl der Sekunden, die das Ticket wartend war.
• time_to_resolve und time_to_own - die Fristen (Deadlines) des Lösungs- und des Reaktions-SLA.
• status - der Zustand des Tickets, der bestimmt, was in den Backlog fällt und was nicht.

Das ändert alles: Die mittlere Lösungszeit, berechnet als solvedate - date, unterscheidet sich von dem Wert aus solve_delay_stat (und ist immer größer), weil die rohe Subtraktion Nächte, Wochenenden und Pausen mitzählt. Die richtige Spalte zu wählen ist schon die halbe Arbeit.

Die KPIs, die zählen, und wo jeder einzelne liegt

Es geht nicht darum, zehn Kennzahlen im Dashboard zu haben; es geht darum, die zu haben, die zu Handlungen führen. Die folgende Matrix verbindet jeden KPI mit seiner technischen Quelle im GLPI und einem ehrlichen Richtwert. Richtwert, kein universelles Ziel: Der faire Wert hängt vom Vertrag und von der Art des Betriebs ab.

Die Zahlen direkt aus der Datenbank holen

Das Statistikmodul (unter Unterstützung) eignet sich gut für punktuelle Abfragen und zum Auswerten nach Kategorie, Gruppe, Techniker und SLA. Es versioniert jedoch die Historie nicht Monat für Monat und verknüpft nicht mehrere Kennzahlen in einer einzigen vergleichbaren Zeile. Wenn wir das konsolidierte Bild für den monatlichen Kundenbericht brauchen, gehen wir mit einem Benutzer mit reinen Leserechten an die Datenbank:

-- KPIs do mês corrente em uma única linha (usar usuário somente-leitura)
-- Base: glpi_tickets, os mesmos campos que o módulo Estatísticas consome
SELECT
    COUNT(*)                                                AS volume,
    SUM(status NOT IN (5,6))                                AS backlog,
    ROUND(AVG(NULLIF(takeintoaccount_delay_stat,0))/60, 1) AS tto_min,
    ROUND(AVG(NULLIF(solve_delay_stat,0))/3600, 1)         AS tmr_horas,
    ROUND(
      100 * SUM(solvedate IS NOT NULL AND solvedate <= time_to_resolve)
          / NULLIF(SUM(time_to_resolve IS NOT NULL AND solvedate IS NOT NULL), 0)
    , 1)                                                    AS sla_ttr_pct
FROM glpi_tickets
WHERE is_deleted = 0
  AND date >= DATE_FORMAT(CURDATE(), '%Y-%m-01');

Wiedereröffnungen haben keine eigene Spalte: Sie stecken im Verlauf der Statusänderungen. In glpi_logs ist eine Wiedereröffnung ein Ticket, das den Status Gelöst (Status 5) verlassen hat und wieder in Bearbeitung ging. Das Log speichert den Wert als „5 Solucionado“, daher filtern wir nach dem numerischen Präfix, um nicht von der Sprache der Installation abhängig zu sein:

-- Reaberturas do mês: chamados que saíram de Solucionado (5) e voltaram
-- para atendimento. Em glpi_logs, id_search_option 12 = campo status
SELECT COUNT(DISTINCT items_id) AS reabertos
FROM glpi_logs
WHERE itemtype = 'Ticket'
  AND id_search_option = 12
  AND old_value LIKE '5 %'
  AND new_value REGEXP '^[123] '
  AND date_mod >= DATE_FORMAT(CURDATE(), '%Y-%m-01');

Die monatliche Erfassung automatisieren

Die Abfrage an jedem Monatsersten von Hand auszuführen skaliert nicht. Wir planen die Extraktion mit dem System-Cron ein, verweisen auf eine Zugangsdatendatei .cnf (chmod 600), damit nie ein Passwort in der Befehlszeile steht, und speichern die CSV-Datei außerhalb von GLPI. So entsteht die Zeitreihe, die das native Dashboard nicht speichert:

# /etc/cron.d/glpi-kpi  ->  dia 1 às 06:00, como www-data
# Credenciais no arquivo .cnf (chmod 600), nunca na linha de comando
0 6 1 * * www-data /usr/bin/mysql --defaults-file=/etc/glpi/kpi-ro.cnf glpi \
  < /opt/glpi-kpi/kpi_mensal.sql >> /var/log/glpi-kpi/kpi-$(date +\%Y-\%m).csv 2>&1

Ziele: ehrliche Richtwerte, keine magischen Zahlen

• SLA-Erfüllung (TTR): Über 90-95 % ist für die meisten Verträge gesund. Konstant 100 % deuten meist auf ein zu großzügiges SLA hin, nicht auf Exzellenz.
• Wiedereröffnung: unter 5 %. Liegt sie darüber, untersuchen Sie unvollständige Lösungen oder voreiliges Schließen, um die Frist „einzuhalten“.
• Lösung im First Level: 70-80 %. Unter 60 % fehlt es an Schulung oder die Kategorisierung ist schlecht; deutlich über 90 % sollten Sie falsch klassifizierte komplexe Tickets vermuten.
• Zufriedenheit (CSAT): über 4,0/5,0, aber immer zusammen mit der Rücklaufquote der Umfrage betrachtet.

Fallstricke, die schon zu Bereitschaftseinsätzen wurden

Beim Betrieb von Kundenumgebungen ist das Erste, was wir bei der Übernahme eines bereits laufenden GLPI tun, dem nativen Dashboard nicht zu vertrauen, bevor die Datenbasis validiert ist. Bei einem Kunden mit hohem monatlichem Ticketvolumen wirkte die „offizielle“ mittlere Lösungszeit hervorragend, bis wir bemerkten, dass bei einem Großteil der Tickets bereits bei der Erstellung derselbe Benutzer Autor und Techniker war: eine Selbstzuweisung, die takeintoaccount_delay_stat auf null setzt und die tatsächliche Reaktionszeit verschleiert. Wir haben die Extraktion per geplantem SQL gerade deshalb standardisiert, weil das Statistikmodul keine Historie Monat für Monat speichert; ohne Zeitreihe vergleichen Sie mit Ihrem Gedächtnis, nicht mit Daten.

Die Fallstricke aus der Praxis, die die Auswertung am meisten stören:

• Die mittlere Lösungszeit über Datumsdifferenzen messen. solvedate - date bläht die Zahl auf: Nächte, Wochenenden und die Zeit in „Wartend“ fließen ein. Verwenden Sie solve_delay_stat, das GLPI bereits an den Kalender anpasst.
• Gelöst mit Geschlossen verwechseln. Wenn Tickets nach X Tagen automatisch geschlossen werden, verbirgt die Messung nur von status = 6 die gelösten Tickets, die auf Bestätigung warten. Der Backlog muss 5 und 6 ausschließen.
• Niedriges TTO aus Selbstzuweisung feiern. Ein Ticket, das bereits zugewiesen erstellt wird, setzt die Reaktionszeit auf null; die Zahl sinkt, ohne dass sich der Betrieb im Geringsten verbessert hat.
• Zufriedenheit ohne Rücklaufquote auswerten. Wenn nur Unzufriedene antworten, täuscht der Durchschnitt. Verknüpfen Sie satisfaction damit, wie viele Umfragen tatsächlich beantwortet wurden.

Wenn Ihr GLPI Zahlen zeigt, denen niemand vertraut, liegt das Problem selten am GLPI: Es liegt an der Datenbasis und an der Art der Extraktion. Der GLPI-Betriebssupport von NexTool umfasst die Modellierung dieser Kennzahlen und den konsolidierten Monatsbericht, den die Führungsebene ohne Tabellenkalkulation lesen kann.

Geprüft vom Team von NexTool Solutions.