# 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