3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk

Kurz erklärt 
 Kennzahlen helfen dabei, die Arbeit des Service Desks sichtbar, bewertbar und verbesserbar zu machen. 
 Sie zeigen jedoch nicht automatisch, ob ein Service wirklich gut ist. 
 Entscheidend ist, Kennzahlen richtig zu interpretieren und mit Qualität, Benutzererfahrung und kontinuierlicher Verbesserung zu verbinden. 
 
 
 Warum Kennzahlen wichtig sind 
 Ohne Kennzahlen bleibt die Leistung eines Service Desks schwer bewertbar. 
 Kennzahlen helfen zu erkennen: 
 
 wie viele Kontakte eingehen, 
 welche Themen häufig auftreten, 
 wie schnell reagiert wird, 
 wie schnell gelöst wird, 
 wie zufrieden Benutzer sind, 
 wo Engpässe entstehen, 
 welche Services häufig gestört sind, 
 und wo Verbesserungen notwendig sind. 
 
 Kennzahlen sollen nicht nur kontrollieren. 
 Sie sollen helfen, bessere Entscheidungen zu treffen. 
 
 Kennzahlen sind kein Selbstzweck 
 Eine Kennzahl ist nur dann sinnvoll, wenn klar ist: 
 
 was sie misst, 
 warum sie gemessen wird, 
 wer sie nutzt, 
 welche Entscheidung daraus folgt, 
 und welche Fehlanreize entstehen können. 
 
 Beispiel: 
 Eine sehr kurze Bearbeitungszeit klingt gut. 
 Sie kann aber problematisch sein, wenn Tickets vorschnell geschlossen werden und Benutzer später erneut Kontakt aufnehmen müssen. 
 
 Merke 
 Eine gute Kennzahl unterstützt bessere Servicequalität. 
 Eine schlechte Kennzahl erzeugt falsches Verhalten. 
 
 
 Qualität im Service Desk 
 Qualität bedeutet nicht nur, dass Tickets schnell geschlossen werden. 
 Qualität bedeutet auch: 
 
 Anliegen werden korrekt verstanden, 
 Benutzer erhalten verständliche Rückmeldungen, 
 Tickets sind vollständig dokumentiert, 
 Lösungen sind nachvollziehbar, 
 Eskalationen erfolgen rechtzeitig, 
 Wiedereröffnungen werden vermieden, 
 bekannte Lösungen werden genutzt, 
 und Verbesserungen werden erkannt. 
 
 Ein Service Desk kann viele Tickets bearbeiten und trotzdem schlechte Qualität liefern. 
 
 Quantität und Qualität unterscheiden 
 
 
 
 Quantität 
 Qualität 
 
 
 
 
 Anzahl der Tickets 
 Vollständigkeit der Erfassung 
 
 
 Anzahl geschlossener Vorgänge 
 tatsächliche Lösung aus Benutzersicht 
 
 
 durchschnittliche Bearbeitungszeit 
 Verständlichkeit der Kommunikation 
 
 
 Anzahl Anrufe 
 richtige Klassifizierung 
 
 
 Anzahl Eskalationen 
 sinnvolle Eskalation mit ausreichendem Kontext 
 
 
 
 Beide Perspektiven sind wichtig. 
 Nur Mengenkennzahlen reichen nicht aus. 
 
 Typische Kennzahlen im Service Desk 
 
 
 
 Bereich 
 Mögliche Kennzahl 
 
 
 
 
 Kontaktvolumen 
 Anzahl der Kontakte pro Zeitraum 
 
 
 Kanäle 
 Anteil Portal, Telefon, E-Mail, Chat 
 
 
 Reaktion 
 Zeit bis zur ersten qualifizierten Rückmeldung 
 
 
 Lösung 
 durchschnittliche Lösungszeit 
 
 
 Wiederherstellung 
 Zeit bis zur Wiederherstellung des Service 
 
 
 First Contact Resolution 
 Anteil beim ersten Kontakt gelöster Anliegen 
 
 
 Eskalation 
 Anteil funktional eskalierter Tickets 
 
 
 Qualität 
 Anteil vollständig dokumentierter Tickets 
 
 
 Benutzererfahrung 
 Zufriedenheit nach Kontakt 
 
 
 Backlog 
 Anzahl offener Tickets 
 
 
 Wiedereröffnung 
 Anteil wiedergeöffneter Tickets 
 
 
 Self-Service 
 Anteil selbst gelöster oder automatisierter Anfragen 
 
 
 Knowledge 
 Nutzung und Bewertung von Wissensartikeln 
 
 
 
 Die konkrete Auswahl hängt von Organisation, Services und Zielsetzung ab. 
 
 Kontaktvolumen 
 Das Kontaktvolumen zeigt, wie viele Anfragen, Störungen oder Rückfragen eingehen. 
 Zu betrachten sind: 
 
 Anzahl Kontakte pro Tag, Woche oder Monat, 
 Verteilung nach Kontaktkanal, 
 Spitzenzeiten, 
 häufige Services, 
 häufige Kategorien, 
 wiederkehrende Themen. 
 
 Ein hohes Kontaktvolumen bedeutet nicht automatisch schlechte Leistung. 
 Es kann auch bedeuten: 
 
 neue Services wurden eingeführt, 
 Benutzer kennen den Service Desk besser, 
 Self-Service funktioniert noch nicht, 
 ein wiederkehrendes Problem erzeugt viele Meldungen, 
 oder ein Major Incident führt zu vielen Kontakten. 
 
 
 Kanäle auswerten 
 Kontaktkanäle können unterschiedliche Qualität und Kosten verursachen. 
 Beispiele: 
 
 
 
 Kanal 
 Typische Stärke 
 Typisches Risiko 
 
 
 
 
 Portal 
 strukturierte Erfassung 
 Benutzer finden Service nicht 
 
 
 Telefon 
 schnelle Klärung 
 schlechte Dokumentation möglich 
 
 
 E-Mail 
 einfach zugänglich 
 unstrukturierte Angaben 
 
 
 Chat 
 schnelle Kurzklärung 
 komplexe Fälle schwer dokumentierbar 
 
 
 Self-Service 
 sofortige Hilfe 
 ungeeignet bei komplexen Incidents 
 
 
 
 Die Organisation sollte prüfen, welche Kanäle für welche Anliegen geeignet sind. 
 
 Zeit bis zur ersten qualifizierten Rückmeldung 
 Diese Kennzahl misst, wie schnell der Benutzer eine verwertbare Rückmeldung erhält. 
 Eine qualifizierte Rückmeldung ist mehr als: 
 
 Ticket wurde erstellt. 
 
 Besser: 
 
 Wir haben den Incident aufgenommen. Betroffen ist der VPN-Zugriff. Erste Prüfungen laufen. Die nächste Rückmeldung erfolgt spätestens um 14:00 Uhr. 
 
 Diese Kennzahl hilft, gefühlte Untätigkeit zu vermeiden. 
 
 Lösungszeit und Wiederherstellungszeit unterscheiden 
 
 
 
 Kennzahl 
 Bedeutung 
 
 
 
 
 Lösungszeit 
 Zeit bis zur Bearbeitung oder zum Abschluss eines Vorgangs 
 
 
 Wiederherstellungszeit 
 Zeit bis der betroffene Service wieder nutzbar ist 
 
 
 Bearbeitungszeit 
 aktive Arbeitszeit am Vorgang 
 
 
 Wartezeit 
 Zeit, in der auf Benutzer, Lieferanten, Genehmigung oder andere Abhängigkeiten gewartet wird 
 
 
 
 Diese Werte sollten nicht verwechselt werden. 
 Ein Incident kann technisch wiederhergestellt sein, obwohl die endgültige Ursache noch im Problem Management untersucht wird. 
 
 First Contact Resolution 
 Die First Contact Resolution (FCR) beschreibt den Anteil der Anliegen, die beim ersten Kontakt ausreichend gelöst werden. 
 Eine hohe FCR kann entstehen durch: 
 
 gute Knowledge Base, 
 geschulte Service-Desk-Mitarbeiter, 
 klare Standardlösungen, 
 ausreichende Berechtigungen, 
 sinnvolle Automatisierung, 
 gute Self-Service-Angebote. 
 
 Aber Vorsicht: 
 Eine hohe FCR ist nicht automatisch gut, wenn Tickets voreilig geschlossen werden. 
 Zu prüfen ist deshalb auch: 
 
 Wiedereröffnungsquote, 
 Benutzerzufriedenheit, 
 Qualität der Dokumentation, 
 tatsächliche Lösung aus Benutzersicht. 
 
 
 SLA-Erfüllung 
 SLA-Erfüllung zeigt, ob vereinbarte Serviceziele eingehalten wurden. 
 Mögliche SLA-Ziele: 
 
 Reaktionszeit, 
 Wiederherstellungszeit, 
 Erfüllungszeit für Service Requests, 
 Verfügbarkeit, 
 Statusintervalle, 
 Bearbeitung innerhalb vereinbarter Servicezeiten. 
 
 Wichtig: 
 SLA-Erfüllung sollte nicht nur formal betrachtet werden. 
 Beispiel: 
 Ein Ticket wurde innerhalb der Zielzeit geschlossen. 
 Wenn der Benutzer danach erneut melden muss, war die Serviceerfahrung trotzdem schlecht. 
 
 Backlog 
 Der Backlog zeigt offene Arbeit. 
 Zu betrachten sind: 
 
 Anzahl offener Tickets, 
 Alter offener Tickets, 
 offene Tickets nach Priorität, 
 offene Tickets nach Team, 
 blockierte Tickets, 
 Tickets mit überschrittener Zielzeit, 
 wiederholt verschobene Tickets. 
 
 Ein Backlog ist nicht automatisch schlecht. 
 Problematisch wird er, wenn: 
 
 Vorgänge lange unbeachtet bleiben, 
 Prioritäten nicht mehr gesteuert werden, 
 Benutzer keine Rückmeldung erhalten, 
 oder alte Tickets immer wieder verdrängt werden. 
 
 
 Wiedereröffnungsquote 
 Die Wiedereröffnungsquote zeigt, wie oft geschlossene Tickets erneut geöffnet werden. 
 Mögliche Ursachen: 
 
 Problem wurde nicht vollständig gelöst, 
 Benutzer hat Lösung nicht verstanden, 
 Abschluss erfolgte zu früh, 
 Workaround wurde als Lösung behandelt, 
 Ursache bestand weiterhin, 
 Kommunikation war unklar, 
 oder ein verwandter Incident wurde falsch zugeordnet. 
 
 Eine hohe Wiedereröffnungsquote kann auf Qualitätsprobleme hinweisen. 
 
 Eskalationsquote 
 Die Eskalationsquote zeigt, wie häufig Tickets an andere Teams weitergegeben werden. 
 Eine hohe Eskalationsquote kann bedeuten: 
 
 Service Desk hat zu wenig Wissen, 
 Knowledge Base ist unzureichend, 
 Berechtigungen fehlen, 
 Kategorien sind unklar, 
 Services sind komplex, 
 oder Tickets werden korrekt an Spezialisten gegeben. 
 
 Eine niedrige Eskalationsquote ist nicht automatisch gut. 
 Sie kann auch bedeuten, dass notwendige Eskalationen zu spät erfolgen. 
 
 Ticketqualität messen 
 Ticketqualität ist wichtig für Bearbeitung, Übergabe und spätere Auswertung. 
 Zu prüfen ist: 
 
 Ist der betroffene Service erfasst? 
 Ist das Symptom verständlich beschrieben? 
 Sind Auswirkungen dokumentiert? 
 Sind Priorität und Begründung nachvollziehbar? 
 Sind bisherige Maßnahmen dokumentiert? 
 Sind relevante Anhänge vorhanden? 
 Ist der Abschluss nachvollziehbar? 
 Wurde ein Workaround dokumentiert? 
 Ist eine Folgeaktivität notwendig? 
 
 Eine gute Ticketdokumentation spart spätere Arbeitszeit. 
 
 Benutzerzufriedenheit 
 Benutzerzufriedenheit kann gemessen werden durch: 
 
 kurze Umfragen nach Ticketabschluss, 
 Feedback im Portal, 
 Service Reviews, 
 Beschwerden, 
 Lob, 
 qualitative Interviews, 
 wiederkehrende Rückmeldungen. 
 
 Wichtig ist, nicht nur eine Zahl zu betrachten. 
 Eine Bewertung sollte ergänzt werden durch: 
 
 Kommentare, 
 Ticketinhalt, 
 Servicekontext, 
 tatsächliche Lösung, 
 und Kommunikationsqualität. 
 
 
 Customer Satisfaction und Experience 
 Customer Satisfaction (CSAT) misst häufig die Zufriedenheit mit einem konkreten Kontakt. 
 Experience betrachtet breiter, wie Benutzer den Service insgesamt erleben. 
 Beispiel: 
 Ein einzelner Service-Desk-Kontakt war freundlich und schnell. 
 Trotzdem kann die Gesamterfahrung schlecht sein, wenn: 
 
 das Portal unübersichtlich ist, 
 dieselbe Störung häufig wiederkehrt, 
 Genehmigungen lange dauern, 
 oder Statusinformationen fehlen. 
 
 
 Self-Service-Kennzahlen 
 Mögliche Kennzahlen: 
 
 Anzahl Portalaufrufe, 
 Anteil über Portal erstellter Tickets, 
 Anteil erfolgreich selbst gelöster Anliegen, 
 Nutzung bestimmter Knowledge-Artikel, 
 Abbruchquote in Formularen, 
 Anzahl automatisiert erfüllter Requests, 
 Zufriedenheit mit Self-Service, 
 Rückgang bestimmter Standardkontakte. 
 
 Nicht nur Nutzung zählt. 
 Wichtig ist auch, ob Benutzer tatsächlich zum Ziel kommen. 
 
 Knowledge-Management-Kennzahlen 
 Mögliche Kennzahlen: 
 
 Artikelaufrufe, 
 Suchanfragen ohne Treffer, 
 hilfreiche Bewertungen, 
 veraltete Artikel, 
 neu erstellte Artikel, 
 aktualisierte Artikel, 
 Artikel, die zur Lösung beigetragen haben, 
 wiederkehrende Incidents ohne vorhandenen Artikel. 
 
 Problematisch wäre, nur die Anzahl der Artikel zu messen. 
 Viele schlechte Artikel helfen weniger als wenige gute. 
 
 Automatisierungskennzahlen 
 Mögliche Kennzahlen: 
 
 Anzahl automatisierter Abläufe, 
 Anteil erfolgreich automatisierter Requests, 
 Fehlerquote, 
 manuelle Nacharbeit, 
 durchschnittliche Durchlaufzeit, 
 eingesparte Bearbeitungsschritte, 
 fehlgeschlagene Automatisierungen, 
 Rollbacks, 
 Sicherheitsereignisse durch Automatisierung. 
 
 Automatisierung muss nicht nur schnell sein. 
 Sie muss sicher, nachvollziehbar und zuverlässig sein. 
 
 Trendanalyse 
 Kennzahlen werden besonders wertvoll, wenn sie über längere Zeit betrachtet werden. 
 Beispiele: 
 
 VPN-Incidents steigen seit einem Client-Update. 
 Passwort-Reset-Anfragen sinken nach Einführung von Self-Service. 
 Drucker-Incidents häufen sich an einem Standort. 
 Wiedereröffnungen steigen in einer bestimmten Kategorie. 
 Backlog wächst regelmäßig zum Monatsende. 
 Eskalationen an ein Team nehmen stark zu. 
 
 Trends helfen, Ursachen und Verbesserungsmöglichkeiten zu erkennen. 
 
 Qualitätssicherung im Service Desk 
 Qualität kann geprüft werden durch: 
 
 Ticket-Stichproben, 
 Gesprächsauswertung, 
 Review von Eskalationen, 
 Prüfung von Abschlussnotizen, 
 Bewertung von Knowledge-Nutzung, 
 Analyse wiedereröffneter Tickets, 
 Feedback der Fachgruppen, 
 Feedback der Benutzer. 
 
 Ziel ist nicht Bestrafung. 
 Ziel ist Lernen und Verbesserung. 
 
 Service Reviews 
 In Service Reviews werden Ergebnisse regelmäßig betrachtet. 
 Mögliche Inhalte: 
 
 SLA-Erfüllung, 
 häufige Incidents, 
 Benutzerfeedback, 
 offene Risiken, 
 Major Incidents, 
 Verbesserungsmaßnahmen, 
 Trends, 
 Qualität der Kommunikation, 
 Leistung von Lieferanten, 
 Stand des Backlogs. 
 
 Service Reviews verbinden operative Daten mit geschäftlicher Bewertung. 
 
 Dashboards 
 Dashboards helfen, wichtige Informationen schnell sichtbar zu machen. 
 Ein gutes Dashboard zeigt: 
 
 aktuelle Lage, 
 Trends, 
 Engpässe, 
 Zielverletzungen, 
 Risiken, 
 und Verbesserungsbedarf. 
 
 Ein Dashboard sollte nicht mit Kennzahlen überladen werden. 
 Besser wenige relevante Kennzahlen als viele unklare Zahlen. 
 
 Ampellogik vorsichtig verwenden 
 Ampeln sind einfach verständlich. 
 Beispiel: 
 
 
 
 Farbe 
 Bedeutung 
 
 
 
 
 Grün 
 Ziel erreicht 
 
 
 Gelb 
 Ziel gefährdet 
 
 
 Rot 
 Ziel verletzt oder Risiko hoch 
 
 
 
 Risiko: 
 Eine Ampel kann komplexe Situationen zu stark vereinfachen. 
 Deshalb sollten kritische Kennzahlen immer mit Kontext erklärt werden. 
 
 Fehlanreize vermeiden 
 Kennzahlen können unerwünschtes Verhalten erzeugen. 
 Beispiele: 
 
 
 
 Kennzahl 
 Möglicher Fehlanreiz 
 
 
 
 
 viele geschlossene Tickets 
 Tickets werden zu früh geschlossen 
 
 
 kurze Lösungszeit 
 komplexe Fälle werden gemieden 
 
 
 niedrige Eskalationsquote 
 Eskalation erfolgt zu spät 
 
 
 hohe FCR 
 Fälle werden oberflächlich gelöst 
 
 
 hohe SLA-Erfüllung 
 Prioritäten werden manipuliert 
 
 
 viele Knowledge-Artikel 
 Qualität wird durch Menge ersetzt 
 
 
 viele Automatisierungen 
 Risiken werden unterschätzt 
 
 
 
 Kennzahlen müssen deshalb regelmäßig kritisch überprüft werden. 
 
 Kennzahlen gemeinsam interpretieren 
 Einzelne Kennzahlen können täuschen. 
 Beispiel: 
 
 Lösungszeit sinkt, 
 aber Wiedereröffnungsquote steigt, 
 und Benutzerzufriedenheit sinkt. 
 
 Dann ist die scheinbare Verbesserung wahrscheinlich keine echte Qualitätsverbesserung. 
 Besser ist eine kombinierte Betrachtung. 
 Beispiel: 
 
 Reaktionszeit, 
 Lösungszeit, 
 Wiedereröffnungen, 
 Benutzerzufriedenheit, 
 Dokumentationsqualität, 
 und SLA-Erfüllung. 
 
 
 Continual Improvement im Service Desk 
 Continual Improvement bedeutet, aus Daten, Feedback und Erfahrungen konkrete Verbesserungen abzuleiten. 
 Möglicher Ablauf: 
 Kennzahl oder Feedback erkennen
 ↓
Ursache oder Muster untersuchen
 ↓
Verbesserungsidee erfassen
 ↓
Nutzen und Aufwand bewerten
 ↓
Maßnahme umsetzen
 ↓
Wirkung messen
 ↓
Standard oder Wissen aktualisieren
 
 Verbesserung ist damit ein dauerhafter Bestandteil des Service Desk. 
 
 Improvement Register 
 Verbesserungsideen sollten nicht verloren gehen. 
 Ein Improvement Register kann enthalten: 
 
 Verbesserungsidee, 
 betroffener Service, 
 Auslöser, 
 erwarteter Nutzen, 
 Aufwand, 
 Risiko, 
 Priorität, 
 Verantwortlicher, 
 Status, 
 Ergebnis, 
 Lessons Learned. 
 
 Das Werkzeug ist nicht entscheidend. 
 Wichtig ist, dass Verbesserungen nachvollziehbar erfasst und verfolgt werden. 
 
 Beispiele für Verbesserungen 
 
 
 
 Beobachtung 
 mögliche Verbesserung 
 
 
 
 
 viele Passwort-Tickets 
 Self-Service-Passwort-Reset einführen 
 
 
 häufige VPN-Probleme 
 Knowledge-Artikel und Clientprüfung verbessern 
 
 
 viele Rückfragen bei Requests 
 Formulare überarbeiten 
 
 
 hohe Wiedereröffnungsquote 
 Abschlussprüfung verbessern 
 
 
 viele Eskalationen an Netzwerkteam 
 Service Desk mit Runbook unterstützen 
 
 
 lange Wartezeiten auf Genehmigungen 
 Genehmigungsworkflow vereinfachen 
 
 
 wiederkehrende Drucker-Incidents 
 Problem Management einbinden 
 
 
 schlechte Suchtreffer 
 Knowledge Base neu strukturieren 
 
 
 
 
 Qualitative Informationen berücksichtigen 
 Nicht alles Wichtige ist direkt messbar. 
 Wertvoll sind auch: 
 
 Kommentare von Benutzern, 
 Erfahrungen des Service Desks, 
 Rückmeldungen von Fachgruppen, 
 Beobachtungen aus Major Incident Reviews, 
 Hinweise aus Service Reviews, 
 Beschwerden, 
 und wiederkehrende Missverständnisse. 
 
 Zahlen zeigen oft, wo man suchen sollte. 
 Die Ursachen versteht man häufig erst durch qualitative Informationen. 
 
 Typische Fehler 
 Fehler 1 
 Es werden viele Kennzahlen gesammelt, aber keine Entscheidungen daraus abgeleitet. 
 
 Fehler 2 
 Nur Geschwindigkeit wird gemessen, nicht Qualität. 
 
 Fehler 3 
 Tickets werden schnell geschlossen, obwohl der Benutzer nicht arbeitsfähig ist. 
 
 Fehler 4 
 SLA-Erfüllung wird wichtiger genommen als tatsächliche Serviceerfahrung. 
 
 Fehler 5 
 Wiedereröffnungen werden ignoriert. 
 
 Fehler 6 
 Kennzahlen werden ohne Kontext verglichen. 
 
 Fehler 7 
 Teams werden für Zahlen verantwortlich gemacht, die sie nicht beeinflussen können. 
 
 Fehler 8 
 Benutzerfeedback wird gesammelt, aber nicht ausgewertet. 
 
 Fehler 9 
 Dashboards zeigen zu viele Werte ohne klare Aussage. 
 
 Fehler 10 
 Verbesserungsideen werden nicht verfolgt. 
 
 Fehler 11 
 Automatisierungserfolg wird nur an Geschwindigkeit gemessen. 
 
 Fehler 12 
 Knowledge Management wird nur nach Anzahl der Artikel bewertet. 
 
 Praxisbeispiel: Wiedereröffnete Tickets 
 Beobachtung 
 Die Lösungszeit im Service Desk ist gesunken. 
 Gleichzeitig steigt die Wiedereröffnungsquote. 
 Analyse 
 Viele Tickets werden geschlossen, nachdem eine Standardantwort versendet wurde. 
 Benutzer bestätigen jedoch nicht, dass das Problem gelöst ist. 
 Verbesserung 
 
 Abschlusskriterien definieren, 
 Benutzer-Outcome prüfen, 
 Abschlussnotiz verbessern, 
 Knowledge-Artikel überarbeiten, 
 Stichproben einführen. 
 
 Erfolgskontrolle 
 Nach zwei Monaten sinkt die Wiedereröffnungsquote. 
 Die Benutzerzufriedenheit steigt. 
 
 Praxisbeispiel: Viele VPN-Incidents 
 Beobachtung 
 VPN-Incidents steigen nach einem Client-Update stark an. 
 Analyse 
 Mehrere Tickets enthalten ähnliche Symptome. 
 Ein Teil der Benutzer nutzt eine veraltete Konfiguration. 
 Verbesserung 
 
 Known Error dokumentieren, 
 Knowledge-Artikel erstellen, 
 Clientprüfung automatisieren, 
 Self-Service-Hinweis im Portal ergänzen, 
 Problem Management einbinden. 
 
 Erfolgskontrolle 
 VPN-Tickets gehen deutlich zurück. 
 Der Service Desk kann verbleibende Fälle schneller lösen. 
 
 Praxisbeispiel: Serviceportal wird kaum genutzt 
 Beobachtung 
 Die meisten Anfragen kommen weiterhin per E-Mail. 
 Analyse 
 Benutzer finden die richtigen Services im Portal nicht. 
 Formulare enthalten unklare technische Begriffe. 
 Verbesserung 
 
 Kategorien vereinfachen, 
 Suchbegriffe ergänzen, 
 Formulare kürzen, 
 verständliche Beschreibungen verwenden, 
 Benutzerkommunikation verbessern. 
 
 Erfolgskontrolle 
 Portalnutzung steigt. 
 Rückfragen pro Request sinken. 
 
 Checkliste Kennzahlen 
 
 Zweck der Kennzahl ist klar 
 Datenquelle ist bekannt 
 Berechnung ist nachvollziehbar 
 Zielwert ist definiert 
 Fehlanreize wurden geprüft 
 Kennzahl wird regelmäßig bewertet 
 Maßnahmen werden daraus abgeleitet 
 Qualität wird mit betrachtet 
 Benutzererfahrung wird berücksichtigt 
 Kennzahl wird bei Bedarf angepasst 
 
 
 Checkliste Ticketqualität 
 
 betroffener Service erfasst 
 Symptom verständlich beschrieben 
 Auswirkung dokumentiert 
 Priorität begründet 
 Maßnahmen nachvollziehbar dokumentiert 
 Eskalationen enthalten genug Kontext 
 Workaround dokumentiert 
 Lösung oder Ergebnis klar beschrieben 
 Benutzer-Outcome geprüft 
 Folgeaktivitäten verknüpft 
 
 
 Checkliste Continual Improvement 
 
 Trends und Muster werden erkannt 
 Benutzerfeedback wird ausgewertet 
 Verbesserungsideen werden erfasst 
 Nutzen und Aufwand werden bewertet 
 Verantwortliche sind benannt 
 Maßnahmen werden umgesetzt 
 Wirkung wird gemessen 
 Knowledge Base wird aktualisiert 
 Runbooks werden angepasst 
 Ergebnisse werden kommuniziert 
 
 
 Bedeutung für Fachinformatiker für Systemintegration 
 Fachinformatiker liefern wichtige Daten für Kennzahlen und Verbesserungen. 
 Sie dokumentieren: 
 
 Symptome, 
 technische Ursachen, 
 durchgeführte Maßnahmen, 
 Workarounds, 
 betroffene Komponenten, 
 Serviceabhängigkeiten, 
 und wiederkehrende Muster. 
 
 Dadurch können spätere Auswertungen überhaupt erst sinnvoll durchgeführt werden. 
 Gute technische Arbeit endet nicht mit der Reparatur. 
 Sie schafft auch verwertbares Wissen für bessere Services. 
 
 Zusammenfassung 
 
 Service-Desk-Arbeit erfassen 
↓ 
sinnvolle Kennzahlen auswählen 
↓ 
Qualität und Benutzererfahrung berücksichtigen 
↓ 
Trends und Muster erkennen 
↓ 
Verbesserungen ableiten 
↓ 
Maßnahmen umsetzen 
↓ 
Wirkung messen 
↓ 
Wissen, Prozesse und Automatisierung verbessern 
 
 
 Merksätze 
 
 Nicht alles, was messbar ist, ist automatisch wichtig. 
 
 
 Geschwindigkeit ohne Qualität ist keine gute Serviceleistung. 
 
 
 Eine Kennzahl braucht immer Kontext. 
 
 
 Benutzerzufriedenheit und Serviceergebnis zählen genauso wie Ticketzahlen. 
 
 
 Gute Dokumentation macht Verbesserung erst möglich. 
 
 
 Continual Improvement beginnt oft mit sauber erfassten Tickets. 
 
 
 Verwandte Seiten 
 
 3.1 Der Service Desk als zentraler Kontaktpunkt 
 3.4 Tickets vollständig erfassen und kategorisieren 
 3.5 Auswirkungen, Dringlichkeit und Priorität 
 3.6 Erstdiagnose, Lösung und funktionale Eskalation 
 3.8 Self-Service, Wissensnutzung und Automatisierung 
 Service Level Management 
 Knowledge Management 
 Continual Improvement 
 Measurement and Reporting 
 
 
 Quellen und Versionsstand 
 Offizielle Grundlagen 
 
 PeopleCert – ITIL Practice Guide: Service Desk 
 PeopleCert – ITIL Practice Guide: Incident Management 
 PeopleCert – ITIL Practice Guide: Knowledge Management 
 PeopleCert – ITIL Practice Guide: Measurement and Reporting 
 PeopleCert – ITIL Practice Guide: Continual Improvement 
 ITIL Foundation – Version 5 
 
 Einordnung 
 Die dargestellten: 
 
 Kennzahlen, 
 Qualitätskriterien, 
 Dashboard-Beispiele, 
 Checklisten, 
 Praxisbeispiele, 
 und Verbesserungsansätze 
 
 sind herstellerneutrale Praxisempfehlungen. 
 ITIL schreibt keine universelle: 
 
 KPI-Liste, 
 Zielquote, 
 Dashboard-Struktur, 
 CSAT-Methode, 
 Ticketqualitätsprüfung, 
 oder Verbesserungsmatrix 
 
 für alle Organisationen vor. 
 Die konkrete Ausgestaltung muss an: 
 
 Services, 
 Service Levels, 
 Benutzergruppen, 
 Organisation, 
 Supportmodell, 
 Werkzeuge, 
 Datenqualität, 
 und geschäftliche Ziele 
 
 angepasst werden. 
 Behandelter Framework-Stand: ITIL Version 5 
 Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance 
 Fachlicher Stand: August 2026