Zu wissen, wo Sie stehen, ist der erste Schritt, um zu wissen, wohin Sie wollen. Dieser Leitfaden zeigt, wie Sie den ITSM-Reifegrad Ihres Betriebs mit objektiven Signalen aus GLPI selbst bewerten – ohne sich auf Eindrücke zu verlassen – und wie Sie die nächsten Entwicklungsschritte priorisieren.
Reife misst man nicht nach Meinung
Die Frage „Auf welcher Stufe stehen wir?“ bekommt fast immer eine emotionale Antwort: Wer jeden Tag Brände löscht, schwört, auf Stufe 1 zu sein, und der Manager, der den Kauf des Werkzeugs genehmigt hat, schwört auf Stufe 4. Beide liegen falsch, weil sie ein Gefühl messen, keinen Prozess. ITSM-Reife ist der Grad der Formalisierung, Automatisierung und Optimierung des Servicemanagements, und sie hinterlässt messbare Spuren in der Datenbank des Werkzeugs. Bevor Sie Beratung beauftragen oder weitere Module kaufen, lohnt es sich, diese Spuren auszuwerten.
Objektive Diagnose: Fragen Sie GLPI selbst
Drei Signale trennen einen reifen von einem unreifen Betrieb recht zuverlässig: wie viele Tickets tatsächlich kategorisiert sind, wie viele ein verknüpftes SLA haben und wie lange ihre Lösung dauert. Führen Sie die folgende Abfrage direkt in der Datenbank (schreibgeschützt) über die letzten 90 Tage aus:
-- Maturity signals over the last 90 days (GLPI 10/11)
SELECT
COUNT(*) AS total_tickets,
ROUND(100 * SUM(itilcategories_id > 0) / COUNT(*), 1) AS pct_categorized,
ROUND(100 * SUM(slas_id_ttr > 0) / COUNT(*), 1) AS pct_with_resolution_sla,
ROUND(AVG(TIMESTAMPDIFF(HOUR, date, solvedate)), 1) AS avg_hours_to_resolve
FROM glpi_tickets
WHERE date >= DATE_SUB(NOW(), INTERVAL 90 DAY)
AND is_deleted = 0
AND solvedate IS NOT NULL;
Einordnung aus der Praxis: Unter 70 % kategorisierter Tickets können Sie Problemmanagement vergessen – Ihnen fehlt die Grundlage, um Wiederholungen zu gruppieren. Unter 50 % mit verknüpftem SLA messen Ihre Erfüllungsberichte nur den Anteil mit Frist, nicht den gesamten Betrieb. Und wenn die durchschnittliche Lösungszeit in Stunden von Monat zu Monat stark schwankt, ist der Prozess immer noch ad hoc, auch wenn es ein Werkzeug gibt.
Matrix: Stufe x Signal in GLPI x Maßnahme
Nutzen Sie die Matrix, um Ihre Stufe anhand dessen zu bestimmen, was GLPI heute zeigt, nicht anhand dessen, was es Ihrer Meinung nach zeigen sollte:
| Stufe | Beobachtbares Signal in GLPI | Nächste technische Maßnahme | Zielkennzahl |
|---|---|---|---|
| 1 – Ad hoc | Kein Werkzeug oder Tickets ohne Kategorie/SLA | GLPI einführen, Einheit und Profile anlegen | 100 % der Tickets im Werkzeug |
| 2 – Wiederholbar | Tickets werden erstellt, aber die Kategorie „Sonstiges“ dominiert | Schlanker Kategorienbaum + erstes SLA | >70 % kategorisiert |
| 3 – Definiert | Kategorien und SLA in Gebrauch; manuelle Verteilung | Geschäftsregeln (Zuweisung), Wissensdatenbank | Verknüpftes SLA >90 % |
| 4 – Gesteuert | Kennzahlen werden erhoben; Cron im CLI-Modus | Problem- und Änderungsmanagement, Dashboards | Erfülltes SLA >90 % |
| 5 – Optimiert | Entscheidungen auf Datenbasis; ausgereifte Automatisierung | Analyse von Wiederholungen, Integration mit dem Geschäft | Jährlicher Rückgang der Wiederholungsfälle |
Das Betriebsdetail, das jede Kennzahl verfälscht
Beim Betrieb von Kundenumgebungen täuscht die Kennzahl „SLA erfüllt“ am meisten, wenn die automatischen Aktionen von GLPI im Modus GLPI (vom Browser ausgelöst) statt im CLI-Modus laufen. In diesem Modus erfolgen die Neuberechnung der Fristen, die Eskalationen und die Benachrichtigungen nur, wenn jemand eine Seite des Systems öffnet. Ergebnis: Um 3 Uhr morgens, wenn niemand angemeldet ist, wird kein Ticket eskaliert, und der Bericht am nächsten Tag zeigt ein grünes SLA, das nicht der Realität entspricht. Der häufige Fehler ist, dem Dashboard zu vertrauen, ohne unter Einrichtung > Automatische Aktionen den Ausführungsmodus zu prüfen. Die Korrektur besteht darin, alles auf CLI zu vereinheitlichen und den System-Cron einzuplanen:
# /etc/cron.d/glpi - runs the automatic actions every minute
# Works for GLPI 10 and 11 (front/cron.php is portable; on 11 avoid depending on the console)
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php &>/dev/null
Stellen Sie nach der Umstellung auf CLI unter Automatische Aktionen das Feld „Ausführungsmodus“ jeder kritischen Aufgabe (queuednotification, slaticket, closeticket) auf CLI um. Ohne das stehen Sie vielleicht auf dem Papier auf Stufe 4 und in der Praxis auf Stufe 2.
Die Falle des geerbten Kategorienbaums
Ein weiterer wiederkehrender Stolperstein: aufsteigen zu wollen in der Annahme, „viele Kategorien“ seien ein Zeichen von Reife. Es ist das Gegenteil. Wir haben einmal den Betrieb einer Umgebung übernommen, die rund 400 aus einem Altsystem importierte Kategorien mitbrachte, verschachtelt über fünf Ebenen. In der Praxis fanden die Bearbeiter die richtige Kategorie nicht, wählten die erste, die erschien, und das Feld wurde zu Rauschen. Wir haben die Historie der letzten Monate neu kategorisiert, den Baum auf gut zwei Dutzend Kategorien gekürzt, die abbildeten, was das Team tatsächlich bearbeitet, und erst dann ergaben die Berichte nach Ursache einen Sinn. Die Faustregel, die wir anwenden: Hat eine Kategorie seit 90 Tagen kein Ticket erhalten, ist sie ein Kandidat zum Entfernen. Zu viele Kategorien messen keine Reife; sie behindern die Triage und verfälschen jede Analyse von Wiederholungen.
Checkliste zur Schnellbewertung
- Gibt es ein ITSM-Werkzeug, in dem sich alle Tickets befinden? (ja = Stufe 2+)
- Haben mehr als 70 % der Tickets eine spezifische Kategorie, nicht „Sonstiges“? (ja = Stufe 3+)
- Ist das SLA verknüpft und läuft der Cron validiert im CLI-Modus? (ja = Stufe 3+)
- Werden Kennzahlen erhoben und in einem festen Meeting überprüft? (ja = Stufe 4+)
- Entstehen Entscheidungen aus Daten, nicht aus Eindrücken? (ja = Stufe 4+)
- Gibt es ein aktives Problemmanagement, das Wiederholungen reduziert? (ja = Stufe 5)
Entwicklungsplan: eine Stufe nach der anderen
Versuchen Sie nicht, Etappen zu überspringen – jede Stufe baut auf der vorherigen auf. Hat die Diagnose eine niedrige Kategorisierung gezeigt, ist der nächste Schritt nicht der Kauf von KI; es geht darum, den Kategorienbaum auf das zu reduzieren, was das Team tatsächlich nutzt (in der Praxis decken 15 bis 25 Kategorien die meisten mittelgroßen Betriebe ab), und die Triage zu schulen. Erst wenn sich die Kategorisierung stabilisiert hat, ergibt Problemmanagement Sinn, weil Sie Störungen endlich nach Ursache gruppieren können. Stehen Sie auf Stufe 1–2, beginnen Sie mit der Einführung von GLPI und der Grundkonfiguration, bevor Sie irgendetwas automatisieren.
Nach unserer Erfahrung im Betrieb kommt der schnellste Reifegewinn nicht von einer neuen Funktion, sondern davon, das Vorhandene zu bereinigen: Cron im CLI-Modus, schlanke Kategorien und ein SLA, das mit 100 % der Tickettypen verknüpft ist. Diese drei Anpassungen bringen den Betrieb in wenigen Wochen von Stufe 2 auf Stufe 3, ohne zusätzliche Lizenzkosten.
Wenn Sie eine Reifegraddiagnose mit diesen Kennzahlen aus Ihrer eigenen Umgebung möchten: NexTool übernimmt Bewertung und Betrieb von GLPI für B2B-Betriebe – von der Grundkonfiguration bis zur optimierten Stufe.
Geprüft vom Team von NexTool Solutions.