# 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** - [ ] Kennzahl beantwortet eine konkrete Frage - [ ] Kennzahl ist für den Service relevant - [ ] Zielgruppe kennt die Bedeutung - [ ] Zielwert ist definiert - [ ] Messmethode ist klar - [ ] Datenquelle ist verfügbar - [ ] Datenqualität ist ausreichend - [ ] Kennzahl ist beeinflussbar - [ ] Kennzahl erzeugt keine falschen Anreize - [ ] Kennzahl unterstützt Entscheidung oder Verbesserung --- **Checkliste Messmethode** - [ ] Startpunkt der Messung definiert - [ ] Endpunkt der Messung definiert - [ ] Messzeitraum definiert - [ ] Servicezeit berücksichtigt - [ ] Supportzeit berücksichtigt - [ ] Wartungsfenster geregelt - [ ] Ausnahmen definiert - [ ] Datenquelle festgelegt - [ ] Berechnung beschrieben - [ ] Verantwortlicher für Prüfung festgelegt - [ ] Ergebnis nachvollziehbar dokumentiert --- **Checkliste Reporting** - [ ] Zielgruppe definiert - [ ] Servicebezug vorhanden - [ ] Zielwerte sichtbar - [ ] Ist-Werte sichtbar - [ ] Abweichungen markiert - [ ] Ursachen beschrieben - [ ] Trends dargestellt - [ ] Risiken genannt - [ ] Maßnahmen beschrieben - [ ] Verantwortliche benannt - [ ] Termine genannt - [ ] Report führt zu Review oder Entscheidung --- **Checkliste SLA-Abweichung analysieren** - [ ] betroffenes SLA-Ziel benannt - [ ] Zeitraum genannt - [ ] betroffener Service genannt - [ ] betroffene Benutzer oder Standorte beschrieben - [ ] technische Ursache geprüft - [ ] organisatorische Ursache geprüft - [ ] Lieferantenbezug geprüft - [ ] Zusammenhang mit Changes geprüft - [ ] Problem Record geprüft oder erstellt - [ ] Maßnahme definiert - [ ] Owner benannt - [ ] Wirksamkeitsprüfung geplant --- **Checkliste Datenqualität für Reports** - [ ] Tickets haben korrekte Servicezuordnung - [ ] Prioritäten sind nachvollziehbar - [ ] Zeitstempel sind korrekt - [ ] Statuswerte sind einheitlich - [ ] CIs sind verknüpft, falls relevant - [ ] Kategorien werden einheitlich genutzt - [ ] automatische Antworten werden getrennt bewertet - [ ] Wartezeiten sind nachvollziehbar - [ ] Dubletten werden bereinigt - [ ] manuelle Korrekturen sind dokumentiert --- **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