Skip to main content

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.

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

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

Back to top