ITSM-Reifegrad: so bewerten und entwickeln Sie Ihren Betrieb

So bewerten Sie den ITSM-Reifegrad Ihres Betriebs mit objektiven Signalen aus GLPI (Diagnose-SQL, Matrix je Stufe und Cron im CLI-Modus) und entwickeln sich Stufe für Stufe weiter, ohne Etappen zu überspringen.

In diesem Artikel7 Abschnitte

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:

StufeBeobachtbares Signal in GLPINächste technische MaßnahmeZielkennzahl
1 – Ad hocKein Werkzeug oder Tickets ohne Kategorie/SLAGLPI einführen, Einheit und Profile anlegen100 % der Tickets im Werkzeug
2 – WiederholbarTickets werden erstellt, aber die Kategorie „Sonstiges“ dominiertSchlanker Kategorienbaum + erstes SLA>70 % kategorisiert
3 – DefiniertKategorien und SLA in Gebrauch; manuelle VerteilungGeschäftsregeln (Zuweisung), WissensdatenbankVerknüpftes SLA >90 %
4 – GesteuertKennzahlen werden erhoben; Cron im CLI-ModusProblem- und Änderungsmanagement, DashboardsErfülltes SLA >90 %
5 – OptimiertEntscheidungen auf Datenbasis; ausgereifte AutomatisierungAnalyse von Wiederholungen, Integration mit dem GeschäftJä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

  1. Gibt es ein ITSM-Werkzeug, in dem sich alle Tickets befinden? (ja = Stufe 2+)
  2. Haben mehr als 70 % der Tickets eine spezifische Kategorie, nicht „Sonstiges“? (ja = Stufe 3+)
  3. Ist das SLA verknüpft und läuft der Cron validiert im CLI-Modus? (ja = Stufe 3+)
  4. Werden Kennzahlen erhoben und in einem festen Meeting überprüft? (ja = Stufe 4+)
  5. Entstehen Entscheidungen aus Daten, nicht aus Eindrücken? (ja = Stufe 4+)
  6. 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.

Häufig gestellte Fragen

Unter Einrichtung > Automatische Aktionen zeigt die Spalte für den Ausführungsmodus für jede Aufgabe CLI oder GLPI an. Prüfen Sie auch das Datum der letzten Ausführung: Rückt es nur vor, wenn jemand das System aufruft, läuft der Cron im Webmodus. Richtig ist, front/cron.php im Cron des Betriebssystems einzuplanen und jede kritische Aktion auf CLI zu setzen.

Über 70 % der Tickets in spezifischen Kategorien (nicht "Sonstiges" oder leer) ist das Minimum, um Problemmanagement zu tragen. Darunter werden die Gruppierungen nach Ursache dürftig, und die Analysen von Wiederholungen verlieren an Verlässlichkeit.

Die Dashboards helfen, hängen aber von gut gepflegten Daten und einem verlässlichen Cron ab. Ist die Kategorisierung niedrig oder läuft der Cron im Webmodus, zeigt das Dashboard optimistische Zahlen. Deshalb lohnt sich der Abgleich mit lesenden SQL-Abfragen direkt in der Datenbank.

Nein. Beginnen Sie mit den Praktiken, die die dringendsten Probleme lösen (Störungen und Anfragen), mit schlanken Kategorien und verknüpftem SLA. Problem- und Änderungsmanagement kommen später, wenn die Basisdaten bereits verlässlich sind.

Neue Funktionen (Automatisierung, KI) zu kaufen, bevor die Grundlagen bereinigt sind. Ohne konsistente Kategorisierung, verknüpftes SLA und Cron im CLI-Modus erbt jede fortgeschrittene Schicht schlechte Daten und erzeugt Berichte, die den tatsächlichen Betrieb nicht widerspiegeln.

Brauchen Sie Hilfe?