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

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.