Service Desk, Incident Management und Problem Management

Support beginnt damit festzustellen, was passiert ist. Eine Practice bringt die Menschen, Informationen, Werkzeuge, Partner und Arbeitsweisen zusammen, die zum Erreichen eines Ziels nötig sind. Die sieben Support-Practices tauschen Informationen aus, haben aber unterschiedliche Zwecke.

Die Situation einordnen

Ein Incident setzt keinen vollständigen Ausfall voraus. Bei einer Spesenseite, die sich normalerweise in 2 Sekunden öffnet, jetzt aber 40 Sekunden braucht, liegt eine Qualitätsminderung vor. Problem Management sucht nach der Ursache hinter Incidents und nach möglichen Ursachen, bevor sie den Service stören. Ein Incident kann diese Arbeit rechtfertigen; viele Incidents können auf dasselbe Problem zurückgehen.

Ein Ereignis betrifft einen beobachteten Zustand. Eine Festplattenwarnung kann eine Aktion ermöglichen, bevor jemand den Service verliert. Zeigt ein Ereignis, dass der Service unterbrochen oder beeinträchtigt wurde, ist auch Incident Management nötig. Der Ereignis- und der Incident-Datensatz beschreiben unterschiedliche Aspekte derselben Situation.

Ein Konfigurationselement, kurz CI, ist eine Komponente, die verwaltet werden muss, um einen Service bereitzustellen. Server, Datenbanken, Netzwerk-Switches und Softwarelizenzen können CIs sein. Die Verknüpfung von Datensätzen mit ihnen hilft Mitarbeitenden zu erkennen, welcher Service und welche Komponente betroffen sind.

Ursache und Abhilfe unterscheiden

Ein bekannter Fehler ist ein Problem, das analysiert wurde, aber ungelöst bleibt. Die Analyse muss die zugrunde liegende Ursache noch nicht geklärt haben, und ein Workaround muss noch nicht vorliegen. Ein Workaround verringert oder beseitigt die Auswirkung, solange keine vollständige Lösung verfügbar ist; manche Workarounds verringern auch die Wahrscheinlichkeit weiterer Incidents.

Beim VPN-Problem ermöglicht die manuelle erneute Verbindung nach dem Aufwachen des Laptops die Weiterarbeit. Dieser Workaround kann den aktuellen Incident eines Anwenders lösen, während das Problem offen bleibt. Die Bezeichnung als bekannter Fehler hält fest, dass das Problem analysiert wurde; sie behauptet keine dauerhafte Fehlerbehebung.

Die zuständige Practice wählen

Der Service Desk erfasst die Nachfrage der Anwender. Incident Management stellt den Service wieder her; Problem Management bearbeitet Ursachen, Workarounds und bekannte Fehler. Service Request Management erfüllt vordefinierte Anfragen. Monitoring und Event Management beobachtet Services und reagiert auf bedeutsame Veränderungen. Service Level Management vereinbart und überprüft geschäftsbezogene Ziele. Beziehungsmanagement entwickelt die Beziehungen zu Stakeholdern, die diese Vereinbarungen unterstützen.

Ordne anhand der Fakten ein, die dem Kontakt zugrunde liegen. Ein vergessenes Passwort führt gewöhnlich zu einer Anfrage nach Zurücksetzung. Ein ausgefallener Anmeldeserver verursacht Incidents. Wird die Laptopbestellung für einen neuen Mitarbeitenden als Incident erfasst, erhöht das die Ausfallzahlen und führt zur Anwendung falscher Ziele, selbst wenn der Anwender sie über das Incident-Formular eingereicht hat.

Der Service Desk erfasst die Nachfrage nach der Lösung von Incidents und nach Serviceanfragen. Er dient als zentrale Anlaufstelle zwischen Anwendern und dem Service Provider. Anwender haben eine klare Stelle, an die sie sich für Hilfe wenden können, auch wenn mehrere Teams zum Ergebnis beitragen müssen.

Das Gespräch zusammenhalten

Ein Kontakt muss bestätigt, eingeordnet, einem Verantwortlichen zugewiesen und bearbeitet werden. Der Service Desk löst, was er kann, und leitet Spezialaufgaben an die richtigen Personen weiter. Während diese arbeiten, bleibt er für den Kontakt mit dem Anwender verantwortlich: Er informiert über Fortschritte, schafft klare Erwartungen und prüft, ob das Ergebnis für den Anwender funktioniert.

Anwender können den Service Desk per Telefon, Portal, mobiler App, E-Mail, Live-Chat, Chatbot, an einer persönlich besetzten Anlaufstelle, per Textnachricht, über soziale Medien oder ein Community-Forum kontaktieren. Ein gemeinsames System für Datensätze erhält den Verlauf über alle Kanäle hinweg. Wer vom Chat zu einem Anruf wechselt, sollte den Sachverhalt nicht noch einmal von vorn schildern müssen.

Menschen um den Service herum organisieren

Eine Follow-the-Sun-Übergabe braucht einen brauchbaren Datensatz: aktuelle Auswirkung, erledigte Arbeit, nächste Aktion und zugesagte Information. Das nächste Team kann die Arbeit und das Gespräch fortsetzen, ohne darauf angewiesen zu sein, dass der vorherige Mitarbeitende online ist.

Da Self-Service mehr einfache Aufgaben übernimmt, verbringen Mitarbeitende mehr Zeit damit, Menschen in geschäftlichen Situationen zu helfen. Praktische Kenntnisse der Organisation helfen ihnen zu verstehen, warum eine blockierte Aufgabe wichtig ist. Ein Problem bei der Gehaltsabrechnung kurz vor einer Frist hat eine andere Dringlichkeit als dasselbe Symptom in einer ruhigen Phase.

Mitarbeitende brauchen Einfühlungsvermögen, klare Kommunikation, emotionale Intelligenz sowie Fähigkeiten zur Analyse und Priorisierung von Incidents. Nicht jeder Mitarbeitende muss hoch spezialisiert auf technische Fragen sein. Eine wirksame Information könnte lauten: „Ich verstehe, dass das deinen Monatsabschlussbericht blockiert. Das Netzwerkteam arbeitet daran, und ich rufe bis 11:30 Uhr mit einem Zwischenstand an.“ Sie verbindet die Arbeit des Anwenders mit einer Aktion und einem verlässlichen nächsten Kontakt.

Mitarbeitenden nützliche Informationen geben

Intelligente Telefonie hilft bei der Verwaltung von Anrufen und Rückrufen. Workflow-Werkzeuge leiten Arbeit weiter und unterstützen Eskalationen. Wissensartikel unterstützen wiederholbare Fehlerbehebungen; Fernzugriffswerkzeuge helfen Mitarbeitenden, Anwender zu unterstützen. Anrufaufzeichnung und Qualitätsprüfungen unterstützen die Anleitung der Mitarbeitenden. Dashboards und Monitoring zeigen aktuelle Zustände, während Konfigurationsinformationen die Komponenten hinter einem Service sichtbar machen.

Neben der Geschwindigkeit auch das Erlebnis messen

Die Erstlösungsquote (FCR) ist der Anteil der Kontakte, die beim ersten Kontakt ohne Weiterleitung oder Rückruf gelöst werden. Bei 780 Lösungen beim ersten Kontakt unter 1.200 Kontakten gilt:

Die durchschnittliche Zeit bis zur Annahme, die Anrufabbruchquote und die Anwenderzufriedenheit ergänzen unterschiedliche Sichtweisen. Die Anrufabbruchquote erfasst Anrufende, die auflegen, bevor ein Mitarbeitender antwortet. Eine steigende FCR kann unzureichende Lösungen verdecken, wenn Anwender bald mit demselben Anliegen zurückkommen. Untersuche deshalb auch Qualität und erneute Kontakte.

Die Datensätze des Service Desks unterstützen auch andere Practices. Wiederholte Symptome helfen bei der Identifizierung von Problemen, Beschwerden liefern Informationen für das Beziehungsmanagement, und Daten zu Reaktionszeiten und Zufriedenheit unterstützen Service-Level-Überprüfungen.

Monitoring und Event Management beobachtet Services und Komponenten systematisch, erfasst ausgewählte bedeutsame Veränderungen und leitet passende Reaktionen ein. Es hilft Teams, auf entstehende Zustände ebenso zu reagieren wie auf Ausfälle, die Anwender bereits beeinträchtigt haben.

Von einer Messung zum Ereignis

Monitoring kann Prozessorlast, Speicherauslastung, Antwortzeiten im Web, geplante Aufträge oder die Temperatur im Rechenzentrum beobachten. Event Management entscheidet, welche Veränderungen bedeutsam sind, wie sie erfasst werden und welche Reaktion sie benötigen. Sein Umfang umfasst Ereignisse in Infrastruktur, Services, Geschäftsprozessen und Informationssicherheit.

Ein Ausnahmeereignis verlangt eine Aktion, doch die Auswirkung auf den Service muss noch bewertet werden. Eine Komponente kann ausfallen, während Redundanz den Service funktionsfähig hält. Erstelle einen Incident, wenn das Ereignis einen unterbrochenen oder beeinträchtigten Service zeigt.

Die verfügbare Zeit berechnen

Eine Festplatte mit 500 GB hat eine Warnung bei 80 % und ein Ausnahmeereignis bei 95 %. Bestimme zuerst den belegten Speicherplatz bei jedem Schwellenwert:

Der verbleibende Speicherplatz dazwischen beträgt 75 GB. Bei einem anhaltenden Wachstum von etwa 10 GB pro Tag:

Die Warnung verschafft Zeit zum Handeln. Diese Schätzung setzt voraus, dass die Wachstumsrate anhält. Aktuelle Messungen bleiben daher nützlich, während das Team Kapazität bereitstellt.

Meldungsrauschen verringern und gemeinsame Ursachen aufdecken

Wähle anhand von Servicezielen und Risiken aus, was überwacht werden soll. Lege Schwellenwerte fest, filtere Ereignisse, die keine Aufmerksamkeit benötigen, und korreliere zusammengehörige Ereignisse. Wenn ein ausgefallener Netzwerk-Switch 40 verbundene Server unerreichbar macht, gruppiert die Korrelation deren Alarme und lenkt die Aufmerksamkeit auf den gemeinsamen Switch.

Für jedes protokollierte Ereignis einen Alarm auszulösen, erzeugt Alarmmüdigkeit. Häufige Meldungen ohne nützliche Aktion gewöhnen Menschen daran, Alarme zu ignorieren. Jeder Alarm braucht einen Verantwortlichen und eine Aktion. Halte routinemäßige Informationsereignisse in Protokollen fest und überprüfe Schwellenwerte, die wiederholt Aufmerksamkeit verlangen, ohne zu nützlicher Arbeit zu führen.

Reaktionen können einen automatisierten Neustart, eine Benachrichtigung, einen Incident-Datensatz, einen Problemdatensatz für einen wiederkehrenden Zustand oder einen Änderungsantrag zur Kapazitätserhöhung umfassen. Manche Ereignisse bleiben einfach zur späteren Analyse im Protokoll. Auch für eine automatisierte Reaktion braucht es eine klare Regel, wann sie gilt.

Prüfen, was Anwender tatsächlich tun können

Unauffällige Komponentenmesswerte können mit einem ausgefallenen Service einhergehen. Eine durchgängige Prüfung, etwa eine synthetische Transaktion, die sich alle 5 Minuten anmeldet und einen Testkauf abschließt, prüft ein Anwenderergebnis über mehrere Komponenten hinweg. Monitoring-Trends helfen anschließend dem Problem Management, Muster zu erkennen, und dem Service Level Management, über Verfügbarkeit und Leistung zu berichten.

Incident Management minimiert die negativen Auswirkungen von Incidents, indem es den normalen Service so schnell wie möglich wiederherstellt. Jeder Incident wird erfasst und anhand realistischer, vereinbarter und kommunizierter Erwartungen an die Lösung bearbeitet. Meldungen können von Anwendern, aus dem Monitoring, von Lieferanten oder Mitarbeitenden kommen.

Genug erfassen, damit andere handeln können

Ein brauchbarer Datensatz nennt die betroffenen Personen und ihre Erreichbarkeit, den Service und relevante Konfigurationselemente, den Erkennungszeitpunkt und die Symptome. Er enthält außerdem Kategorie, Auswirkung, Dringlichkeit, Priorität, zugewiesene Gruppe, Aktionen und Lösung. Verknüpfungen mit zugehörigen Changes, Problemen, bekannten Fehlern und Wissensartikeln verhindern wiederholte Untersuchungen.

Zum Beispiel: „Seit 09:40 Uhr können Lagerscanner am Nordstandort keine Lieferbestätigungen hochladen; etwa 30 Mitarbeitende sind betroffen.“ Das vermittelt dem nächsten Mitarbeitenden die Auswirkung auf den Service, einen Ort, eine Zeit und das Ausmaß. Erfasse spätere Erkenntnisse und Aktionen während der Bearbeitung, damit der Verlauf brauchbar bleibt.

Kategorisierung gruppiert Incidents nach Art, etwa „Netzwerk > WLAN“ oder „Anwendung > Gehaltsabrechnung“. Eine korrekte Kategorie leitet die Arbeit an Personen mit den richtigen Fähigkeiten weiter und unterstützt eine zuverlässige Trendanalyse. Eine falsche Einordnung kann sowohl heute Verzögerungen als auch später irreführende Problemdaten verursachen.

Entscheiden, was zuerst Aufmerksamkeit braucht

Die Auswirkung beschreibt den geschäftlichen Effekt: betroffene Anwender, Bedeutung des Services und finanzielle, rechtliche oder sicherheitsbezogene Folgen. Die Dringlichkeit beschreibt, wie schnell der Schaden wächst oder wie bald der Service wiederhergestellt sein muss. Die Priorität verbindet beides, um die Reihenfolge der Arbeit festzulegen.

Organisationen definieren ihre eigenen Matrizen. Hier ist ein verbreitetes Beispiel mit fünf Stufen:

Ein Ausfall des Bezahlvorgangs in einem Geschäft, der an einem Aktionstag alle Kunden betrifft, hat eine hohe Auswirkung und eine hohe Dringlichkeit und erhält in dieser Matrix Priorität 1. Ist die Gehaltsabrechnung für das Personalteam nicht verfügbar und steht morgen ein Abrechnungslauf an, ergibt sich bei mittlerer Auswirkung und hoher Dringlichkeit Priorität 2. Ein flackernder zweiter Monitor bei verfügbarem Ersatzgerät hat eine niedrige Auswirkung und eine niedrige Dringlichkeit und erhält Priorität 5.

Eine ranghohe anrufende Person kann ein dringendes geschäftliches Anliegen haben, doch Rang und Lautstärke der Beschwerden bestimmen nicht die Priorität. Frag, welche Arbeit blockiert ist und wann die Folgen schwerwiegend werden. Wende auf diese Fakten die vereinbarte Matrix an.

Reaktion und Wiederherstellung unterscheiden

Angenommen, für einen Incident der Priorität 2 gelten die Ziele, innerhalb von 30 Minuten zu reagieren und ihn innerhalb von 4 Stunden zu lösen. Ein um 13:10 Uhr eröffneter Datensatz wird um 13:25 Uhr bestätigt und zugewiesen: Die Reaktion dauert 15 Minuten. Wird der Service um 16:40 Uhr wiederhergestellt, ergibt sich eine Lösungszeit von 3 Stunden und 30 Minuten. Beide Ziele sind erreicht und messen unterschiedliche Meilensteine.

Incidents mit geringer Auswirkung müssen effizient bearbeitet werden; Incidents mit hoher Auswirkung benötigen möglicherweise zusätzliches Personal und Aufmerksamkeit durch das Management. Ein Incident-Modell gibt vordefinierte Schritte für eine bekannte Incident-Art vor, etwa wenn ein Drucker offline geht, einschließlich Prüfungen und Zuweisung. Es spart Zeit, ohne die Prioritätsentscheidung für jede neue Situation vorwegzunehmen.

Die Person, die einen Incident erfasst, ist möglicherweise nicht dieselbe, die den Service wiederherstellt. Anwender, Mitarbeitende am Service Desk, Fachleute, Lieferanten und temporäre Teams können alle dazu beitragen. Klare Verantwortung und brauchbare Übergaben halten die Arbeit in Gang, während der Anwender einen verlässlichen Ansprechpartner hat.

Die richtige Hilfe hinzuziehen

Mehrstufiger Support gruppiert die Arbeit nach Fachkenntnissen. Eine verbreitete Struktur ordnet den Service Desk Stufe 1, Netzwerk- oder Anwendungsfachleute Stufe 2 und hoch spezialisierte Fachleute, Entwickler oder Lieferanten Stufe 3 zu. Organisationen wählen ihre Struktur und Nummerierung selbst.

Swarming verringert Wartezeiten und wiederholte Übergaben, wenn die Zuständigkeit anfangs unklar ist. Ziehe relevante Personen hinzu und entlasse sie aus der Zusammenarbeit, sobald ihr Beitrag nicht mehr benötigt wird. Der Gesamtaufwand hängt davon ab, wie das Swarming organisiert wird; viele Personen an einem einfachen Incident arbeiten zu lassen, verschwendet Zeit.

Nutze bei der Untersuchung Wissensartikel, bekannte Fehler, Monitoring und Datensätze kürzlich durchgeführter Changes. Eine brauchbare Übergabe nennt den betroffenen Service, was bereits versucht wurde und was dabei geschah. Wird das Ticket ohne diese Informationen neu zugewiesen, kommt es leicht zu wiederholter Arbeit. Ein Verantwortlicher bleibt bis zum Abschluss zuständig, auch wenn die zugewiesene technische Gruppe wechselt.

Die Lösung am Service beurteilen

Lösung bedeutet, dass der normale Service wiederhergestellt ist. Das kann durch eine dauerhafte Fehlerbehebung oder einen Workaround geschehen. Angenommen, ein ausgefallener Druckserver verhindert das Drucken von Gehaltsabrechnungen. Stufe 2 leitet die Aufträge innerhalb von 25 Minuten auf einen Ersatzserver um. Anwender können wieder drucken, der Incident ist also gelöst, während das Problem Management untersuchen kann, warum der erste Server ausgefallen ist.

Ein Neustart, nach dem Anwender weiterhin nicht drucken können, hat den Incident nicht gelöst. Ihn als gelöst zu markieren, um ein Ziel einzuhalten, führt nur zu irreführenden Berichten und wieder geöffneten Tickets. Überprüfe das Ergebnis für den Service anhand einer Bestätigung durch den Anwender und geeigneter Serviceprüfungen.

Anwender informieren und den Datensatz abschließen

Vereinbare Abstände für Informationen und verwende einfache Sprache. Zum Beispiel: „Die Druckaufträge werden auf einen anderen Server umgeleitet. Voraussichtlich funktioniert das Drucken bis 14:30 Uhr wieder; wir bestätigen das, sobald es so weit ist.“ Erkläre die Auswirkung auf den Service, die Aktion und wann die nächste Information folgt, ohne Anwender technische Protokolle auswerten zu lassen.

Zum Abschluss gehören die Bestätigung, dass der Service für den Anwender funktioniert, eine dokumentierte Lösung, die korrekte abschließende Kategorie und Verknüpfungen zu zugehörigen Problemen oder bekannten Fehlern. Aktualisiere Wissensartikel, wenn sich aus dem Incident ein wiederverwendbarer Schritt ergibt. Manche Organisationen schließen einen gelösten Datensatz nach einer festgelegten Frist, etwa 3 Arbeitstagen, wenn der Anwender nicht antwortet; die Abschlussregel ist Teil des vereinbarten Prozesses.

Meldungen über vermutete Schadsoftware, kompromittierte Konten oder Datenlecks können beim selben Service Desk eingehen. Erfasse die Meldung und übergib sie an den dafür vorgesehenen Prozess der Organisation zur Reaktion auf Sicherheitsvorfälle. Bei Katastrophen werden die Wiederherstellungspläne der Organisation aktiviert.

Ein Major Incident hat so erhebliche geschäftliche Auswirkungen, dass er eine eigene, koordinierte Reaktion benötigt. Die Organisation legt ihre Kriterien fest. Ein weitreichender Ausfall für Kunden oder ein Ausfall des Zahlungssystems kann darunterfallen, und Major Incidents entsprechen üblicherweise der höchsten Priorität.

Anhand der Auswirkung ausrufen und die Reaktion koordinieren

Warte nicht, bis die Ursache bekannt ist, bevor du einen Major Incident ausrufst. Das Ausrufen gibt der Organisation die Möglichkeit, die richtigen Personen zusammenzubringen, während die Untersuchung weiterläuft. Zeigen spätere Erkenntnisse eine geringere Auswirkung, kann der Incident herabgestuft werden.

Ein namentlich benannter Major Incident Manager koordiniert Prioritäten, Aktionen und Entscheidungen. Fachleute, Lieferanten und Vertreter des Fachbereichs können ein temporäres Team für die Reaktion bilden. Das ist Swarming in größerem Maßstab: Das Team arbeitet gemeinsam auf die Wiederherstellung hin, mit klarer Verantwortung für die Koordination.

Die Kommunikation braucht einen eigenen Verantwortlichen. Informiere Stakeholder in festen Abständen, etwa alle 30 Minuten. Ein Portalbanner oder eine Statusseite zeigt, dass das Problem bekannt ist, und verringert wiederholte Anrufe. Halte Informationen für den Fachbereich von der technischen Arbeitsbesprechung getrennt, damit sich die technischen Fachkräfte konzentrieren und Stakeholder klare Informationen erhalten können.

Den Zahlungsausfall verfolgen

Um 09:12 Uhr erkennt das Monitoring, dass jede Kartenzahlung an den Ladenkassen fehlschlägt. Die erste Filiale ruft um 09:15 Uhr an. Die Organisation ruft um 09:18 Uhr einen Major Incident aus und stellt bis 09:20 Uhr das Team zusammen.

Um 09:35 Uhr erhalten die Stakeholder die erste Information. Um 09:50 Uhr stellt das Team fest, dass um 09:00 Uhr ein Zertifikat am Zahlungs-Gateway erneuert wurde. Um 10:05 Uhr wird der Change zurückgerollt und Zahlungen funktionieren wieder. Die Wiederherstellung dauerte ab der Erkennung 53 Minuten:

Um 10:20 Uhr bestätigt das Monitoring einen stabilen Service; zu diesem Zeitpunkt wird die abschließende Information versendet. Diese spätere Bestätigung ist vom Wiederherstellungszeitpunkt 10:05 Uhr zu unterscheiden. Werden beide erfasst, sind der zeitliche Ablauf und die Service-Level-Berechnung nachvollziehbar.

Nach der Wiederherstellung lernen

Eine Incident-Nachbesprechung untersucht, was passiert ist, wie die Reaktion funktioniert hat und was verbessert werden sollte. Eine Nachbesprechung ohne Schuldzuweisungen fragt, welche technischen und organisatorischen Bedingungen den Ausfall ermöglicht haben. Menschen können fehlende Prüfungen und verwirrende Entscheidungen offener ansprechen, wenn die Besprechung Verbesserungen statt eines Schuldigen sucht.

Weise Verbesserungsmaßnahmen Verantwortlichen zu und lege fest, wie ihre Erledigung überprüft wird. Ein Major Incident ist außerdem ein wichtiger Auslöser für Problem Management, da eine Wiederholung schwerwiegende Auswirkungen haben könnte. Die Untersuchung kann über Change Enablement zu einer dauerhaften Fehlerbehebung führen. Service Level Management berichtet über den Ausfall im Verhältnis zu den vereinbarten Zielen, und Beziehungsmanagement erklärt den betroffenen Führungskräften des Fachbereichs die Auswirkung und den Plan zur Vermeidung einer Wiederholung.

Problem Management verringert die Wahrscheinlichkeit und Auswirkung von Incidents, indem es tatsächliche und mögliche Ursachen identifiziert und Workarounds und bekannte Fehler verwaltet. Es nutzt Erkenntnisse aus der Supportarbeit, um künftige Störungen weniger wahrscheinlich oder weniger aufwendig zu machen.

Eine andere Frage stellen

Die beiden Practices können gleichzeitig am selben Sachverhalt arbeiten. Mitarbeitende im Incident Management können einen Workaround anwenden, während Mitarbeitende im Problem Management die Bedingungen hinter dem Ausfall untersuchen. Ein erfolgreicher Workaround verschafft Anwendern Abhilfe, doch seine wiederholte Anwendung kostet weiterhin Zeit und die Ursache bleibt bestehen.

Problem Management hat drei Phasen: Problemidentifizierung, Problemsteuerung und Fehlersteuerung. Die Identifizierung findet eine Ursache oder ein Risiko, dessen Untersuchung sich lohnt. Die Problemsteuerung analysiert sie beziehungsweise es und dokumentiert Workarounds und bekannte Fehler. Die Fehlersteuerung verwaltet die ungelösten bekannten Fehler und bewertet dauerhafte Lösungen.

Mehrere Quellen für Belege nutzen

Incident-Trends zeigen wiederkehrende Symptome. Mitarbeitende am Service Desk und Anwender können Muster bemerken, die durch unterschiedliche Ticketbeschreibungen verborgen bleiben. Ein Major Incident kann schon nach einer einzigen Störung ein erhebliches Wiederholungsrisiko aufdecken. Lieferanten können Mängel bekannt geben; Entwickler, Tester und Projektteams können Zustände erkennen, bei denen Ausfälle wahrscheinlich sind, wenn ein Service breiter genutzt wird.

Reaktives Problem Management geht von bereits aufgetretenen Incidents aus. Proaktive Arbeit geht möglichen Ursachen nach, bevor ein Incident auftritt. Die Warnung eines Lieferanten, dass eine Firmware-Version ein Speicherleck hat, kann eine Untersuchung rechtfertigen, auch wenn lokale Anwender keine Ausfälle gemeldet haben. Wiederholte Warnereignisse können ein weiteres frühes Signal liefern.

Aus einem Muster einen Problemdatensatz machen

In 30 Tagen erfasst der Service Desk 14 Incidents mit der Beschreibung „VPN-Verbindung bricht nach dem Aufwachen des Laptops ab“. Jeder beansprucht etwa 25 Minuten Arbeitszeit am Service Desk:

Das sind etwa 5,8 Stunden, ohne die verlorene Zeit der Anwender mitzuzählen. Verknüpfe die Incidents mit einem Problemdatensatz, damit die Untersuchenden betroffene Geräte, Bedingungen und Zeitpunkte vergleichen können. Die einzelnen Incidents erfassen weiterhin jede Störung; das Problem verbindet die Belege für ihre gemeinsame Ursache.

Ein brauchbarer Problemdatensatz enthält die Beschreibung, betroffene Services und CIs, verknüpfte Incidents, einen Verantwortlichen, den Status, Analyseergebnisse und eine risikobasierte Priorität. Berücksichtige sowohl, wie wahrscheinlich weitere Incidents sind, als auch, wie stark sie den Service beeinträchtigen würden. Der seltene Ausfall eines kritischen Services kann ebenso Aufmerksamkeit verdienen wie ein häufiger geringfügiger Ausfall.

Für jeden Incident ein Problem zu eröffnen, erzeugt einen Rückstand ohne sinnvollen Untersuchungszweck. Eine einmalige Schwierigkeit mit einer offensichtlichen, geringfügigen Ursache benötigt möglicherweise keinen eigenen Problemdatensatz. Eine Wiederholung, eine erhebliche Auswirkung oder ein bedeutsamer möglicher Ausfall gibt einen stärkeren Grund für eine Untersuchung.

Die Problemsteuerung analysiert Probleme und dokumentiert Workarounds und bekannte Fehler. Die Priorität richtet sich nach dem Risiko für Services, damit dort untersucht wird, wo weitere Incidents am wahrscheinlichsten sind oder den größten Schaden anrichten.

Über die ausgefallene Komponente hinausblicken

Die vier Dimensionen helfen, die Analyse zu erweitern: Organisationen und Menschen, Informationen und Technologie, Partner und Lieferanten sowie Wertströme und Prozesse. Ein technischer Fehler kann mit einer Prozesslücke oder fehlendem Wissen zusammenhängen. Beispielsweise kann die Laptop-Einrichtung eine Energieeinstellung deaktivieren, die der Netzwerktreiber eines Lieferanten benötigt, während der Test des Standard-Images die Auswirkung nicht erkennt.

Nützliche Methoden untersuchen Belege aus verschiedenen Blickwinkeln:

• Die Fünf-Warum-Methode folgt einer Kette von Erklärungen zu Ursachen, gegen die Menschen vorgehen können. Der Name ist eine Aufforderung, tiefer zu suchen, und keine Vorgabe, nach genau fünf Fragen aufzuhören.
• Ein Ursache-Wirkungs-Diagramm, auch Ishikawa-Diagramm genannt, gruppiert mögliche Ursachen unter Überschriften wie Menschen, Prozess, Technologie und Lieferanten.
• Eine Zeitleiste ordnet Changes und Ausfälle zeitlich, damit das Team ihre Beziehung untersuchen kann.

Mögliche Ursachen müssen anhand von Belegen überprüft werden. Mehrere Bedingungen können zusammenwirken. Ein nützliches Ergebnis ist daher eine Erklärung, die eine Aktion ermöglicht, auch wenn es keine einzelne Grundursache gibt.

Eine Ursachenkette durchgehen

Ein Export für die Gehaltsabrechnung schlägt fehl, weil sein Stapelverarbeitungsauftrag die Zeitvorgabe überschreitet. Warum überschreitet er sie? Eine Datenbankabfrage dauert dreimal so lange wie üblich. Warum? Nach einem Upgrade fehlt ein Index. Warum fehlt er? Das Upgrade-Skript hat ihn nicht erneut erstellt. Warum wurde das Problem nicht entdeckt? Die Release-Checkliste enthält keine Prüfung der Datenbankleistung.

Diese Analyse weist auf technische Arbeit am Index und am Skript sowie auf eine Prozessverbesserung bei den Release-Prüfungen hin. Würde man bei der Zeitüberschreitung aufhören, blieben die Bedingungen bestehen, die eine Wiederholung ermöglichen. Auch wer bei „menschlichem Versagen“ aufhört, übersieht Prüfungen oder klarere Verfahren, die einen weiteren Fehler verhindern könnten.

Teilweise Abhilfe wiederverwendbar machen

Wenn keine vollständige Fehlerbehebung verfügbar ist, dokumentiere einen Workaround im Problemdatensatz. Gib Mitarbeitenden genügend Einzelheiten, um ihn einheitlich anzuwenden, und erkläre, wann er passt. Beim VPN-Problem des Laptops lautet die Aktion: „Öffne nach dem Aufwachen des Laptops die VPN-App und wähle ‚Erneut verbinden‘; das dauert etwa 20 Sekunden.“

Ein Workaround verringert die Auswirkung des Problems; er belegt nicht, dass die Ursache beseitigt wurde. Teile ihn in einer Wissensdatenbank oder Datenbank bekannter Fehler, damit Mitarbeitende im Incident Management betroffene Services schneller wiederherstellen können, manchmal schon beim ersten Kontakt.

Ein Problem wird zu einem bekannten Fehler, sobald es analysiert wurde und ungelöst bleibt. Die zugrunde liegende Ursache kann noch ungewiss sein und ein Workaround noch fehlen. Der Datensatz hält fest, was bisher bewertet und gelernt wurde. Würde man sowohl eine nachgewiesene Ursache als auch einen Workaround voraussetzen, bevor der bekannte Fehler geteilt wird, würden nützliche Informationen verzögert.

Incident-Datensätze liefern viele der Belege. Einheitliche Kategorien, Symptome, Aktionen und Ergebnisse helfen Analysten beim Vergleich von Fällen. Die Problemsteuerung gibt den Nutzen als verbessertes Wissen für den nächsten Incident zurück.

Die Fehlersteuerung verwaltet bekannte Fehler und identifiziert mögliche dauerhafte Lösungen. Sie hält die Kosten und Auswirkungen ungelöster Probleme sichtbar, damit Entscheidungen über Fehlerbehebungen aktuelle Belege berücksichtigen.

Aufwand und Nutzen vergleichen

Eine Lösung muss im Hinblick auf Kosten, Risiken und Nutzen gerechtfertigt sein. Berücksichtige den Aufwand für Tests und Ausrollen, die Auswirkungen der wiederholten Anwendung des Workarounds und die Zeit, die Anwender verlieren. Auch eine schnelle technische Fehlerbehebung kann ein Risiko für den Service mit sich bringen; eine längere Reparatur kann sich lohnen, wenn sie häufige Störungen beseitigt.

Der bekannte VPN-Fehler verursacht jeden Monat etwa 14 Incidents, die jeweils etwa 25 Minuten Arbeitszeit am Service Desk beanspruchen. Der aktualisierte Treiber benötigt 16 Stunden für Tests und das Ausrollen auf 600 Laptops.

1. Der monatliche Aufwand am Service Desk beträgt $14\times 25=350\text{ Minuten}$.
2. Der geplante Aufwand für die Fehlerbehebung beträgt $16\times 60=960\text{ Minuten}$.
3. Die Amortisationsdauer anhand der Zeit am Service Desk beträgt $960÷350\approx \mathrm{2,7}\text{ Monate}$.

Diese Schätzung vergleicht den einmaligen Aufwand für die Fehlerbehebung mit dem wiederkehrenden Aufwand am Service Desk. Die eingesparte Zeit der Anwender ist ein zusätzlicher Nutzen. Sie hilft, den Change zu rechtfertigen, während das Risiko seiner Umsetzung weiterhin bewertet werden muss.

Akzeptierte Fehler regelmäßig überprüfen

Eine Organisation kann einen bekannten Fehler akzeptieren, wenn eine dauerhafte Fehlerbehebung mehr kostet, als sie nutzt. Betrachte einen geringfügigen Anzeigefehler in einem Altsystem, das in 4 Monaten außer Betrieb genommen werden soll. Ist der Workaround einfach, kann die Entscheidung lauten, ihn bis zur Außerbetriebnahme beizubehalten.

Die Akzeptanz benötigt einen dokumentierten Fehler, einen brauchbaren Workaround und eine Überprüfung, ob die Entscheidung weiterhin gilt. Verzögert sich die Außerbetriebnahme oder wächst die Auswirkung auf Anwender, verändert sich die Abwägung. Die Fehlersteuerung bewertet die Auswirkung auf Kunden, die Verfügbarkeit und Kosten von Lösungen sowie die Wirksamkeit von Workarounds erneut. Wird ein wiederholt eingesetzter Workaround verbessert oder automatisiert, kann das den Aufwand verringern, während der dauerhafte Fehler bestehen bleibt.

Umsetzung autorisieren und Erfolg überprüfen

Problem Management identifiziert und begründet die Lösung. Change Enablement bewertet das Risiko und autorisiert einen Change, bevor die verantwortlichen Teams ihn umsetzen. Ein Problemdatensatz allein autorisiert kein Deployment in die Produktivumgebung.

Prüfe nach der Umsetzung, ob die Ursache oder ihre Auswirkung tatsächlich beseitigt wurde. Überprüfe zum Beispiel das Monitoring und passende Incidents über einen Zeitraum von 30 Tagen. Die Meldung eines erfolgreichen Deployments zeigt, dass eine Aktion abgeschlossen wurde; Incident-Trends zeigen, ob die Aktion das Problem gelöst hat.

Sobald die Belege das Ergebnis bestätigen, schließe das Problem und den bekannten Fehler ab und aktualisiere zugehörige Artikel oder nimm sie außer Gebrauch. Treten weiterhin Incidents auf, nutze die neuen Belege, um die Analyse oder Lösung erneut zu bewerten. Problem Management liefert auch Beiträge zur kontinuierlichen Verbesserung, wenn die Untersuchung Lücken in einem Prozess, den Fähigkeiten der Mitarbeitenden oder Lieferantenvereinbarungen aufdeckt.

Service Request Management bearbeitet vordefinierte, von Anwendern ausgelöste Anfragen wirksam und anwenderfreundlich, um die vereinbarte Servicequalität zu unterstützen. Anfragen sind ein normaler Teil der Bereitstellung, auch wenn ihre Erfüllung mehrere Personen oder Genehmigungen benötigt.

Häufige Anfragearten erkennen

Ein ausgefallener Laptop ist ein Incident, weil ein bestehender Service nicht mehr funktioniert. Eine vereinbarte Laptopbestellung ist eine Anfrage. Weder der Kanal noch die Formulierung entscheidet über die Art, sondern die Servicesituation.

Organisationen veröffentlichen Anfragearten üblicherweise in einem Servicekatalog auf einem Self-Service-Portal. Jedes Formular erfasst die für die Bereitstellung benötigten Angaben, etwa Anwender, Startdatum, Kostenstelle und genehmigende Führungskraft. Werden relevante Angaben bei der Einreichung erfragt, vermeidet das wiederholte Rückfragen, die die Wartezeit verlängern.

Anfrage und Change unterscheiden

Manche Anfragen benötigen einen Change an einem Service oder CI. Ein Standard-Change ist risikoarm, vorab autorisiert, gut verstanden und vollständig dokumentiert. Er folgt seinem genehmigten Verfahren, ohne dass für jede Anwendung eine neue Autorisierung nötig ist. Ein häufiges Beispiel ist die Aufnahme eines Anwenders in einen E-Mail-Verteiler.

Der Status der Anfrage und die Autorisierung des Changes beantworten unterschiedliche Fragen. Eine vordefinierte Kataloganfrage bleibt eine Serviceanfrage, wenn ihre Erfüllung einen Change benötigt, der einzeln bewertet werden muss. Behalte den Anfrage-Datensatz und verknüpfe die zur Erfüllung benötigte Arbeit des Change Enablements damit.

Ein Katalog bietet beispielsweise virtuelle Server an. Ein Anwender fragt eine Servergröße an, die über den zulässigen Bereich des Standard-Changes hinausgeht. Die Anfrage bleibt eine Serviceanfrage; die Erstellung durchläuft vor der Erfüllung Change Enablement. Die Aufnahme in einen Katalog autorisiert nicht jede mögliche Erstellung vorab.

Eine Anfrage nach etwas, das nicht vordefiniert ist, folgt einem anderen Weg. „Erstellt uns ein neues Kundenportal“ ist neue Nachfrage, über die als Produkt oder Projekt entschieden wird. Der Vorschlag, unbekannte Fernsteuerungssoftware auf allen Bürocomputern zu installieren, benötigt eine Change-Bewertung. Dass man dies im Alltag eine Anfrage nennt, macht es nicht zu einer vordefinierten Serviceanfrage.

Auf Feedback und häufige Nachfrage reagieren

Eine über den Anfrageweg eingegangene Beschwerde benötigt einen Verantwortlichen, der darauf reagieren kann. Wiederholte Beschwerden über Reaktionszeiten können das Service Level Management erreichen, während ein weitergehender Vertrauensverlust das Beziehungsmanagement erfordern kann. Das Erfassen des Feedbacks ist der Beginn der Bearbeitung, nicht ihr Abschluss.

Zähle Anfragearten, um herauszufinden, wo Standardisierung am meisten hilft. Zugriffsanfragen, Passwortzurücksetzungen und Gerätebestellungen machen oft einen großen Teil des Volumens aus. Wird für diese häufigen Arten ein definiertes Verfahren wiederverwendet, müssen Anwender und Mitarbeitende nicht jeden Fall als neue Gestaltungsaufgabe behandeln.

Ein Anfrage-Workflow definiert den Weg von der Einreichung bis zur Erfüllung: Schritte, Genehmigungen, Verantwortlichkeiten und das Ergebnis, das der Anwender erhält. Ähnliche Anfragearten können oft ein Workflow-Modell mit kleinen Änderungen wiederverwenden.

Genehmigungen dort einsetzen, wo sie Kontrolle bieten

Genehmigungsregeln hängen von der Anfrage ab. Eine Passwortzurücksetzung kann nach einer Identitätsprüfung ohne Genehmigung einer Führungskraft erfolgen. Ein Laptopkauf benötigt möglicherweise eine finanzielle Genehmigung. Für den Zugriff auf Gehaltsdaten kann eine Genehmigung der Informationssicherheit oder der Datenverantwortlichen nötig sein.

Richtlinien legen fest, welche Anfragen diese Entscheidungen benötigen und welche mit wenigen oder ohne Genehmigungen bearbeitet werden können. Wird jede Routineaktion an eine Führungskraft geschickt, verlängert das die Wartezeit, ohne die tatsächlichen Kontrollanforderungen der Anfrage zu berücksichtigen. Werden erforderliche Zugriffsgenehmigungen zugunsten der Geschwindigkeit weggelassen, entsteht ein anderer Fehler. Formuliere die Richtlinie ausdrücklich, bevor du den Ablauf automatisierst.

Die Anfrage für einen neuen Mitarbeitenden verfolgen

Eine einstellende Führungskraft reicht 10 Arbeitstage vor dem Eintrittstermin eine Anfrage ein. Das Formular erfasst die Rolle des Mitarbeitenden, den Eintrittstermin sowie den Geräte- und Zugangsbedarf.

• An Tag 1 bestätigt die Personalabteilung den Eintrittstermin und die Kontoerstellung läuft automatisch ab.
• An den Tagen 2–3 genehmigen Datenverantwortliche den Zugang zu Abteilungssystemen.
• An den Tagen 2–4 nimmt das Supportteam einen Laptop aus dem Bestand und richtet ihn ein.
• Vor dem Eintrittstermin werden die Geräte und der Zugang bereitgestellt und überprüft.

Einige Aktivitäten laufen parallel. Der Workflow zeigt dennoch ihre jeweiligen Verantwortlichen und Abhängigkeiten. Die Führungskraft verfolgt den Gesamtstatus anhand einer Anfrage, einschließlich jedes Schritts, der auf eine Genehmigung wartet.

Geschwindigkeit vorhersehbar machen

Veröffentliche Erfüllungszeiten, die die Organisation einhalten kann, etwa „Standard-Laptop: 3 Arbeitstage; Laptop außerhalb des Standards: 10 Arbeitstage“. Wartet ein Schritt, zeige, welche Entscheidung oder Information benötigt wird und wer dafür verantwortlich ist. Eine sichtbare Wartezeit gibt dem Anwender eine nützliche Erklärung zum Fortschritt.

Service Level Management vereinbart Ziele; der Service Desk übernimmt oft die Entgegennahme. Nützliche Kennzahlen sind die Erfüllung im Vergleich zum Ziel, der automatisch erbrachte Anteil, wegen fehlender Angaben zurückgegebene Anfragen und die Zufriedenheit. Viele zurückgegebene Formulare können auf unklare Fragen zu Beginn hinweisen, während langsame Genehmigungen eine Änderung der Richtlinie oder Weiterleitung nahelegen können.

Einen zuverlässigen Prozess automatisieren

Angenommen, 400 monatliche Anrufe zur Passwortzurücksetzung dauern jeweils etwa 8 Minuten. Eine sichere Self-Service-Zurücksetzung mit Mehrfaktorprüfung kann einsparen:

Das sind etwa 53 Stunden Arbeitszeit der Mitarbeitenden pro Monat, wenn alle diese Anrufe vermieden werden. Anwender können die Aktion außerdem jederzeit ausführen. Standardisiere die Schritte und die erforderliche Prüfung vor der Automatisierung, damit sie ein solides Verfahren wiederholt.

Manche Anwender reichen Anfragen als Incidents ein und hoffen auf schnelleren Service. Leite den Datensatz mit einer kurzen Erklärung und einer korrekten Erwartung an die Erfüllung weiter. Richtlinien und Workflows leiten auch Einreichungen weiter, die tatsächlich Incidents oder Changes sind. Ein verbesserter Anfrageweg verringert den Anreiz, das falsche Formular zu wählen, und hält Incident-Berichte brauchbar.

Service Level Management legt klare geschäftsbezogene Ziele fest und stellt sicher, dass die Bereitstellung anhand dieser Ziele bewertet, überwacht und gesteuert wird. Ein Service Level beschreibt die erwartete oder erreichte Qualität anhand einer oder mehrerer Kennzahlen. Ein Service Level Agreement (SLA) dokumentiert die benötigten Services und das erwartete Service Level, das Provider und Kunde vereinbart haben.

Bei der Arbeit des Kunden beginnen

Ein brauchbares SLA bezieht sich auf einen definierten Service im Katalog und auf definierte Ergebnisse. Es hält eine tatsächliche, durch Gespräche erzielte Vereinbarung fest und verwendet eine Sprache, die beide Parteien verstehen. Die Serververfügbarkeit allein zeigt möglicherweise nicht, ob Kunden während der Öffnungszeiten Bestellungen abschließen können.

Typische Inhalte sind Serviceumfang und -zeiten, Verfügbarkeit, Reaktions- und Lösungsziele für Incidents, Erfüllungszeiten für Anfragen, Supportkontakte, die Verantwortlichkeiten beider Parteien, Messung und Berichterstattung sowie die Häufigkeit der Überprüfung. Vereinbart, wie jede Kennzahl berechnet wird, damit Berichte dieselbe Grundlage wie die Zusage verwenden.

Zulässige Ausfallzeit berechnen

Verwende die vereinbarte Servicezeit als Nenner. Für einen Service, der 24 Stunden am Tag, 7 Tage die Woche erbracht wird, in einem Monat mit 30 Tagen:

Ein Verfügbarkeitsziel von 99,9 % erlaubt 0,1 % Ausfallzeit:

Die Verfügbarkeit ist der Anteil der vereinbarten Zeit, in dem der Service verfügbar ist:

Bei 50 Minuten Ausfallzeit beträgt die Verfügbarkeit etwa 99,88 %, das Ziel ist also verfehlt. Verwende das ungerundete Ergebnis, wenn du es mit einem Ziel vergleichst, das nahe am erreichten Wert liegt.

Bei Servicezeiten von Montag bis Freitag, 08:00 Uhr bis 18:00 Uhr, beträgt die vereinbarte Zeit über 22 Arbeitstage 220 Stunden oder 13.200 Minuten. Bei 99,5 % sind 66 Minuten Ausfallzeit zulässig. Ein Ausfall von 90 Minuten an einem Sonntag um 02:00 Uhr liegt außerhalb dieser vereinbarten Zeiten und zählt nicht gegen dieses Ziel. Ein Ausfall von 40 Minuten während der Servicezeit am Dienstag ergibt etwa 99,70 % und erfüllt damit das Ziel.

Die Zusage im Hintergrund unterstützen

Eine Wiederherstellungszusage von 4 Stunden benötigt unterstützende Vereinbarungen, die dieses Ergebnis ermöglichen. Ein Lieferant, der lediglich eine Fachkraft innerhalb von 8 Stunden vor Ort verspricht, kann allein mit dieser Zusage kein Wiederherstellungsziel von 4 Stunden unterstützen.

Organisationen können ein servicebasiertes SLA für einen Service und alle seine Kunden, ein kundenbasiertes SLA für die Services einer Kundengruppe oder eine mehrstufige Struktur mit unternehmensweiten, kundenbezogenen und servicebezogenen Bedingungen nutzen.

Die Berichterstattung zu Service Levels braucht einen umfassenden Blick auf die Bereitstellung. Operative Kennzahlen zeigen, was der Provider getan hat; Geschäftskennzahlen und Feedback zeigen, wie der Service die Arbeit des Kunden unterstützt hat.

Kennzahlen gemeinsam auswählen

Kundeneinbindung ermittelt Bedürfnisse durch Gespräche. Frag: „Welche Arbeit unterstützt Technologie?“, „Wann sind deine wichtigsten Geschäftszeiten?“ und „Wie misst du Erfolg?“ Kundenfeedback ergänzt Umfrageergebnisse und Kommentare nach Incidents, Anfragen und längeren Servicezeiträumen.

Zu den operativen Kennzahlen gehören Incident-Zahlen, Reaktionszeiten und Verfügbarkeit. Geschäftskennzahlen können etwa pro Stunde bearbeitete Bestellungen umfassen. Ihre Kombination kann eine Lücke zwischen technischer Leistung und einem nutzbaren Service aufdecken.

Der Wassermeloneneffekt beschreibt grüne Berichte bei zugleich rotem Kundenerlebnis. Zum Beispiel werden alle Lösungsziele und 99,95 % Verfügbarkeit erreicht, doch das Kundensystem benötigt am Quartalsende 12 Sekunden pro Bildschirmseite und die Zufriedenheit sinkt auf 2,1 von 5. Die Vereinbarung verfehlt eine wichtige Bedingung für einen brauchbaren Service. Besprecht die langsame geschäftliche Aufgabe und überarbeitet die Kennzahlen und Ziele anhand dieses Bedürfnisses.

Zielerfüllungsquote berechnen

Von 200 Incidents der Priorität 3 erfüllen 184 ein Lösungsziel von 8 Geschäftsstunden:

Beträgt die erforderliche Zielerfüllung 95 %, ist die Anzahl der Incidents, die das Ziel hätten erfüllen müssen:

Das Ziel wird um 6 Incidents verfehlt. Die Zielerfüllungsquote misst, wie viele Fälle ihr jeweiliges Ziel erreicht haben, während die Verfügbarkeit die Servicezeit misst. Beide haben unterschiedliche Nenner und sollten klar bezeichnet werden.

Die vereinbarte Zeitregel anwenden

Ein SLA legt fest, ob die Zeit in Geschäftsstunden oder Kalenderstunden zählt und ob bestimmte Wartezeiten die Uhr anhalten. Erfinde keine Pause, weil ein Ticket auf einen Anwender wartet; wende die vereinbarte Regel an.

Angenommen, die Servicezeiten sind von Montag bis Freitag, 08:00 Uhr bis 18:00 Uhr, und für die Lösung sind 8 Geschäftsstunden vorgesehen. Ein Incident am Freitag um 16:00 Uhr verbraucht 2 Stunden vor Geschäftsschluss. Die verbleibenden 6 Stunden beginnen am Montag um 08:00 Uhr, sodass die Frist am Montag um 14:00 Uhr endet. Das Wochenende verlängert die Kalenderzeit, verbraucht aber keine der vorgesehenen Geschäftsstunden.

Verhalten und Verbesserung überprüfen

Eine einzelne Kennzahl kann Abkürzungen begünstigen. Ist Geschwindigkeit das einzige Ziel, schließen Mitarbeitende möglicherweise ungelöste Tickets. Wiedereröffnungsquoten und Zufriedenheit helfen zu erkennen, ob ein schneller Abschluss eine tatsächliche Wiederherstellung widerspiegelte. Betrachte die Kennzahlen gemeinsam, bevor du entscheidest, dass sich ein Prozess verbessert hat.

Ein Service-Review bringt Provider und Kunde häufig monatlich oder vierteljährlich zusammen, um Leistung, Trends, bevorstehende Veränderungen und Verbesserungsmaßnahmen zu untersuchen. Zeige neben erfüllten oder verfehlten Zielen auch den Kontext: Verfügbarkeit, Bestellvolumen, Zufriedenheit und eine Erklärung zu verfehlten Zielen. Weise Maßnahmen zu und nutze das Review, um das SLA bei veränderten geschäftlichen Bedürfnissen zu aktualisieren. Die Erkenntnisse fließen auch in die kontinuierliche Verbesserung ein.

Beziehungsmanagement baut die Beziehungen zwischen der Organisation und ihren Stakeholdern auf strategischer und taktischer Ebene auf und entwickelt sie weiter. Es identifiziert und analysiert Beziehungen, überwacht, wie sie funktionieren, und verbessert sie im Laufe der Zeit.

Verstehen, wer was braucht

Eine Person kann mehr als eine Rolle innehaben, doch die Interessen müssen trotzdem untersucht werden. Identifiziere Bedürfnisse, Prioritäten und Einfluss. Ein Sponsor kann die Kosten betonen, während Anwender längere Supportzeiten wünschen. Das Verständnis beider Bedürfnisse gibt dem Provider eine Grundlage, um Zielkonflikte zu besprechen.

Zu den Beziehungsaktivitäten gehören das Lösen widersprüchlicher Anforderungen, die Überwachung der Zufriedenheit, die Bearbeitung von Beschwerden und Eskalationen und die Unterstützung von Stakeholdern dabei, zu verstehen, wie sie Wert aus Services ziehen können. Sie helfen außerdem, Produkte und Services entsprechend den geschäftlichen Bedürfnissen zu priorisieren.

Pläne teilen, bevor sie dringend werden

Ein Business Relationship Manager dient oft als ranghoher Ansprechpartner für einen größeren Geschäftsbereich. Er versteht die Pläne des Bereichs, vertritt dessen Bedürfnisse gegenüber dem Provider und erklärt die Fähigkeiten und Einschränkungen des Providers.

Bei einem vierteljährlichen Gespräch teilt das Marketing mit, dass eine Kampagne in zwei Monaten voraussichtlich das Fünffache des üblichen Website-Verkehrs anziehen wird. Der Business Relationship Manager gibt dies an die Kapazitätsteams und das Service Level Management weiter. Der Provider kann zusätzliche Kapazität vorbereiten und die Erwartungen an den Service besprechen, bevor die Kampagne beginnt.

Die nützliche Information ist mehr als eine Prognosezahl. Sie umfasst, wann die Nachfrage auftreten wird und warum sie wichtig ist. So können technische Arbeit und Zielgespräche dasselbe geschäftliche Ereignis unterstützen. Wartet man bis zum Starttag, wird aus einem vorhersehbaren Bedarf ein dringendes Problem.

Vertrauen mit messbaren Zusagen verbinden

Beziehungsmanagement kümmert sich um die Partnerschaft insgesamt, das Vertrauen und die strategische Ausrichtung. Service Level Management behandelt konkrete Serviceziele und deren Messung. Ein regelmäßiges Gespräch kann ein Bedürfnis aufdecken; die Arbeit am Service Level kann es in eine vereinbarte Zusage mit geeigneten Kennzahlen umsetzen.

Eine gute Beziehung ermöglicht eine ehrliche Diskussion über Grenzen und Servicekosten. Zuverlässige Bereitstellung stärkt dieses Vertrauen. Beide Parteien tragen bei: Der Kunde teilt Pläne rechtzeitig, und der Provider erklärt die Ressourcen, die für ein vorgeschlagenes Service Level benötigt werden. Das ist gemeinsame Wertschöpfung in der praktischen Supportarbeit.

Wer den Fachbereich nur bei Ausfällen kontaktiert, erfährt nichts von Plänen und Anliegen. Halte geplanten Kontakt auch dann aufrecht, wenn der Service gut läuft. Beschwerden, die eine beschädigte Beziehung offenlegen, benötigen ein Gespräch und konsequente weitere Bearbeitung; ihre Leistungsdetails können außerdem Informationen für das nächste Service-Review liefern.

Ein Wertstrom ist eine Folge von Schritten, durch die eine Organisation Produkte und Services für Konsumenten erstellt und bereitstellt. Ein Support-Wertstrom kombiniert Practices um ein Ergebnis herum, etwa die Wiederherstellung des Services eines Anwenders. Er kann die Aktivitäten Einbinden, Bereitstellen und Unterstützen sowie Verbessern der Wertschöpfungskette einbeziehen.

Erkennen, koordinieren und wiederherstellen

Um 08:55 Uhr warnt das Monitoring, dass die Warteschlange ausgehender E-Mails wächst. Um 09:05 Uhr überschreitet sie den Ausnahmeschwellenwert und ein Incident wird erstellt. Von 09:10 Uhr bis 09:30 Uhr erhält der Service Desk 25 Anrufe, verknüpft die Kontakte mit dem Incident und veröffentlicht ein Portalbanner.

Das Messaging-Team leitet die E-Mails um 09:40 Uhr über ein Ersatz-Gateway um. Der normale E-Mail-Service funktioniert wieder, der Incident ist also nach 35 Minuten gelöst. Der Workaround stellt die Zustellung wieder her, während das Problem Management die Ursache noch untersuchen muss.

Werden viele Anwendermeldungen mit einem übergeordneten Incident verknüpft, bleibt die Auswirkung sichtbar, ohne dass 25 separate Wiederherstellungsarbeiten entstehen. Jeder Anwender kann über die verknüpften Datensätze Informationen zum Fortschritt erhalten. Die Incident-Berichterstattung kann eine Servicestörung und viele betroffene Anwender zeigen, während die Anzahl der Kontakte weiterhin den Arbeitsaufwand des Service Desks beschreibt.

Untersuchen und eine Wiederholung verhindern

Ein Problemdatensatz führt die Incident-Belege zusammen. Die Analyse ergibt, dass die automatische Erneuerung eines Sicherheitszertifikats fehlgeschlagen ist und kein Alarm dies erkannt hat. Das analysierte, ungelöste Problem wird als bekannter Fehler mit dem Ersatz-Gateway als Workaround erfasst.

Ein korrigierter Erneuerungsauftrag und die Überwachung der Erneuerung bilden die vorgeschlagene dauerhafte Lösung. Der Change durchläuft vor der Umsetzung Change Enablement, und das Ergebnis wird überprüft. Incident Management liefert die Belege zur Störung; Problem Management liefert die Analyse und die Arbeit zur Vorbeugung.

Über die Auswirkung auf den Service berichten und sie erklären

Für einen Service, der 24 Stunden am Tag, 7 Tage die Woche vereinbart ist, beträgt der vereinbarte Zeitraum in einem Monat mit 30 Tagen 43.200 Minuten. Bei 35 Minuten Ausfallzeit:

Das Verfügbarkeitsziel von 99,9 % ist erreicht. Dieses Ergebnis beschreibt die Einhaltung der vereinbarten Kennzahl. Der Business Relationship Manager erklärt der Finanzleitung dennoch die Störung und den Plan zur Vermeidung einer Wiederholung. Die Erfüllung eines Monatsziels ersetzt nicht die Auseinandersetzung mit der geschäftlichen Auswirkung eines bestimmten Ausfalls.

Eine Anfrage nach einem neuen gemeinsamen Postfach, die am selben Morgen eingeht, bleibt in ihrem Serviceanfrage-Workflow. Die Trennung verhindert, dass der Ausfall die Anfragezahlen verzerrt oder aus regulärer Nachfrage Incident-Arbeit wird.

Arbeit an den Übergaben verknüpfen

Ein Ereignis erfordert Incident Management, wenn der Service betroffen ist. Ein wiederkehrender Incident oder ein Major Incident kann Problemarbeit auslösen. Eine gerechtfertigte dauerhafte Fehlerbehebung kann einen Änderungsantrag benötigen. Auch eine vordefinierte Serviceanfrage kann einen verknüpften Change benötigen, wenn die Aktion zur Erfüllung einzeln autorisiert werden muss. Beschwerden können das Service Level Management oder das Beziehungsmanagement erreichen.

Eine Practice ist eine Zusammenstellung von Ressourcen und Fähigkeiten, keine Abteilung. Ein Mitarbeitender kann einen Incident erfassen, eine Anfrage erfüllen und ein wiederkehrendes Muster erkennen. Korrekte Kategorien, Datensatzverknüpfungen und klare Verantwortliche ermöglichen diesen Aktivitäten, dasselbe Ergebnis für den Anwender zu unterstützen.

Guter Support macht eine bewährte Lösung leicht auffindbar und sicher wiederholbar. Wissen, Self-Service und Automatisierung verlagern geeignete Arbeit näher an den Anwender und geben Mitarbeitenden mehr Zeit für komplexe Fälle.

Wissen nutzbar halten

Eine Wissensdatenbank enthält Anleitungen, Standardschritte zur Lösung und Workarounds. Ein brauchbarer Artikel ist kurz, verwendet die Worte der Anwender und hat einen Verantwortlichen und einen Überprüfungstermin. Zum Beispiel nennt „VPN-Verbindung bricht nach dem Aufwachen deines Laptops ab: schnelle Lösung“ das Symptom, nach dem ein Anwender wahrscheinlich sucht. Aktualisiere Artikel nach der Nutzung, damit der nächste Leser von den gewonnenen Erkenntnissen profitiert.

Self-Service ermöglicht Anwendern, Wissen zu durchsuchen, Kataloganfragen einzureichen und den Ticketstatus zu verfolgen. Chatbots und virtuelle Assistenten können häufige Fragen beantworten oder einfache Workflows ausführen. Ein klarer Weg zu einer Person bleibt verfügbar, wenn der automatisierte Weg nicht helfen kann.

Shift-Left verlagert geeignete Lösungen näher an den Anwender, etwa von Stufe 2 zu Stufe 1 oder vom Service Desk zum Self-Service. Verlage eine Fehlerbehebung, wenn sie dort einfach und sicher genug anzuwenden ist und das für diesen Einsatz nötige Wissen und die erforderlichen Kontrollen vorhanden sind. Der Nutzen entsteht durch weniger Wartezeit und geringeren Supportaufwand.

Dafür geeignete Arbeit automatisieren

Automatisierung kann Datensätze klassifizieren und weiterleiten, aus Ereignissen Incidents erstellen, definierte Reaktionen ausführen, Standardanfragen erfüllen und aktuelle Informationen versenden. Vereinfache und standardisiere zuerst den Prozess. Sind Weiterleitungsregeln falsch, schickt ihre Automatisierung mehr Datensätze schneller an die falsche Stelle.

KI-Werkzeuge können Kategorien vorschlagen, Antworten entwerfen, lange Verläufe zusammenfassen und Gruppen ähnlicher Incidents erkennen. Menschen bleiben für Prioritäten, Genehmigungen und Nachrichten an Anwender verantwortlich. Deshalb prüfen Mitarbeitende Vorschläge, bevor sie danach handeln. Tickets können personenbezogene Daten enthalten; nutze diese Werkzeuge entsprechend den Datenschutzregeln der Organisation.

Die Veränderung der Nachfrage beim Service Desk berechnen

Ein Service Desk erhält monatlich 2.000 Kontakte, darunter 600 zu Passwortzurücksetzungen und einfachen Anwendungsfragen. Ein Portal und ein Chatbot lösen 450 davon ohne Kontakt zum Service Desk. Es verbleiben:

Der Rückgang der gesamten Nachfrage beim Service Desk beträgt:

Würde man 600 als Nenner verwenden, beschriebe das den Anteil dieser ausgewählten einfachen Kontakte, die durch Self-Service bearbeitet wurden: eine andere Kennzahl. Mitarbeitende können die frei gewordene Zeit für komplexe Incidents und die Identifizierung von Trends nutzen.

Erfolg über Portalzugriffe hinaus prüfen

Ein stark genutztes Portal kann erfolgreiche Selbsthilfe oder wiederholte erfolglose Suche widerspiegeln. Untersuche den Anteil der Self-Service-Sitzungen, nach denen der Anwender den Service Desk nicht wegen desselben Anliegens kontaktieren musste. Kombiniere dieses Ergebnis mit Anwenderfeedback und der Qualität der Ergebnisse.

Ein Chatbot, der den Zugang zu einer Person blockiert, kann die Zahl der erfassten Anrufe verringern, während der Anwender nicht weiterkommt. Ein brauchbarer automatisierter Weg liefert ein Ergebnis und übergibt den Kontext, wenn menschliche Hilfe benötigt wird.