43.676 ServiceNow Tickets analysiert

Wer IT-Automatisierung nach Bauchgefühl plant, beginnt oft beim sichtbarsten Problem. Ticketdaten zeigen etwas anderes: welche Fälle tatsächlich häufig sind, wo Routine lange wartet, wie oft Vorgänge zwischen Teams wandern und welches Wissen im Alltag fehlt.

Für einen europäischen Fertigungskonzern hat nara eine anonymisierte ServiceNow Historie aus dem Zeitraum 2020 bis 2026 analysiert. Die Grundlage waren 43.676 Incidents aus sechs Jahren, einschließlich 194.000 Kommentaren und 33.700 Anhängen. Ziel war keine allgemeine Automatisierungsquote, sondern eine belastbare Reihenfolge für konkrete Support-Prozesse.

Die vollständige öffentliche Zusammenfassung steht in der Case Study zum Ticketarchiv. Dieser Artikel ordnet die Ergebnisse ein und zeigt, wie sich die Methode auf andere Ticketbestände übertragen lässt.

Die wichtigsten Ergebnisse

Aus dem Bestand wurden 51 wiederkehrende Use Cases abgeleitet. Die zehn häufigsten standen zusammen für 48% des gesamten Ticketvolumens. Die mediane Lösungszeit über den analysierten Bestand lag bei 1,24 Tagen. Rund 20% der Tickets wurden zweimal oder öfter neu zugewiesen.

Vier Zahlen fassen den Befund zusammen:

43.676 Incidents: die analysierte ServiceNow Historie.
51 wiederkehrende Use Cases: aus ähnlichen Anliegen und Abläufen gruppierte Muster.
48% des Volumens: Anteil der zehn häufigsten Use Cases am Gesamtbestand.
Rund jedes fünfte Ticket: zweimal oder öfter neu zugewiesen.

Diese Werte beschreiben genau diesen anonymisierten Bestand. Sie sind kein Benchmark für jedes Unternehmen und kein Beleg dafür, dass ein bestimmter Anteil vollautomatisch lösbar ist.

Welche Muster oben auf der Roadmap landeten

Die Analyse machte mehrere bekannte Service-Desk-Fälle sichtbar: Passwortzurücksetzungen, SAP-Zugriffe und Berechtigungen, Eintritte und Austritte sowie Freigaben für Verzeichnisrechte. Auch VPN, Drucker und Standardsoftware gehörten zu den wiederkehrenden Themen im analysierten Bestand.

Passwort-Resets

Passwortzurücksetzungen hatten eine mediane Laufzeit von anderthalb Stunden. Die eigentliche technische Aktion ist oft kurz, doch Identitätsprüfung, Rückfragen, Warteschlange und Dokumentation verlängern den Fall.

Ein kontrollierter Agenten-Ablauf kann den Nutzer verifizieren, ein freigegebenes Reset-Tool aufrufen, das Ergebnis bestätigen und das Ticket dokumentieren. Geschützte Konten, unklare Identität oder technische Fehler werden an Menschen übergeben.

Zugriffe und Berechtigungen

Bei SAP-Zugriffen und Verzeichnisrechten ist die Tool-Ausführung nur ein Teil des Prozesses. Zuerst müssen Rolle, benötigter Zugriff, Begründung und zuständige Freigabe vollständig sein.

Der Agent kann diese Informationen sammeln, Regeln prüfen und die Anfrage entscheidungsfertig vorlegen. Die Berechtigungsentscheidung bleibt bei einem verantwortlichen Menschen. Erst nach Freigabe wird die Änderung über ein erlaubtes Tool ausgeführt.

Joiner-Mover-Leaver

Eintritte, Wechsel und Austritte verbinden Konten, Rechte, Geräte, Software und mehrere Verantwortliche. Genau deshalb profitieren sie von einem sichtbaren Ablauf: Was wurde erledigt, welche Freigabe fehlt und welcher Schritt hängt von einem anderen ab?

Automatisierung hilft hier bei Koordination und Nachweis. Personalentscheidungen und besondere Rechte bleiben außerhalb der Zuständigkeit des Agenten.

VPN, Drucker und Standardsoftware

Diese Themen eignen sich nicht pauschal, sondern dann, wenn bekannte Fehlerbilder, definierte Prüfungen und sichere Tools vorhanden sind. Ein Agent kann etwa Status, Dienste oder Zertifikate prüfen und Ergebnisse dokumentieren. Unbekannte Konfigurationen und Hardwaredefekte brauchen weiterhin das Team.

Eine praktische Einordnung dieser Kandidaten liefert unser Artikel über zehn frühe Service-Desk-Prozesse.

Lange Laufzeit ist nicht dasselbe wie lange Arbeit

Die mediane Lösungszeit von 1,24 Tagen sagt nicht, dass an jedem Ticket mehr als einen Tag aktiv gearbeitet wurde. Ein Fall kann in einer Warteschlange liegen, auf Angaben warten oder mehrfach neu zugewiesen werden. Gerade die Kombination aus Laufzeit und Übergaben hilft deshalb bei der Priorisierung.

Ein häufiger, regelbasierter Fall mit kurzer eigentlicher Bearbeitung, aber langer Wartezeit kann ein guter Kandidat sein. Ein seltener Fall mit derselben Laufzeit und hoher fachlicher Unsicherheit möglicherweise nicht.

Für die Bewertung sollten mindestens diese Signale zusammen betrachtet werden:

Häufigkeit des Musters.
Mediane und stark abweichende Laufzeiten.
Zahl der Neuzuweisungen und beteiligten Teams.
Vollständigkeit der Eingangsdaten.
Vorhandenes und aktuelles Lösungswissen.
Benötigte Systeme, Tools und Freigaben.
Klarheit des Erfolgskriteriums.

Die Wissensbasis gegen echte Nachfrage prüfen

Zur Analyse gehörte auch ein Abgleich von 85 vorhandenen Wissensartikeln mit dem tatsächlichen Ticketaufkommen. Für die größten Lücken erzeugte nara 20 Artikelentwürfe zur Prüfung und Freigabe durch das Team.

Das ist ein wichtiger Perspektivwechsel. Eine Wissensbasis ist nicht vollständig, nur weil sie viele Dokumente enthält. Entscheidend ist, ob sie die häufigen realen Fragen und Fehlerbilder abdeckt. Ticketdaten zeigen, welche Themen oft auftreten, aber schlecht oder gar nicht dokumentiert sind.

nara Memory strukturiert Wissen als Schemas, Objekte und Beziehungen und macht es für Agenten während eines Falls nutzbar. Neue Artikelentwürfe gelten nicht automatisch als korrekt. Das Team prüft und genehmigt sie, bevor sie Teil der Wissensbasis werden. Mehr dazu steht auf der Seite zu operativem Wissen.

Von Rohdaten zu einer Automatisierungsroadmap

Eine belastbare Auswertung lässt sich in sechs Schritte zerlegen:

1. Datenbestand festlegen

Definieren Sie Zeitraum, Tickettypen, Sprachen, Mandanten und ausgeschlossene Daten. Sonst vermischen sich nicht vergleichbare Fälle.

2. Inhalt erschließen

Betrachten Sie nicht nur Kategorie und Kurztext. Kommentare und Anhänge enthalten häufig Diagnose, Rückfragen und tatsächlichen Lösungsweg. Im analysierten Bestand gehörten deshalb 194.000 Kommentare und 33.700 Anhänge zur Grundlage.

3. Wiederkehrende Muster gruppieren

Ähnliche Formulierungen sind nicht automatisch derselbe Prozess. Gruppiert werden sollten Fälle mit vergleichbarem Ziel, benötigtem Wissen, Systemzugriff und Abschlusskriterium.

4. Volumen und Reibung verbinden

Häufigkeit allein priorisiert möglicherweise sehr einfache Lesefragen. Laufzeit und Neuzuweisungen zeigen zusätzlich, wo ein standardisierter Ablauf Wartezeit und Übergaben reduzieren könnte.

5. Umsetzbarkeit und Risiko prüfen

Für jeden Kandidaten müssen Wissen, Integrationen, Tool-Rechte, Freigaben und Eskalationswege vorhanden sein. Die nara Plattform für KI-Automatisierung verbindet diese Bausteine; welche Aktionen im konkreten Stack möglich sind, wird einzeln validiert.

6. Mit einem begrenzten Ablauf starten

Ein Pilot sollte klare Eingaben, erlaubte Tools, Erfolgskriterien und Stoppsignale haben. Erst die Ergebnisse im echten Betrieb zeigen, ob der Ablauf erweitert werden sollte.

Was die Analyse nicht behauptet

Die 48% Volumen der zehn häufigsten Use Cases sind keine 48% Automatisierungsquote. Die 1,24 Tage mediane Lösungszeit sind keine 1,24 Tage aktive Arbeitszeit. Die 20 Artikelentwürfe sind keine automatisch freigegebenen Wissensartikel. Und die Roadmap ist noch kein Nachweis realisierter Einsparung.

Diese Grenzen machen die Analyse nicht schwächer, sondern nützlicher. Sie trennt beobachtete Daten von der anschließenden technischen und organisatorischen Validierung.

Tickets als Ausgangspunkt, nicht als Endpunkt

Eine Ticket-Historie zeigt, wo Nachfrage entsteht und Reibung wiederkehrt. Der nächste Schritt ist ein kontrollierter Prozess, der Wissen, Tools, Freigaben und Menschen zusammenbringt. Auf der Seite zur IT Service Desk Automation sehen Sie, wie nara solche Fälle von der Triage bis zur Ticket-Dokumentation abbildet.

Wenn Sie die Muster in Ihrem eigenen Ticketbestand untersuchen möchten, können Sie eine Demo und Ticketanalyse anfragen. Wir bewerten die Daten in Ihrem Kontext, statt fremde Quoten auf Ihren Service Desk zu übertragen.