Der Service Desk ist die zentrale Schnittstelle zwischen Anwendern und Service-Provider-Organisationen. Anwender wenden sich an den Service Desk, wenn sie etwas ben\u00f6tigen, und ihre Produktivit\u00e4t h\u00e4ngt davon ab, dass der Service Desk wirksame und zeitnahe Unterst\u00fctzung bietet. Um diese Unterst\u00fctzung leisten zu k\u00f6nnen, st\u00fctzen sich Service-Desk-Mitarbeitende h\u00e4ufig auf ein Netzwerk anderer Teams, um n\u00fctzliche Informationen zu erhalten und Probleme nachzuverfolgen, um die Servicequalit\u00e4t insgesamt zu verbessern \u2013 dies ist Teil eines wesentlich umfassenderen Probleml\u00f6sungsprozesses. Auch wenn die meisten Service-Desk-Mitarbeitenden ein gewisses Verst\u00e4ndnis davon haben, wie Probleml\u00f6sung funktioniert, finden Sie hier 5 Fakten zur Probleml\u00f6sung, die sie m\u00f6glicherweise nicht kennen und die dazu beitragen k\u00f6nnen, die Leistung Ihres Service Desk zu verbessern. <\/p>\n
Technisch versierte Personen neigen dazu, Dinge l\u00f6sen zu wollen; entscheidend ist jedoch, auf das zu reagieren, was Anwender und Unternehmen ben\u00f6tigen. Der Aufstieg der Erstkontaktl\u00f6sung (First Contact Resolution, FCR) als Kennzahl kann dieses Verhalten mitunter f\u00f6rdern, obwohl Anwender oft nur das wichtige Vorhaben abschlie\u00dfen m\u00f6chten, das sie begonnen haben \u2013 was sich manchmal eleganter und schneller mit einem gut gew\u00e4hlten Workaround erreichen l\u00e4sst. <\/p>\n
Problemmanagement und Risikomanagement haben vieles gemeinsam, darunter einen starken Fokus auf den Return on Investment (ROI). Jedes Problem, das im Rahmen des Probleml\u00f6sungsprozesses identifiziert wird, hat eine prognostizierte Auswirkung auf die Organisation sowie eine Einsch\u00e4tzung der Wahrscheinlichkeit und H\u00e4ufigkeit, mit der das Problem k\u00fcnftig auftreten wird. Jede Problemuntersuchung verursacht Kosten; hinzu kommen die Kosten f\u00fcr die Umsetzung der L\u00f6sung (die Investition). Viele Probleme erfordern Investitionen, die den potenziellen Nutzen \u00fcbersteigen; das sind Probleme, die nicht gel\u00f6st werden sollten. <\/p>\n
Wenn ein Service Desk den Support f\u00fcr ein System \u00fcbernimmt, das entweder k\u00fcrzlich ver\u00f6ffentlicht wurde oder von einem anderen Service Desk \u00fcbergeben wird, kann man davon ausgehen, dass das System eine Reihe bestehender Probleme mitbringt, die bereits jemandem bekannt sind. Bei neuen Systemen (oder aktuellen Releases) verf\u00fcgt das Entwicklungsteam wahrscheinlich \u00fcber Listen mit Designentscheidungen, technischen Annahmen, Themen, Risiken und Defekten, die vor der Ver\u00f6ffentlichung identifiziert, aber nicht vollst\u00e4ndig behoben wurden. Wenn das System von einem anderen Support-Team oder einer anderen Service-Desk-Funktion an den Service Desk \u00fcbergeht, liefern FAQs, Troubleshooting-Guides und Problemmanagement-Aufzeichnungen Listen bekannter Probleme. All dies sind potenzielle Probleme, auf die der Service Desk sto\u00dfen kann. Im Rahmen des Wissenstransfers an den Service Desk sollten Service Manager diese bekannten Probleme erfassen, damit die Informationen erhalten bleiben und nicht verloren gehen. <\/p>\n
Es ist g\u00e4ngige Praxis, Self-Service- und automatisierte Support-Funktionen zu nutzen, damit Anwender Anfragen und Incidents ohne die Personalkosten von Service-Desk-Mitarbeitenden l\u00f6sen k\u00f6nnen. Auch wenn dies eine wirksame Methode zur Vermeidung operativer Kosten sein und dem Service Desk Geld sparen kann, f\u00fchrt Self-Service-Support nicht dazu, dass die Probleme verschwinden, und er erm\u00f6glicht Ihrer ITSM-Funktion auch nicht, die Services f\u00fcr den Anwender zu verbessern. Im Gegenteil: Self-Service-Incident-L\u00f6sung ermutigt Service Desk und Service Owner dazu, zugrunde liegende Serviceprobleme zu ignorieren, was letztlich zu geringerer Servicequalit\u00e4t und h\u00f6heren Gesamtkosten f\u00fcr die Organisation f\u00fchrt. <\/p>\n
Informationen k\u00f6nnen fl\u00fcchtig sein: manchmal existieren sie nur im Ged\u00e4chtnis des Anwenders, der gesehen hat, was passiert ist; oder Logfiles und andere \u00fcberwachte Daten bleiben nur Stunden oder Minuten erhalten oder werden durch einen Neustart gel\u00f6scht. Dennoch geh\u00f6ren \u201erestart\u201c, \u201ereboot\u201c, \u201ereload\u201c und \u201etry again later\u201c zu den h\u00e4ufigsten Anweisungen zur Incident-L\u00f6sung, die Service-Desk-Mitarbeitende Anwendern geben. Auch wenn diese Techniken wirksam sein k\u00f6nnen, um die Auswirkungen des Incidents zu mindern und den Service schnell wiederherzustellen, ist die unbeabsichtigte Folge h\u00e4ufig die Zerst\u00f6rung von Umgebungsbedingungen, Kontextdaten und System-Log-Informationen, die als wesentliche Diagnosewerkzeuge zur Identifizierung und Behebung zugrunde liegender Probleme dienen. Bevor Service-Desk-Mitarbeitende eine dieser destruktiven Empfehlungen aussprechen, sollten sie kurz innehalten und pr\u00fcfen, ob es diagnostische Informationen gibt, die zuerst erfasst werden k\u00f6nnten und\/oder sollten, um den Probleml\u00f6sungsprozess zu unterst\u00fctzen. <\/p>\n
Gleichzeitig sollten wir uns bem\u00fchen, Informationen zu erfassen, die sp\u00e4ter nur schwer oder gar nicht mehr zu bekommen sind: den genauen Zeitpunkt, zu dem der Anwender das Problem erstmals bemerkt hat, und ebenso wichtig den letzten Zeitpunkt, zu dem der Anwender diese Funktion noch erfolgreich nutzen konnte.<\/p>\n
Service-Desk-Anrufe bedeuten stets eine Beeintr\u00e4chtigung des normalen Betriebs von Anwendern und Gesch\u00e4ftsprozessen und sind daher Probleme, die erfasst und adressiert werden sollten. Ob es bei dem Anruf um eine Zugriffsanfrage, Anleitungen zur Vorgehensweise, einen Change Request, die Meldung eines Bugs oder die Information des Support-Teams \u00fcber einen Systemausfall geht \u2013 der Anwender hat seine normale Arbeit unterbrochen, um mit dem Service Desk in Kontakt zu treten. Probleme beziehen sich nicht nur auf Incidents; sie bestehen immer dann, wenn ein Anwender das, was er gerade tut, unterbrechen und einem separaten Prozess folgen muss, bevor er fortfahren kann. Jede SD-Interaktion nach Verbesserungsm\u00f6glichkeiten zu durchforsten, geschieht bereits, da Unternehmen die Informationen aus jedem Kanal (E-Mail\/Chat\/Social Media\/Telefon) zusammenf\u00fchren. <\/p>\n
Noch wichtiger wird es sein, dass vermittelte Interaktionen (also solche, bei denen es einen Dialog mit dem Anwender gibt) nach Best-in-Class-Ans\u00e4tzen gesteuert werden. Das wird deutlich schnellere Fortschritte bei der Automatisierung dessen erm\u00f6glichen, was automatisiert werden sollte: Zugriffsanfragen, die in Onboarding-Prozesse integriert werden k\u00f6nnen; Benutzeroberfl\u00e4chen, die intuitiver gestaltet sind und keine Anleitungen erfordern; Feedback- und Change-Request-Mechanismen, die in Systeme eingebettet sind; sowie besseres Monitoring, das die Notwendigkeit eliminiert, dass Anwender melden m\u00fcssen, wenn ein System nicht funktioniert. <\/p>\n
Der Service Desk ist in vielen Organisationen eine untersch\u00e4tzte Ressource und wird f\u00fcr Routing und Routineanfragen genutzt. Seine Rolle dabei, Daten zu erfassen, die Diagnose und L\u00f6sung unterst\u00fctzen, muss anerkannt und gest\u00e4rkt werden; schon das Verst\u00e4ndnis, wie der Service Desk mit jedem pr\u00e4zisen Datenpunkt Mehrwert schafft, kann dazu beitragen, die Leistung zu steigern. <\/p>\n