8.3 Kennzahlen, Messmethoden und Reporting

Kurz erklärt

Kennzahlen, Messmethoden und Reporting machen Servicequalität sichtbar.

Entscheidend ist nicht, möglichst viele Zahlen zu sammeln.

Entscheidend ist, die richtigen Fragen zu beantworten:

Wird der Service wie vereinbart erbracht?

Wo gibt es Abweichungen?

Welche Benutzer oder Geschäftsprozesse sind betroffen?

Welche Ursachen sind erkennbar?

Welche Verbesserungen sind notwendig?

Gute Messung unterstützt Entscheidungen. Schlechte Messung erzeugt falsche Sicherheit.

Warum Kennzahlen wichtig sind

Ohne Messung bleibt Servicequalität oft subjektiv.

Typische Aussagen ohne klare Daten:

„Der Service ist ständig langsam.“
„Der Support reagiert nie.“
„Das System fällt dauernd aus.“
„Die IT hält ihre Zusagen nicht ein.“
„Der Lieferant ist unzuverlässig.“
„Die Benutzer sind unzufrieden.“

Kennzahlen helfen, solche Aussagen zu prüfen.

Sie zeigen:

wie häufig etwas passiert,
wie stark die Auswirkung ist,
ob Ziele erreicht wurden,
ob sich Trends verschlechtern,
ob Verbesserungen wirken,
und wo genauer analysiert werden muss.

Kennzahlen sind kein Selbstzweck

Eine Kennzahl ist nur sinnvoll, wenn sie genutzt wird.

Ungeeignet:

Wir messen alles, weil es technisch möglich ist.

Besser:

Wir messen das, was für Servicequalität, Steuerung, Risiko und Verbesserung wichtig ist.

Zu viele Kennzahlen führen zu unübersichtlichen Reports.

Zu wenige Kennzahlen können wichtige Probleme verdecken.

Die richtige Auswahl hängt vom Service, den Zielen und den Entscheidungen ab, die unterstützt werden sollen.

Gute Kennzahlen

Gute Kennzahlen sind:

verständlich,
messbar,
relevant,
nachvollziehbar,
regelmäßig verfügbar,
vergleichbar,
beeinflussbar,
mit Servicezielen verbunden,
und für Entscheidungen nutzbar.

Eine Kennzahl sollte immer eine Frage beantworten.

Beispiel:

Nicht nur:

Wie viele Tickets wurden geschlossen?

Sondern:

Werden Benutzer schneller wieder arbeitsfähig und verbessert sich die Servicequalität?

Kennzahl und Ziel unterscheiden

Eine Kennzahl ist ein Messwert.

Ein Ziel beschreibt, welcher Wert erreicht werden soll.

Begriff	Bedeutung	Beispiel
Kennzahl	gemessener Wert	Verfügbarkeit des Service
Zielwert	gewünschter oder vereinbarter Wert	mindestens 99,5 Prozent während Servicezeit
Messmethode	Art der Ermittlung	synthetischer Login-Test alle 5 Minuten
Report	Darstellung und Bewertung	Monatsbericht Servicequalität
Maßnahme	Reaktion auf Ergebnis	Problem Record für wiederholte Ausfälle

Ohne Zielwert ist eine Kennzahl schwer zu bewerten.

Ohne Messmethode ist ein Ziel schwer überprüfbar.

Messmethode

Die Messmethode beschreibt, wie eine Kennzahl ermittelt wird.

Zu klären ist:

Was genau wird gemessen?
Wo wird gemessen?
Wann wird gemessen?
Wie häufig wird gemessen?
Welche Datenquelle gilt?
Welche Zeiträume zählen?
Welche Ausnahmen gelten?
Wer prüft die Daten?
Wie wird das Ergebnis berechnet?
Wie wird berichtet?

Eine unklare Messmethode führt zu Diskussionen über Zahlen statt zu Verbesserungen.

Beispiel: Verfügbarkeit messen

Unklar:

Der Service war zu 99,9 Prozent verfügbar.

Klärende Fragen:

Wurde aus Sicht des Servers oder aus Sicht des Benutzers gemessen?
Zählte nur die Startseite oder auch die Anmeldung?
Wurden geplante Wartungsfenster ausgeschlossen?
Wurde während Servicezeit oder rund um die Uhr gemessen?
Zählten kurze Unterbrechungen?
Waren alle Standorte betroffen oder nur einzelne?
Welche Datenquelle wurde verwendet?

Erst mit diesen Angaben ist die Zahl aussagekräftig.

Technische Messung und Benutzerperspektive

Technische Messungen sind wichtig, aber nicht ausreichend.

Beispiele:

Technische Sicht	Benutzerperspektive
Server antwortet auf Ping	Benutzer kann Anwendung nutzen
HTTP-Status ist 200	Anmeldung funktioniert wirklich
Datenbank läuft	Anwendung verarbeitet Daten korrekt
CPU-Auslastung ist normal	Oberfläche reagiert schnell genug
Service Desk Ticket ist geschlossen	Benutzer ist tatsächlich arbeitsfähig

Ein Service kann technisch verfügbar sein und trotzdem für Benutzer schlecht nutzbar sein.

Servicebezogene Kennzahlen

Service Level Management sollte möglichst servicebezogen messen.

Beispiele:

Verfügbarkeit je Service,
Incidents je Service,
Reaktionszeit je Priorität,
Wiederherstellungszeit je Service,
Benutzerzufriedenheit je Service,
Anzahl Major Incidents je Service,
Anzahl Changes je Service,
Incidents nach Changes,
wiederkehrende Incidents je Service,
offene Problems je Service,
SLA-Erfüllung je Service.

Servicebezogene Kennzahlen sind hilfreicher als reine Technikzahlen ohne Kontext.

Verfügbarkeit

Verfügbarkeit beschreibt, ob ein Service im vereinbarten Zeitraum nutzbar ist.

Zu definieren ist:

Servicezeit,
Messpunkt,
Messintervall,
betroffene Funktionen,
Ausnahmen,
Wartungsfenster,
Teilausfälle,
Datenquelle.

Beispiel:

Der Service gilt als verfügbar, wenn Benutzer während der Servicezeit die Startseite öffnen, sich anmelden und die Hauptfunktion nutzen können.

Diese Definition ist aussagekräftiger als nur:

Server ist erreichbar.

Berechnung von Verfügbarkeit

Eine einfache Formel:

Verfügbarkeit = verfügbare Zeit / vereinbarte Servicezeit × 100

Beispiel:

vereinbarte Servicezeit im Monat: 10.000 Minuten
Ausfallzeit: 50 Minuten

Verfügbarkeit = 9.950 / 10.000 × 100
Verfügbarkeit = 99,5 Prozent

Wichtig:

Die Berechnung muss definieren, welche Ausfallzeit zählt und welche nicht.

Geplante Wartung

Geplante Wartung sollte getrennt betrachtet werden.

Zu klären ist:

Wird geplante Wartung aus der Verfügbarkeitsberechnung ausgeschlossen?
War die Wartung angekündigt?
Lag sie im vereinbarten Wartungsfenster?
Wurde das Wartungsfenster überschritten?
Waren Benutzer trotzdem betroffen?
Gab es Incidents nach der Wartung?

Geplante Wartung ist nicht automatisch unproblematisch.

Auch geplante Arbeiten können die Benutzererfahrung verschlechtern, wenn sie schlecht kommuniziert oder schlecht geplant sind.

Teilausfälle

Nicht jeder Ausfall betrifft den gesamten Service.

Beispiele:

Anmeldung funktioniert, aber Export nicht.
Service funktioniert an Standort A, aber nicht an Standort B.
interne Benutzer können arbeiten, externe Benutzer nicht.
Anwendung läuft, aber Schnittstelle zum ERP ist gestört.
nur bestimmte Benutzergruppe ist betroffen.

Für Teilausfälle muss festgelegt werden, wie sie bewertet werden.

Sonst wird Servicequalität zu positiv oder zu negativ dargestellt.

Reaktionszeit

Reaktionszeit beschreibt die Zeit bis zur ersten qualifizierten Bearbeitung oder Rückmeldung.

Zu klären ist:

Wann startet die Messung?
Wann endet die Messung?
Zählt nur Supportzeit?
Was gilt als qualifizierte Reaktion?
Zählt eine automatische Eingangsbestätigung?
Wird nach Priorität unterschieden?
Werden Wartezeiten auf Benutzer getrennt?

Eine automatische Antwort sollte nicht als echte Reaktion gewertet werden, wenn keine Bearbeitung beginnt.

Wiederherstellungszeit

Wiederherstellungszeit beschreibt, wann ein Service wieder nutzbar ist.

Das kann bedeuten:

vollständige technische Lösung,
Wiederherstellung der Kernfunktion,
funktionierender Workaround,
Rollback,
Ersatzverfahren,
Teilwiederherstellung.

Wichtig ist, den Begriff vorher zu definieren.

Ein Benutzer kann wieder arbeitsfähig sein, obwohl die Ursache noch nicht dauerhaft behoben ist.

Lösungszeit

Lösungszeit beschreibt die Zeit bis zur endgültigen Lösung.

Sie unterscheidet sich von Wiederherstellungszeit.

Beispiel:

Ein Incident wird durch Workaround schnell behoben.

Das zugrunde liegende Problem wird erst später durch einen Change dauerhaft gelöst.

Dann sind Wiederherstellung und endgültige Lösung unterschiedliche Zeitpunkte.

MTTA, MTTR und ähnliche Kennzahlen

Häufig genutzte Kennzahlen:

Kennzahl	Bedeutung
MTTA	durchschnittliche Zeit bis zur Annahme oder Reaktion
MTTR	durchschnittliche Zeit bis Wiederherstellung oder Lösung
MTBF	durchschnittliche Zeit zwischen Ausfällen
MTRS	durchschnittliche Zeit bis Service-Wiederherstellung
FCR	First Contact Resolution, Lösung beim ersten Kontakt

Wichtig:

Abkürzungen müssen in der Organisation einheitlich definiert werden.

MTTR kann je nach Organisation „Mean Time to Repair“, „Mean Time to Restore“ oder anders verstanden werden.

Incident-Kennzahlen

Mögliche Incident-Kennzahlen:

Anzahl Incidents je Service,
Anzahl Incidents je Priorität,
Major Incidents,
Reaktionszeit,
Wiederherstellungszeit,
Wiedereröffnungen,
Eskalationen,
Incidents nach Changes,
wiederkehrende Incidents,
Incidents mit Known Error,
Incidents mit Knowledge-Nutzung,
Benutzerzufriedenheit nach Incident.

Wichtig ist die Kombination.

Eine einzelne Incident-Kennzahl erklärt selten die ganze Situation.

Problem-Kennzahlen

Mögliche Problem-Kennzahlen:

offene Problems,
Problems je Service,
Problems mit Known Error,
Problems mit Workaround,
Zeit bis Ursachenanalyse,
wiederkehrende Incidents je Problem,
Problems mit dauerhafter Lösung,
Problems ohne Owner,
gealterte Problems,
Problems mit hohem Risiko.

Problem-Kennzahlen helfen, strukturelle Ursachen sichtbar zu machen.

Sie sollten nicht dazu führen, Problems vorschnell zu schließen.

Change-Kennzahlen

Mögliche Change-Kennzahlen:

Anzahl Changes,
erfolgreiche Changes,
fehlgeschlagene Changes,
Emergency Changes,
Changes mit Rollback,
Incidents nach Changes,
Changes ohne betroffene CIs,
Changes ohne Risikoanalyse,
Changes ohne Knowledge-Prüfung,
Durchlaufzeit von Changes,
Changes außerhalb Wartungsfenster.

Change-Kennzahlen helfen, Stabilität und Veränderungsfähigkeit zu bewerten.

Request-Kennzahlen

Mögliche Request-Kennzahlen:

Anzahl Service Requests,
Bearbeitungszeit je Request-Typ,
Erfüllung vereinbarter Zielzeiten,
Rückfragenquote,
abgebrochene Requests,
automatisierte Requests,
Self-Service-Anteil,
Genehmigungsdauer,
häufige Standardrequests,
falsch eingereichte Requests.

Diese Kennzahlen helfen, Serviceportale, Formulare und Automatisierung zu verbessern.

Knowledge-Kennzahlen

Mögliche Knowledge-Kennzahlen:

Artikelaufrufe,
Nutzung im Incident,
Suchanfragen ohne Treffer,
Artikel ohne Owner,
Artikel ohne Review-Datum,
schlecht bewertete Artikel,
häufig genutzte Workarounds,
Knowledge-Artikel nach Major Incidents,
Knowledge-Aktualisierung nach Changes,
veraltete Artikel.

Knowledge-Kennzahlen zeigen, ob Wissen im Alltag hilft oder nur abgelegt wird.

Benutzerzufriedenheit

Benutzerzufriedenheit ergänzt technische Kennzahlen.

Mögliche Methoden:

kurze Umfrage nach Ticketabschluss,
regelmäßige Serviceumfrage,
Feedback im Serviceportal,
Bewertung von Knowledge-Artikeln,
Interviews mit Fachbereichen,
Service Reviews,
Auswertung wiederkehrender Beschwerden.

Wichtig:

Zufriedenheit ist subjektiv, aber trotzdem wertvoll.

Sie zeigt, ob gemessene Servicequalität auch so erlebt wird.

Experience Level

Neben klassischen Service Levels kann auch die Benutzererfahrung betrachtet werden.

Beispiele:

Wie einfach ist ein Service zu nutzen?
Wie verständlich ist der Self-Service?
Wie hilfreich ist die Kommunikation?
Wie schnell fühlen sich Benutzer unterstützt?
Wie viele Schritte braucht ein Standardrequest?
Wie störend sind kurze Ausfälle im Arbeitsfluss?

Technische Ziele allein zeigen nicht immer die tatsächliche Nutzungserfahrung.

Reporting

Reporting stellt Kennzahlen und Bewertungen verständlich dar.

Ein Report sollte nicht nur Zahlen zeigen.

Er sollte erklären:

Was ist passiert?
Was bedeutet es?
Welche Ziele wurden erreicht?
Welche Ziele wurden verfehlt?
Was sind die Ursachen?
Welche Risiken bestehen?
Welche Maßnahmen laufen?
Welche Entscheidungen werden benötigt?

Ein guter Report führt zu Handlung, nicht nur zu Ablage.

Zielgruppen für Reporting

Verschiedene Zielgruppen benötigen unterschiedliche Reports.

Zielgruppe	benötigt typischerweise
Management	Risiken, Trends, Zielerreichung, Entscheidungen
Service Owner	Servicequalität, Abweichungen, Maßnahmen
Service Desk	Tickettrends, Knowledge-Lücken, Eskalationen
Fachteam	technische Ursachen, Changes, Problems
Security Team	Schwachstellen, kritische CIs, Vorfälle
Benutzer	Status, einfache Verfügbarkeit, bekannte Störungen

Nicht jeder Report muss alle Details enthalten.

Management-Reporting

Management benötigt meist verdichtete Informationen.

Geeignete Inhalte:

wichtigste Serviceziele,
rote und kritische Abweichungen,
große Risiken,
Major Incidents,
Trends,
Lieferantenprobleme,
Kosten- oder Ressourcenbezug,
Entscheidungen,
geplante Verbesserungen.

Management-Reports sollten nicht mit technischen Details überladen werden.

Sie müssen entscheidungsfähig machen.

Operatives Reporting

Operative Teams benötigen mehr Detail.

Geeignete Inhalte:

genaue Incident-Daten,
betroffene CIs,
Fehlerkategorien,
wiederkehrende Muster,
technische Messpunkte,
betroffene Versionen,
Eskalationszeiten,
Change-Auswirkungen,
Problem Records,
konkrete Maßnahmen.

Operatives Reporting hilft bei Analyse und Verbesserung der täglichen Arbeit.

Benutzerorientiertes Reporting

Benutzer benötigen klare und einfache Informationen.

Beispiele:

aktueller Status eines Service,
bekannte Störung,
geplantes Wartungsfenster,
erwartete nächste Aktualisierung,
was Benutzer tun sollen,
ob ein Ticket notwendig ist,
ob ein Workaround verfügbar ist.

Benutzer brauchen keine internen Detailberichte.

Sie brauchen verständliche Orientierung.

Dashboards

Dashboards zeigen aktuelle oder regelmäßige Informationen auf einen Blick.

Mögliche Inhalte:

Serviceverfügbarkeit,
offene Major Incidents,
SLA-Erfüllung,
Ticketvolumen,
kritische Changes,
offene Problems,
ablaufende Zertifikate,
Lieferantenstatus,
Knowledge-Lücken,
Benutzerzufriedenheit.

Ein Dashboard muss gepflegt und richtig interpretiert werden.

Ein grünes Dashboard bedeutet nicht automatisch, dass Benutzer zufrieden sind.

Ampelstatus

Viele Reports nutzen Ampelfarben.

Beispiel:

Status	Bedeutung
grün	Ziel erreicht
gelb	Risiko oder leichte Abweichung
rot	Ziel verfehlt oder kritisches Risiko

Wichtig:

Ampeln brauchen klare Regeln.

Ungeeignet:

Gelb nach Bauchgefühl.

Besser:

Gelb, wenn Zielwert um bis zu 10 Prozent verfehlt wird oder ein Risiko für den nächsten Zeitraum besteht.

Trends statt Momentaufnahmen

Ein einzelner Monatswert reicht oft nicht aus.

Wichtiger sind Trends.

Beispiele:

Ticketvolumen steigt seit drei Monaten.
Wiederherstellungszeit verbessert sich.
Benutzerzufriedenheit sinkt trotz SLA-Erfüllung.
Incidents nach Changes nehmen zu.
Suchanfragen ohne Treffer steigen.
Emergency Changes werden häufiger.

Trends zeigen, ob sich Servicequalität verbessert oder verschlechtert.

Durchschnittswerte vorsichtig nutzen

Durchschnittswerte können täuschen.

Beispiel:

Die durchschnittliche Lösungszeit beträgt 4 Stunden.

Mögliche Realität:

viele kleine Tickets werden sehr schnell gelöst,
wenige kritische Tickets dauern extrem lange,
bestimmte Benutzergruppen sind stark betroffen,
ein Service hat große Probleme, andere nicht.

Deshalb sollten Durchschnittswerte ergänzt werden durch:

Median,
Verteilung,
Priorität,
Servicebezug,
Ausreißer,
Anzahl kritischer Fälle.

Median und Perzentile

Der Median zeigt den mittleren Wert einer Verteilung.

Perzentile zeigen, wie viele Fälle unter einem bestimmten Wert liegen.

Beispiel:

90 Prozent der P2-Incidents werden innerhalb von 8 Stunden wiederhergestellt.
50 Prozent werden innerhalb von 2 Stunden wiederhergestellt.
10 Prozent dauern deutlich länger.

Das ist oft aussagekräftiger als nur ein Durchschnittswert.

Kontext zu Kennzahlen

Kennzahlen brauchen Kontext.

Beispiel:

Ticketvolumen steigt.

Mögliche Ursachen:

neuer Service eingeführt,
Release mit Fehlern,
bessere Meldewege,
mehr Benutzer,
bekannte Störung,
schlechte Self-Service-Artikel,
organisatorische Änderung,
Sicherheitskampagne,
saisonale Belastung.

Ohne Kontext kann eine Kennzahl falsch interpretiert werden.

Datenqualität im Reporting

Reports sind nur so gut wie ihre Daten.

Typische Datenprobleme:

falsche Kategorien,
fehlende Servicezuordnung,
falsche Prioritäten,
nicht gepflegte CIs,
uneinheitliche Statuswerte,
manuell geschönte Werte,
fehlende Zeitstempel,
automatische Antworten als Reaktion gezählt,
Wartezeiten falsch behandelt.

Datenqualität muss regelmäßig geprüft werden.

Messung kann Verhalten beeinflussen

Kennzahlen beeinflussen, wie Menschen arbeiten.

Beispiele:

Wird nur Ticketanzahl gemessen, werden Tickets schnell geschlossen.
Wird nur Bearbeitungszeit gemessen, werden schwierige Fälle vermieden.
Wird nur SLA-Erfüllung gemessen, werden Prioritäten möglicherweise angepasst.
Wird nur Artikelanzahl gemessen, entstehen viele schlechte Knowledge-Artikel.

Kennzahlen müssen so gewählt werden, dass sie gutes Verhalten fördern.

Falsche Anreize vermeiden

Besser ist eine Kombination von Kennzahlen.

Beispiele:

Kombination	besser als
Lösungszeit und Wiedereröffnungsquote	nur schnelle Lösung
Ticketanzahl und Benutzerzufriedenheit	nur Produktivität
SLA-Erfüllung und Major-Incident-Analyse	nur grüne Ampel
Change-Erfolg und Incidents nach Changes	nur Anzahl Changes
Knowledge-Nutzung und Artikelbewertung	nur Anzahl Artikel

Gute Kennzahlensets betrachten Qualität, Wirkung und Stabilität gemeinsam.

Reporting-Frequenz

Die Frequenz hängt vom Zweck ab.

Report	mögliche Frequenz
Live-Dashboard für Betrieb	laufend
Major-Incident-Status	während Ereignis regelmäßig
Service-Level-Report	monatlich
Service Review	monatlich oder quartalsweise
Lieferantenreport	monatlich oder quartalsweise
Managementreport	monatlich oder quartalsweise
Datenqualitätsreport	regelmäßig nach Bedarf

Zu häufige Reports ohne Handlung erzeugen Aufwand.

Zu seltene Reports erkennen Probleme zu spät.

Reporting und Service Review

Reports sollten Service Reviews vorbereiten.

Ein Service Review nutzt Reports, um zu besprechen:

welche Ziele erreicht wurden,
welche Abweichungen relevant sind,
welche Ursachen erkennbar sind,
welche Risiken bestehen,
welche Maßnahmen laufen,
welche Entscheidungen nötig sind,
welche Verbesserungen priorisiert werden.

Reporting liefert Daten.

Service Review macht daraus Bewertung und Handlung.

SLA-Abweichungen berichten

Bei SLA-Abweichungen sollte ein Report enthalten:

betroffenes Ziel,
Zeitraum,
Höhe der Abweichung,
betroffener Service,
betroffene Benutzer,
Ursache oder vermutete Ursache,
beteiligte CIs oder Lieferanten,
Zusammenhang mit Changes oder Problems,
aktuelle Maßnahmen,
geplante Verbesserung,
Verantwortlicher,
Termin.

Nur „SLA nicht erreicht“ reicht nicht aus.

Beispiel: SLA-Abweichung

Ziel

P1-Incidents innerhalb von 4 Stunden wiederherstellen.

Ergebnis

Ziel wurde in einem Fall verfehlt.

Ursache

Datenbankproblem wurde zu spät an das zuständige Team eskaliert.

Auswirkung

Mitarbeiterportal war für mehrere Standorte nicht nutzbar.

Maßnahme

OLA-Eskalation wird angepasst.

Service Desk erhält neuen Knowledge-Artikel.

Monitoringalarm wird geändert.

Serviceverbesserung aus Kennzahlen ableiten

Kennzahlen sollen Verbesserungen auslösen.

Beispiele:

viele Incidents nach Changes → Change Review verbessern,
viele Tickets zu MFA → Self-Service-Artikel verbessern,
lange Eskalationszeiten → OLA prüfen,
schlechte Benutzerbewertung → Kommunikation und Lösung prüfen,
häufige Workarounds → Problem Management starten,
veraltete Knowledge-Artikel → Review-Prozess verbessern,
wiederholte Lieferantenverzögerung → Supplier Review durchführen.

Die wichtigste Frage lautet:

Welche konkrete Handlung folgt aus dem Report?

Kennzahlen für Continual Improvement

Continual Improvement nutzt Kennzahlen zur Priorisierung.

Hilfreich sind:

Trends,
wiederholte Abweichungen,
Auswirkung auf Benutzer,
Risiko,
Kosten,
Häufigkeit,
Verbesserungspotenzial,
Aufwand,
erwarteter Nutzen.

Nicht jede schlechte Kennzahl ist sofort höchste Priorität.

Die Bedeutung hängt von Servicekritikalität und Auswirkung ab.

Praxisbeispiel: Grüne SLA, unzufriedene Benutzer

Situation

SLA-Verfügbarkeit wurde erreicht.

Trotzdem sind Benutzer unzufrieden.

Analyse

Anwendung ist verfügbar,
aber häufig langsam,
Suchfunktion reagiert schlecht,
Tickets werden formal schnell beantwortet,
dauerhafte Lösung fehlt.

Erkenntnis

Verfügbarkeit allein misst nicht die Benutzererfahrung.

Verbesserung

Performance-Ziel und Benutzerfeedback werden ergänzt.

Praxisbeispiel: Ticketzahlen steigen

Situation

Ticketanzahl im Service Desk steigt stark.

Mögliche Ursachen

neuer Service,
schlechtes Release,
fehlender Self-Service,
bessere Meldewege,
echter Qualitätsverlust,
neue Benutzergruppe,
Sicherheitskampagne.

Vorgehen

Tickets nach Service, Kategorie, Priorität und Ursache auswerten.

Nicht vorschnell annehmen, dass der Service Desk schlechter arbeitet.

Praxisbeispiel: Lieferant erfüllt Ziel nicht

Situation

SLA-Abweichungen entstehen durch langsame Lieferantenreaktion.

Reporting zeigt

betroffener Service,
Lieferant,
Reaktionszeiten,
Vertragsziel,
tatsächliche Bearbeitung,
Auswirkung auf Benutzer.

Verbesserung

Supplier Review durchführen.

Underpinning Contract prüfen.

Internes SLA realistisch bewerten.

Praxisbeispiel: Knowledge-Lücke

Situation

Viele Benutzer suchen im Portal nach „neues Handy MFA“.

Es gibt keinen passenden Treffer.

Folge

Viele Tickets entstehen.

Verbesserung

Benutzerartikel „MFA auf neuem Smartphone einrichten“ erstellen.

Suchbegriffe ergänzen.

Ticketformular verlinken.

Messung

Suchtreffer, Artikelbewertung und Ticketvolumen nach Verbesserung prüfen.

Typische Fehler

Fehler 1

Es werden zu viele Kennzahlen ohne klare Entscheidung gemessen.

Fehler 2

Kennzahlen sind technisch korrekt, aber für den Service nicht relevant.

Fehler 3

Messmethoden sind nicht definiert.

Fehler 4

Reports enthalten Zahlen ohne Bewertung.

Fehler 5

Durchschnittswerte verdecken kritische Einzelfälle.

Fehler 6

Benutzerzufriedenheit wird ignoriert.

Fehler 7

Datenqualität in Tickets und CMDB ist schlecht.

Fehler 8

Automatische Antworten werden als echte Reaktion gezählt.

Fehler 9

SLA-Abweichungen werden nur gemeldet, aber nicht analysiert.

Fehler 10

Kennzahlen erzeugen falsche Anreize.

Fehler 11

Reports sind nicht auf Zielgruppen angepasst.

Fehler 12

Aus Reports entstehen keine Verbesserungsmaßnahmen.

Checkliste Kennzahl auswählen

Checkliste Messmethode

Checkliste Reporting

Checkliste SLA-Abweichung analysieren

Checkliste Datenqualität für Reports

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker liefern viele Daten, die für Service Level Management wichtig sind.

Im Arbeitsalltag bedeutet das:

Incidents sauber dokumentieren,
betroffene Services und CIs korrekt verknüpfen,
technische Messwerte richtig interpretieren,
Monitoring nicht nur auf Server, sondern auf Servicefunktion ausrichten,
Wiederherstellungszeiten nachvollziehbar erfassen,
Changes und deren Auswirkungen dokumentieren,
wiederkehrende Probleme erkennen,
und Reports nicht nur als Kontrolle, sondern als Verbesserungsgrundlage verstehen.

Gute Messung hilft, technische Arbeit sichtbar und steuerbar zu machen.

Zusammenfassung

Serviceziele verstehen
↓
passende Kennzahlen auswählen
↓
Messmethode eindeutig definieren
↓
Datenquellen und Datenqualität sichern
↓
technische und Benutzerperspektive kombinieren
↓
Ergebnisse verständlich berichten
↓
Abweichungen analysieren
↓
Trends erkennen
↓
Verbesserungsmaßnahmen ableiten
↓
Wirkung erneut messen

Merksätze

Eine Kennzahl ist nur sinnvoll, wenn daraus eine Entscheidung oder Verbesserung entstehen kann.

Messmethode und Datenquelle müssen klar sein.

Technische Verfügbarkeit ist nicht automatisch gute Servicequalität.

Durchschnittswerte können kritische Probleme verdecken.

Reports brauchen Kontext, Bewertung und Maßnahmen.

Kennzahlen können Verhalten beeinflussen und falsche Anreize erzeugen.

Reporting ist die Grundlage für Service Reviews und Continual Improvement.

Verwandte Seiten

8.1 Service Level Management – Ziele, Begriffe und Grundlagen
8.2 SLA, SLR, OLA und Underpinning Contracts
8.4 Service Reviews und Continual Improvement
8.5 Service Level Management im Zusammenspiel mit Incident, Problem, Change und Configuration Management
Measurement and Reporting
Incident Management
Problem Management
Change Enablement
Service Configuration Management
Knowledge Management

Quellen und Versionsstand

Offizielle Grundlagen

PeopleCert – ITIL Practice Guide: Service Level Management
PeopleCert – ITIL Practice Guide: Measurement and Reporting
PeopleCert – ITIL Practice Guide: Incident Management
PeopleCert – ITIL Practice Guide: Problem Management
PeopleCert – ITIL Practice Guide: Change Enablement
PeopleCert – ITIL Practice Guide: Continual Improvement
ITIL Foundation – Version 5

Einordnung

Die dargestellten:

Kennzahlen,
Messmethoden,
Reporting-Strukturen,
SLA-Abweichungsanalysen,
Checklisten,
und Praxisbeispiele

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

Kennzahlenliste,
Berechnungsformel,
Reporting-Vorlage,
Dashboard-Struktur,
Ampellogik,
Zielwerttabelle,
oder Review-Frequenz

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

Services,
Service Level Agreements,
Kunden,
Benutzergruppen,
Supportmodell,
Monitoring,
Toollandschaft,
Datenqualität,
Lieferanten,
Risiken,
und verfügbare Fähigkeiten

angepasst werden.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance
Fachlicher Stand: August 2026

Revision #1
Created 2 August 2026 20:30:31 by Admin
Updated 2 August 2026 20:30:45 by Admin