IT-Helpdesk-Prozess: Flussdiagramm für Störungen und Anfragen

Was ist it-helpdesk-prozess: flussdiagramm für störungen und anfragen?

Ein IT-Helpdesk-Prozess beschreibt, wie ein Service Desk seinen Tag organisiert: eine Eingangstür für jeden Anwenderkontakt, unabhängig vom Kanal, und ein vereinbarter Weg von diesem Kontakt bis zum geschlossenen Ticket. Von einer Einzweckvorschrift unterscheidet ihn, dass er zwei Arten von Arbeit gleichzeitig trägt. Manche Tickets sind Störungen: Etwas, das funktionieren sollte, tut es nicht. Andere sind Serviceanfragen, bei denen nichts kaputt ist und die anfragende Person eine vereinbarte Standardleistung möchte: eine Lizenz, einen neuen Laptop, eine Software. Beide brauchen unterschiedliche Uhren und häufig unterschiedliche Freigebende, deshalb trennt der Prozess sie früh, statt eine gemeinsame Warteschlange alles wie einen Ausfall behandeln zu lassen.

Diese Seite zeigt den Betriebsablauf des Desks, nicht die Innereien eines einzelnen Zweigs. Wenn Sie die Ausrufung eines Major Incident, einen benannten Incident Manager, Krisentelefonate und die Eskalation bei SLA-Verletzung brauchen, gehört dieser Detailgrad in den Incident-Management-Prozess. Ein Verdacht auf Kompromittierung folgt stattdessen dem Incident-Response-Prozess für Sicherheitsvorfälle. Eine Lösung, die einen laufenden Service verändert, übergibt an das Change Management, und ein Antrag auf Systemzugriff folgt dem Zugriffsantrag mit eigener Freigabekette und turnusmäßiger Rezertifizierung. Ursachenanalyse verlässt diesen Prozess ganz: Der Zweig für wiederkehrende Probleme legt einen Problem-Datensatz an, statt das Ticket des Anwenders offen zu halten, während jemand ermittelt.

Das Diagramm zeichnet fünf Bahnen (Anwender, Service Desk, Second Level Support, Asset und Beschaffung sowie Problemmanagement) über fünf Phasen vom Kontakt bis zum Abschluss. Es macht zwei Dinge sichtbar, die Desks meist undokumentiert lassen: die Prüfung der Wissensdatenbank, die entscheidet, ob der First Level eine dokumentierte Lösung anwendet oder von Grund auf diagnostiziert, und den Beschaffungszweig, der klärt, ob ein Artikel aus dem Lager ausgegeben oder bestellt wird. Und es endet dort, wo die meisten schriftlichen Verfahren aufhören: bei der Bestätigung durch den Anwender und einem Zweig zum Wiederöffnen, falls das Problem weiterbesteht.

Was dieses Flussdiagramm abdeckt

In dieser Vorlage

• Fünf Swimlanes mit einem Verantwortlichen je Schritt (Anwender, Service Desk, Second Level Support, Asset und Beschaffung sowie Problemmanagement) über fünf Phasen: Kontakt, Erfassung und Triage, First Level, Eskalation und Erfüllung sowie Lösung und Abschluss
• Kanalunabhängiger Eingang: „Anwender meldet sich beim Service Desk“ mündet in „Kontakt über beliebigen Kanal annehmen“, sodass Telefon, E-Mail, Self-Service-Portal, Chat und persönlicher Besuch in derselben Warteschlange landen, bevor irgendetwas erfasst wird
• Die Weiche „Störung oder Serviceanfrage?“ direkt nach „Ticket erfassen und kategorisieren“, die Störungen zu „Priorität aus Auswirkung und Dringlichkeit“ schickt und Anfragen in einen eigenen Erfüllungszweig
• Ein First-Level-Versuch rund um „Lösung in der Wissensdatenbank?“: Ja wendet die dokumentierte Lösung an, Nein führt zu „Lösung im First Level versuchen“; beide treffen sich bei „Im First Level gelöst?“ mit einem Eskalationszweig in „Im Second Level analysieren und lösen“
• Der Anfragezweig: „Führungskraft gibt die Anfrage frei?“ mit einem Ablehnungszweig, der bei „Anfrage abgelehnt und geschlossen“ endet, danach „Artikel auf Lager?“, das eine Bestellung über „Bestellung auslösen“ leitet, bevor „Anfrage erfüllen und Asset erfassen“ folgt
• Der Abschluss in der letzten Spalte: „Lösung dokumentieren und Anwender informieren“, die Entscheidung „Anwender bestätigt die Lösung?“ mit einem Zweig zurück in den First Level und „Wiederkehrendes Problem?“, das einen Problem-Datensatz anlegt, bevor „Ticket geschlossen“ erreicht wird

Wann Sie diese Vorlage verwenden sollten

• Sie dokumentieren, wie Ihr Service Desk tatsächlich arbeitet, damit neue Mitarbeitende sehen, wohin ein Ticket läuft und wer welche Stufe verantwortet, ohne eine Kollegin fragen zu müssen
• Sie trennen Störungen von Serviceanfragen, die heute in einer undifferenzierten Warteschlange liegen, in der am Ende alles als dringend behandelt wird
• Sie konfigurieren ein Ticket- oder ITSM-Werkzeug, in dem Kategorien, Prioritätsmatrix, Freigaberegel und Asset-Aktualisierung aus dem Diagramm ohnehin als Felder anzulegen sind
• Sie klären, wo der First Level endet und der Second Level beginnt: in den meisten Teams eine gewachsene Gewohnheit statt einer geschriebenen Regel
• Sie weisen einen ausgelagerten oder neu aufgebauten Desk in die Übergaben, Bestätigungen und Dokumentationspflichten ein, die Sie erwarten

So funktioniert es

1. Benennen Sie die Bahnen nach Ihren echten Rollen

   Ersetzen Sie Anwender, Service Desk, Second Level Support, Asset und Beschaffung sowie Problemmanagement durch die Teams, die es bei Ihnen gibt. Kleinere Organisationen führen Asset und Beschaffung häufig in der Service-Desk-Bahn mit, und Problemmanagement ist oft eine benannte Person statt eines Teams. Halten Sie eine Bahn je Entscheidungsträger statt je Person, damit das Diagramm einen Stellenwechsel übersteht.

2. Schreiben Sie den Test Störung gegen Serviceanfrage auf

   Die Weiche „Störung oder Serviceanfrage?“ funktioniert nur, wenn Agenten sie in Sekunden anwenden können. Notieren Sie den Test direkt an der Entscheidung: Ist etwas defekt, das funktionieren sollte, oder wünscht die anfragende Person vereinbarte Standardarbeit? Listen Sie Ihre echten Grenzfälle auf (etwa ein langsamer Laptop gegenüber dem Wunsch nach einem neuen) und legen Sie fest, wohin jeder läuft.

3. Veröffentlichen Sie Ihre Prioritätsmatrix

   Hängen Sie Ihre Definitionen von Auswirkung und Dringlichkeit an „Priorität aus Auswirkung und Dringlichkeit“ und beschreiben Sie, was jede Prioritätsstufe hinsichtlich betroffener Personen und geschäftlicher Folgen bedeutet. Erst wenn die Matrix dort steht, wo auch Anwender sie lesen können, wird Priorität zu etwas Abgeleitetem statt zu etwas, das je Ticket ausgehandelt wird.

4. Setzen Sie die Grenze des First Level und den Inhalt einer Eskalation

   Legen Sie fest, was der First Level lösen darf und kann, und was eine Eskalation enthalten muss, bevor der Second Level sie annimmt: bereits versuchte Schritte, betroffener Service, Belege und die Erreichbarkeit des Anwenders. Entscheiden Sie, ob Sie zusätzlich eine zeitbasierte Rückfalllinie wollen, die ein Ticket ohne Fortschritt automatisch eskaliert, und benennen Sie, wer nach der Übergabe verantwortlich ist.

5. Entscheiden Sie, was freigepflichtig und was vorab genehmigt ist

   Kennzeichnen Sie günstige, risikoarme Katalogpositionen als vorab genehmigt, damit sie „Führungskraft gibt die Anfrage frei?“ ganz überspringen, und reservieren Sie die Freigabe für Ausgaben, Lizenzen und alles, was ändert, worauf eine Person zugreifen kann. Geht es um Systemzugriffe, übergeben Sie an Ihren Zugriffsantrag, statt hier freizugeben.

6. Vereinbaren Sie Abschluss, Wiederöffnen und Problemübergabe, und veröffentlichen Sie eine Fassung

   Legen Sie fest, was als Bestätigung des Anwenders gilt, wie lange ein gelöstes Ticket bis zum automatischen Schließen wartet und nach welchen Kriterien „Wiederkehrendes Problem?“ einen Problem-Datensatz auslöst. Gehen Sie das Diagramm anschließend mit jeder Bahn durch, korrigieren Sie die Schritte, die dort wirklich ausgeführt werden, und veröffentlichen Sie es mit dokumentierter Freigabe als gültige Fassung, damit alle dieselbe Version lesen.

Häufig gestellte Fragen

Worin unterscheiden sich IT-Helpdesk-Prozess und Incident Management?

Der Helpdesk-Prozess ist der Betriebsablauf des Desks selbst: jeder eingehende Kontakt, über jeden Kanal, geleitet in die passende Bearbeitung. Incident Management ist ein Strang darin und behandelt ausschließlich ungeplante Unterbrechungen eines Service. ITIL 4 führt Service Desk, Incident Management, Service Request Management und Problem Management genau deshalb als getrennte Practices, auch wenn ein kleines Team sie in der Praxis mit denselben Personen aus einer Warteschlange bedient. Dieses Diagramm ist die Sicht auf Desk-Ebene: Es zeigt, wie die Stränge Eingang und Abschluss teilen, und übergibt die Tiefe des Störungsfalls (Ausrufung eines Major Incident, Eskalation bei SLA-Verletzung) an den Incident-Management-Prozess.

Was ist der Unterschied zwischen einer Störung und einer Serviceanfrage?

Eine Störung ist etwas, das funktionieren sollte und es nicht tut: eine fehlgeschlagene Anmeldung, ein offline gegangener Drucker, eine Anwendung mit Fehlermeldungen. Eine Serviceanfrage ist vereinbarte Standardarbeit ohne Fehler: neue Software, eine Lizenz, ein Ersatzgerät, ein Postfach für eine neue Kollegin. Die Unterscheidung ist wichtig, weil sie fast alles danach verändert. Störungen bekommen eine Priorität aus Auswirkung und Dringlichkeit und werden an der Wiederherstellung gemessen; Anfragen bekommen eine Freigabe und einen Erfüllungsweg und werden an der Lieferung gemessen. Wer beides vermischt, lässt entweder Routineanfragen auf einer Ausfalluhr laufen oder echte Ausfälle hinter Laptop-Bestellungen warten.

Wann sollte ein Ticket an den Second Level eskaliert werden?

Eskalieren Sie, wenn die Arbeit die Grenze von Wissen, Werkzeugen oder Rechten des First Level überschreitet: Das ist eine funktionale Eskalation. Davon zu unterscheiden ist die hierarchische Eskalation, bei der eine Führungskraft hinzugezogen wird, weil Auswirkung oder Verzögerung zu einem geschäftlichen und nicht mehr zu einem technischen Thema geworden sind. Viele Desks ergänzen eine zeitbasierte Rückfalllinie, die ein Ticket ohne Fortschritt automatisch weitergibt; als Sicherheitsnetz nützlich, als alleinige Hauptregel aber schwach. Was auch immer sie auslöst: Die Übergabe muss mitführen, was bereits versucht wurde, sonst wiederholt der Second Level in der ersten Stunde die Arbeit des First Level.

Darf ein Ticket geschlossen werden, bevor der Anwender die Lösung bestätigt?

Gelöst und geschlossen sind zwei verschiedene Zustände, und dieses Diagramm hält sie auseinander. Ein Agent setzt ein Ticket auf gelöst, wenn die Lösung angewendet ist; geschlossen wird es erst, wenn „Anwender bestätigt die Lösung?“ mit Ja beantwortet ist. Sagt der Anwender, das Problem bestehe weiter, wird das Ticket in den First Level wiedereröffnet statt neu angelegt: So bleiben Historie und ursprüngliche Uhr zusammen. Weil manche Anwender nie antworten, setzen die meisten Desks ein Zeitfenster von wenigen Arbeitstagen mit vorheriger Erinnerung und schreiben diese Frist in die Servicebeschreibung, damit der Abschluss niemanden überrascht.

Wie passen Serviceanfragen mit Beschaffung in den Prozess?

Sie folgen dem Erfüllungszweig: Freigabe, wo der Katalog sie verlangt, danach „Artikel auf Lager?“, das entweder aus dem Bestand ausgibt oder vor der Erfüllung eine Bestellung auslöst. Der Schritt, den man gern überspringt, ist die Aktualisierung des Asset-Datensatzes: Deshalb steht sie hier im selben Knoten wie die Erfüllung. Wird das Inventar nicht bei der Ausgabe gepflegt, laufen Lizenzzählung und Hardware-Erneuerungsplanung binnen Monaten aus dem Ruder. Bei größeren oder katalogfremden Beschaffungen meldet der Desk lediglich den Bedarf, und der umfassendere Bestellprozess mit eigener Lieferantenauswahl und Rechnungsprüfung übernimmt.