NexTool Solutions

Die durchschnittliche Lösungszeit misst, wer die Warteschlange bereits verlassen hat. Das durchschnittliche Ticketalter misst, wer noch darin steht - und genau dort liegt der vergessene Backlog. Dieser Leitfaden zeigt, woher die Zahl im GLPI stammt, warum der Durchschnitt allein täuscht, wie Sie Alter und Stillstand trennen und wie Sie daraus in den von uns betreuten Umgebungen eine wöchentliche Routine zur Backlog-Überprüfung machen.

Was das durchschnittliche Alter misst - und was es verbirgt

Das durchschnittliche Ticketalter ist der Durchschnitt der Tage zwischen der Erstellung und heute, wobei nur Tickets berücksichtigt werden, die weiterhin offen sind. Anders als die mittlere Lösungszeit (MTTR), die nur sieht, was bereits gelöst wurde, bildet es den aktuellen Zustand der Warteschlange ab. Das Problem: Der Durchschnitt allein ist eine sehr schlechte Zusammenfassung einer realen Warteschlange. Ein typischer Backlog ist bimodal - Dutzende neue Tickets, die erst wenige Stunden alt sind, existieren neben einem Ausläufer von Tickets, die seit Wochen stillstehen. Die Masse der neuen Tickets zieht den Durchschnitt nach unten und verbirgt gerade die alten, die Sie finden müssen. Deshalb steht der Durchschnitt nie allein: Er wird von der Verteilung und dem Median begleitet.

Woher die Zahl im GLPI stammt

Alles liegt in der Tabelle glpi_tickets. Das Alter verwendet die Spalte date (Erstellungsdatum); die Abgrenzung „offen“ verwendet status. Die relevanten Status:

• 1 - Neu (noch nicht triagiert)
• 2 - In Bearbeitung (zugewiesen)
• 3 - In Bearbeitung (geplant)
• 4 - Wartend (wartet auf Dritte)
• 5 - Gelöst und 6 - Geschlossen (außerhalb des Backlogs)

Der häufigste Fehler ist hier, alles, was weder 5 noch 6 ist, in einen Topf zu werfen. Tickets im Status Wartend (Status 4) stehen berechtigterweise still, weil sie auf einen Lieferanten, den Kunden oder ein Ersatzteil warten - sie treiben das durchschnittliche Alter nach oben, ohne dass jemand etwas vergessen hätte. Die Segmentierung nach Status ist der erste ehrliche Filter:

-- Idade média por status (segmentar: "Pendente" infla a média)
SELECT
  status,
  ROUND(AVG(DATEDIFF(NOW(), date)), 1) AS idade_media_dias,
  COUNT(*)                             AS total
FROM glpi_tickets
WHERE status NOT IN (5, 6)   -- fora Solucionado e Fechado
  AND is_deleted = 0
GROUP BY status
ORDER BY idade_media_dias DESC;
-- status: 1 Novo, 2 atribuído, 3 planejado, 4 Pendente

Alter ist nicht dasselbe wie Stillstand

Ein Ticket, das vor 40 Tagen erstellt wurde, aber gestern eine erfasste Aufgabe erhalten hat, ist etwas ganz anderes als eines, das vor 40 Tagen erstellt und seitdem von niemandem angefasst wurde. Das Alter (seit der Erstellung) misst die Dauer; der Stillstand (seit der letzten menschlichen Aktion) misst die Vernachlässigung - und der Stillstand zeigt auf das vergessene Ticket.

Im Betrieb war der Fehler, den wir teuer werden sahen, date_mod als „letzte Aktion“ zu verwenden. Die Spalte date_mod des Tickets wird durch alles Mögliche aktualisiert: eine versendete Benachrichtigung, einen hinzugefügten Beobachter, den SLA-Cron, der die Frist neu berechnet, eine auslösende Geschäftsregel. Sie erweckt also den Anschein von Bewegung bei Tickets, an denen niemand tatsächlich gearbeitet hat. Die echte letzte menschliche Aktion steckt in der Folgeaktion und in der Aufgabe - glpi_itilfollowups und glpi_tickettasks. Als wir date_mod durch das maximale Datum dieser beiden Tabellen ersetzt haben, sprang die Liste der stillstehenden Tickets eines Kunden von 3 auf 17: Die anderen 14 wirkten nur lebendig, weil eine Automatisierung sie jeden Tag berührte.

-- Estagnação real: dias desde a última interação humana
-- date_mod não serve (notificações, seguidores e cron o atualizam)
SELECT
  t.id,
  t.name,
  DATEDIFF(NOW(), t.date) AS idade_dias,
  DATEDIFF(NOW(), GREATEST(
      t.date,
      COALESCE(MAX(f.date), t.date),
      COALESCE(MAX(k.date), t.date)
  ))                       AS parado_ha_dias
FROM glpi_tickets t
LEFT JOIN glpi_itilfollowups f
       ON f.itemtype = 'Ticket' AND f.items_id = t.id
LEFT JOIN glpi_tickettasks k
       ON k.tickets_id = t.id
WHERE t.status NOT IN (4, 5, 6)   -- fora Pendente, Solucionado, Fechado
  AND t.is_deleted = 0
GROUP BY t.id, t.name, t.date
HAVING parado_ha_dias >= 7
ORDER BY parado_ha_dias DESC;

Verteilung, nicht nur der Durchschnitt

Bevor Sie auf einen gestiegenen Durchschnitt reagieren, sehen Sie sich die Form der Warteschlange an. Die folgende Abfrage teilt den Backlog in Altersklassen auf und macht den langen Ausläufer sichtbar, den der Durchschnitt glättet:

-- Distribuição do backlog por faixa de idade
SELECT
  CASE
    WHEN DATEDIFF(NOW(), date) <= 3  THEN '0-3 dias'
    WHEN DATEDIFF(NOW(), date) <= 7  THEN '3-7 dias'
    WHEN DATEDIFF(NOW(), date) <= 15 THEN '7-15 dias'
    WHEN DATEDIFF(NOW(), date) <= 30 THEN '15-30 dias'
    ELSE '30+ dias'
  END        AS faixa,
  COUNT(*)   AS chamados
FROM glpi_tickets
WHERE status NOT IN (4, 5, 6)
  AND is_deleted = 0
GROUP BY faixa
ORDER BY MIN(DATEDIFF(NOW(), date));

Als ehrlicher Richtwert (Kalendertage, keine Werktage): unter 3 Tagen ist gesund, 3 bis 7 Tage sind akzeptabel, 7 bis 15 Tage lösen eine Warnung aus, und über 15 Tagen ist eine Überprüfung Ticket für Ticket nötig. Das sind keine universellen Ziele - der faire Wert hängt vom Vertrag und von der Art des Betriebs ab.

Von der Zahl zur Aktion: Entscheidungsmatrix

Ein hohes Alter ist kein Problem; es ist ein Symptom mit mehreren Ursachen. Was hilft, ist, das technische Signal zu lesen und vor dem Handeln zu klassifizieren:

Ein stiller Fall, der Erwähnung verdient: Tickets, die in Neu feststecken, weil die Geschäftsregel für die Zuweisung nicht zur Kategorie passte und nie eine Gruppe gesetzt hat. Sie altern unsichtbar - sie verschwinden aus den Dashboards nach Gruppe und tauchen erst auf, wenn Sie das durchschnittliche Alter ohne Gruppenfilter betrachten.

Die wöchentliche Überprüfung automatisieren

Abfragen von Hand auszuführen skaliert nicht. Wir speichern die Stillstandsabfrage in einer .sql-Datei und planen sie im System-Cron ein, wobei die Zugangsdaten aus einer .cnf-Datei (chmod 600) gelesen werden, damit nie ein Passwort in der Befehlszeile steht. Das Ergebnis ist eine wöchentliche CSV-Datei, die zur Tagesordnung der Backlog-Überprüfung wird:

# /etc/cron.d/glpi-idade  ->  toda segunda 07:30, como www-data
# Gera a lista de chamados estagnados (7+ dias) para a revisão de backlog
30 7 * * 1 www-data /usr/bin/mysql --defaults-file=/etc/glpi/kpi-ro.cnf glpi \
  < /opt/glpi-kpi/estagnados.sql \
  > /var/log/glpi-kpi/estagnados-$(date +\%Y-\%m-\%d).csv 2>&1

Häufige Fehler in der Praxis

• Nur auf den Durchschnitt schauen: Er glättet den Ausläufer. Betrachten Sie immer auch die Verteilung und, wenn möglich, den Median.
• Wartend mit in den Topf werfen: Status 4 ist berechtigtes Warten; allein dadurch steigt der Durchschnitt, und es entsteht ein Fehlalarm.
• date_mod als letzte Aktion verwenden: Automatisierungen aktualisieren es. Verwenden Sie die Daten von Folgeaktionen und Aufgaben.
• Einheiten mit unterschiedlichen Kalendern vergleichen: DATEDIFF zählt Kalendertage; Einheiten mit unterschiedlichen Arbeitszeiten lassen sich nicht eins zu eins vergleichen.
• is_deleted = 0 vergessen: Der Papierkorb des GLPI verschwindet nicht aus der Tabelle und verfälscht jeden Durchschnitt.

Nächster Schritt

Kombinieren Sie das durchschnittliche Alter mit den übrigen Service-Desk-KPIs und bauen Sie alles in einem Dashboard in Metabase oder Grafana mit Filter nach Einheit und Gruppe zusammen. So ist das Alter nicht mehr nur eine Zahl am Monatsende, sondern eine Warnung, die auslöst, solange noch Zeit zum Handeln bleibt.

Bei NexTool fließen Alter und Stillstand des Backlogs in den monatlichen Betriebsbericht ein, den wir unseren Kunden liefern, zusammen mit der Liste der zu rettenden Tickets. Wenn Sie diese Begleitung für Ihr GLPI wünschen, lernen Sie unseren Support- und Betriebsservice kennen.

Geprüft vom Team von NexTool Solutions.