Den Incidentmanagement-Prozess agiler gestalten

In meinem vorherigen Blogartikel können Sie alles über das agile Servicemanagement lesen. In diesem Artikel richten wir unser Augenmerk auf den wichtigsten Prozess einer Serviceabteilung: Wie gestalten Sie Ihr Incidentmanagement agiler?

Entfernen Sie sämtliche Schritte, aus denen Ihr Melder keinen Nutzen zieht

Erwägen Sie, Ihren Incident-Prozess agiler zu gestalten? Dann sollten Sie sich zunächst jeden Schritt Ihres aktuellen Prozesses genau anschauen und sich die Frage stellen: Bringt dieser Schritt dem Melder einen zusätzlichen Nutzen?

Um diese Frage zu beantworten müssen Sie zunächst wissen, was Ihr Melder sich wünscht. Ihr Anwender sucht wahrscheinlich eine schnelle und gute Lösung. Jeder Schritt Ihres Incidentmanagement-Prozesses muss dazu beitragen, wie schnell ein Incident bearbeitet werden kann oder Ihrem Melder eine bessere Lösung zu bieten. Gibt es einen Schritt, der nicht zu Ihrem Ziel beiträgt? Kann dieser entfernt werden?

Sie können das mit dem Lean Management-Ansatz vergleichen. Dabei entfernen Sie alles Überflüssige aus Ihren Prozessen. Der Unterschied dabei ist, dass Sie beim Lean Management-Ansatz Ihren Prozess effizienter gestalten möchten und beim „agil sein“ Ihren Meldern so viel Nutzen wie möglich bieten wollen.

Ein traditioneller Incidentmanagement-Prozess

Schauen wir uns mal einen gewöhnlichen Incidentmanagement-Prozess an. Sie kennen bestimmt dieses oder ein ähnliches Diagramm:

Der Melder reicht einen Incident ein. Daraufhin klassifiziert ein Servicedesk-Mitarbeiter die Anfrage und fügt einen Zeitplan hinzu. Als nächstes prüft er oder sie, ob der Incident direkt bearbeitet werden kann. Falls ja, fängt er oder sie direkt mit der Bearbeitung an. Falls nein, wird der Incident an einen Spezialisten weitergeleitet. Dieser Spezialist führt die gleiche Bewertung durch. Sobald der Incident abgeschlossen ist, wird er zurück an den Servicedesk gegeben, wonach der Incident geschlossen und der Melder informiert wird.

Ziemlich einfach, oder? Dabei könnte es sogar noch einfacher sein.

Warum muss Ihr Servicedesk jeden Incident bearbeiten?

In vielen Unternehmen ist es so, dass Incidents vom Servicedesk abgeschlossen werden, auch wenn das Problem vom Backoffice gelöst wurde. Der Backoffice-Bearbeiter beschreibt, was er oder sie getan hat und der Servicedesk wandelt das Fachchinesisch in die Sprache der Melder um, schließt den Incident ab und informiert den Melder. Weshalb? Weil davon ausgegangen wird, dass technische Spezialisten schlecht darin sind, Ihre Lösungen in einer anwendergerechten Art und Weise zu kommunizieren.

Das stört mich. Wenn ein technischer Spezialist seine Lösung nicht beschreiben kann, wie soll dann der Servicedesk verstehen, was er oder sie gemacht hat? Ein Servicedesk-Mitarbeiter muss sich mühsam durch alle Informationen wälzen, um letztendlich zu einer verständlichen Erklärung zu gelangen. Zeitverschwendung, wenn Sie mich fragen.

Warum sollte das Backoffice nicht dazu fähig sein, für Melder verständliche Lösungen zu verfassen? Klar, für manche mag das schwer sein, das leuchtet mir ein. Aber es ist leicht zu lernen. Halten Sie eine Trainingseinheit ab und coachen Sie sich gegenseitig. Es ist sehr viel effizienter, wenn das Backoffice seine Incidents selbst beschreiben und abschließen kann, als wenn der Servicedesk sich überlegen muss, wie er die Sache dem Melder am besten erklärt. Außerdem muss so der Incident weniger oft weitergeleitet werden, was zu einer kürzeren Gesamtbearbeitungszeit führt.

Muss Ihr Servicedesk wirklich alle Felder ausfüllen?

Bei jedem neuen Incident müssen sehr viele Daten festgehalten werden. Doch ist das wirklich notwendig? Sie brauchen doch eigentlich nur sehr wenige Informationen, um einen Incident zu bearbeiten. Den Melder, das Anliegen und die Deadline des Incidents. Sämtlich verbleibende Daten werden nur für Reports benutzt.

Setzen Sie sich mit dem Servicedesk und dem Management zusammen und prüfen Sie, ob die Daten, die momentan festgehalten werden, überhaupt für Reports benötigt werden.

Gibt es Reports für diese Daten?

Ich war bei dutzenden Unternehmen zu Gast, bei denen der Servicedesk allerlei Formularfelder ausfüllt, diese aber nie in Reports aufgegriffen werden. Wie kommt es dazu? Während der Implementierungsphase haben sich manche Mitarbeiter vielleicht etwas Richtung „Lasst uns diese Felder ausfüllen, dann können wir später Reports damit erstellen“ gedacht. Diese Reports wurden allerdings nie erstellt.

Was passiert mit den Reports?

Stellen Sie sich vor, dass es zu sämtlichen von Ihnen festgehaltenen Daten Reports gibt, die tatsächlich gelesen werden. Dann stellt sich natürlich die Frage: Machen wir überhaupt etwas mit diesen Daten? Führt das Management Verbesserungen anhand dieser Reports durch? Helfen diese Verbesserungen Ihrem allgemeinen Ziel, für Ihre Melder so schnell wie möglich eine passende Lösung zu finden? Falls ja: Sind diese Verbesserungen so wichtig, dass es sich lohnt, bei jedem Incident all diese Daten festzuhalten?

Verstehen Sie mich nicht falsch. Ich möchte nicht sagen, dass Reports nutzlos sind. Ganz im Gegenteil: Durch Reports erhalten Sie wertvolle Informationen über Ihren Servicemanagement Prozess. Sie müssen bei Ihrer Bewertung aber kritisch bleiben. Sind manche Daten nicht relevant? Dann füllen Sie diese Felder nicht aus, oder lassen Sie sie automatisch ausfüllen. Das spart dem Servicedesk viel Zeit dabei, Daten festzuhalten.

Kann ich meinen Incidentmanagement-Prozess agiler gestalten?

Natürlich gibt es noch mehr Möglichkeiten, den Prozess agiler zu gestalten. Haben Sie eigene Ideen dazu? Oder experimentieren Sie diesbezüglich mit Ihrer eigenen Serviceabteilung? Dann teilen Sie es mir in den Kommentaren mit, ich freue mich darüber, Ihre Ideen zu hören!

Sie möchten mehr über Agile Servicemanagement erfahren?

In unserem E-Book finden Sie alles Wissenswerte zum Thema agiles Servicemanagement. Sie erfahren, wie „agil sein“ mit ITIL zusammenspielt, wie agile Servicemanagement in der Praxis umsetzbar ist und welche Hürden bei der Umstellung auf eine agile Arbeitsweise überwunden werden müssen.