Blog

Checkliste: Ergeben Ihre Incident-Kategorien Sinn?

Dieser Blogartikel fällt unter die folgenden Kategorien:

03 März 2021

Ihr Team wendet wahrscheinlich viel Zeit dafür auf, Incidents zu kategorisieren. Aber warum überhaupt? Hilft das Ihrem Team, Incidents schneller zu bearbeiten? Stellen Sie sich diese sechs Fragen, um zu prüfen, ob Sie mehr aus Ihrer Incident-Kategorisierung herausholen können.

Warum sollten Sie Ihre Incidents kategorisieren?

Zunächst sollten wir uns die Grundfrage stellen: Warum sollten wir Incidents überhaupt kategorisieren? Benötigen Sie diese Information? Können Sie einen Incident nicht einfach registrieren und das war‘s?

Die Kategorisierung verfolgt zwei Ziele: Zuweisung und Reporting.

Eine Kategorisierung hilft Ihnen, einen Incident schnell dem richtigen Team zuzuweisen. In den meisten Fällen ist dies ein manueller Vorgang. Er kann jedoch durch Künstliche Intelligenz oder auf Grundlage von Schlagworten automatisiert werden.

Kategorien helfen Ihnen ebenfalls bei der Analyse der Incidentauslöser. Sie erhalten Einsicht in die Art der wiederkehrenden Anfragen. Das erlaubt Ihnen, die zugrundeliegenden Probleme zu beheben, relevante Know-how-Einträge zu erstellen oder Prozesse wie die Passwortzurücksetzung zu automatisieren.

1. Wie sollten Sie Ihre Incident-Kategorien organisieren?

In der Praxis sehen wir allerlei Lösungen. Ich empfehle jedoch, dass Ihre Incident-Kategorien auf Ihren Services und Situationen basieren.

Ihre Hauptkategorie sollte die von Ihnen erbrachten Services widerspiegeln, wie beispielsweise „E-Mail“, „Arbeitsplatz“ oder „Onboarding/Offboarding“. Je Kategorie listen Sie die Situationen auf, die entstehen könnten, wie beispielsweise „E-Mail blockiert“, „Arbeitsplatz-Zubehör anfragen“, oder „neue Einstellung“.

Ein paar Tipps zu den Incident-Kategorien:

Gestalten Sie Ihre Unterkategorien nicht zu spezifisch. Ich konnte bei vielen Organisationen beobachten, dass Sie den Service („E-Mail“) in der Hauptkategorie definieren. Die möglichen Situationen werden dann in der Unterkategorie (z.B. „Mailserver offline“, oder „Outlook-Fehler“) definiert. Beachten Sie jedoch: Wird der Incident eingereicht, wissen Sie noch nicht, wodurch das Problem ausgelöst wird. Treffen Sie zu Beginn der Incidentbearbeitung eine falsche Einschätzung, müssen Sie die Kategorisierung während der Bearbeitung anpassen.
Versteifen Sie sich nicht zu sehr darauf, Ihre Kategorien an Ihrem Self Service Portal auszurichten. Jeder Service könnte aus einer Vielzahl verschiedener Aufgaben für Ihr Team bestehen. Selbst wenn diese Aufgaben verschiedenen Kategorien angehören, möchten Sie Ihren Meldern einen einzelnen, umfassenden Service präsentieren.

2. Wie viele Ebenen sollten Ihre Incident-Kategorien aufweisen?

Zwei. Na gut, die genaue Antwort lautet: Nicht mehr als unbedingt notwendig. In den meisten Fällen sollten zwei Kategorien mehr als ausreichend sein. Denn:

Sie möchten schließlich nicht, dass Ihr Team seine komplette Kapazität in die Tätigkeitsbeschreibungen steckt. Sie möchten ebenfalls nicht, dass die Kategorien für die Benutzer Ihres Self Service Portals zu unübersichtlich werden. Es mag verlockend erscheinen, Wegweiser für die immer weiterwachsenden Verzweigungen Ihrer Kategorien aufzustellen. Das führt aber lediglich zu einer weniger transparenten Kategorisierung.
Ihr Ziel sollte sein, die Auswahl einer Kategorie so einfach wie möglich zu gestalten. Jede zusätzliche Kategorisierungsebene macht es komplexer und zeitaufwändiger, die richtige Kategorie zu wählen. Manchmal kennen Sie die benötigte Unterkategorie, können sich dann jedoch nicht erinnern, unter welcher Hauptkategorie diese zu finden ist. Sich rückwärts durch zwei obere Kategorisierungsebenen zu wühlen ist äußert mühsam.
Nicht jede noch so winzige Information muss Teil Ihrer Kategorisierung werden. Sie müssen Incidents nicht in immer kleiner werdende Kategorien aufteilen. Das führt uns direkt zur nächsten Frage.

3. Welche Informationen haben bei Ihrer Kategorisierung nichts zu suchen?

Manchmal beobachte ich, dass Informationen in der Kategorisierung verwendet werden, die auf eine andere Art viel besser registriert werden könnten. Hier sind zwei Beispiele für Informationen, die nicht in Ihre Kategorisierung gehören:

Assets, die vom Problem betroffen sind. Verwenden Sie Assets in Ihrer Kategorisierung, zum Beispiel einen bestimmten Laptoptyp, müssen Sie Ihre Kategorien anpassen, wenn Sie einen neuen Typ Laptop einführen. Es ist vorzuziehen, das relevante Asset im Incident zu erwähnen und darauf zu verweisen.
Abteilung oder Team. Ich sehe oft, dass Kategorien Abteilungen ( „IT-Services“, „Facility-Services“) oder Teams („Datenbank-Team“ oder „Anwendungsmanagement“) gleichen. Das Problem ist, dass Sie bei der Registrierung eines Incidents oft noch nicht wissen, wer den Incident bearbeiten wird.

4. Gibt es eine maximale Anzahl an Incident-Kategorien?

Nicht wirklich. Genau wie bei der Anzahl der Kategorisierungsebenen gilt es hier, nicht mehr einzuführen als unbedingt notwendig.

Wir neigen dazu, als Richtlinie die 7×7-Regel zu verwenden. Versuchen Sie, sich auf sieben Kategorien und pro Kategorie auf sieben Unterkategorien zu beschränken.

Versteifen Sie sich aber nicht auf diese Regel. Arbeite ich mit einem Servicedesk zusammen, der mit acht, neun oder zehn Kategorien am besten bedient ist, stellt das auch kein Problem dar. Kommen Sie jedoch auf eine Anzahl über zehn, sollten Sie sorgfältig darüber nachdenken, ob Sie diese ganzen Kategorien wirklich brauchen.

5. Sollten wir eine „Diverses”-Kategorie haben?

Diese Frage war schon Auslöser heftiger Diskussionen. Meine Meinung: Ja, „Diverses“ sollte als Kategorie inbegriffen werden. Ich habe mich mit Experten unterhalten, die innig gegen das grenzenlose Loch wüten, zu dem diese Kategorie ausarten kann. Warum also spreche ich mich dafür aus?

Wenn Sie keinen besonderen Ort für schwer kategorisierbare Incidents haben, werden zwangsweise unpassende Kategorien ausgewählt. Das widerspricht dem Konzept der Kategorisierung komplett. Jede Kategorie könnte eine Vielzahl von Incidents beinhalten, die nicht dort hingehören. Eine „Diverses“-Kategorie zeigt Ihnen, dass Sie schwierig einzustufende Incidents haben und hält Ihnen diese Incidents direkt vor Augen. Und wenn Ihre „Diverses“-Kategorie stets gefüllt ist, könnte dies sogar wertvolle Informationen liefern, um Ihre anderen Kategorien zu verbessern.

6. Worauf sollten Sie beim Prüfen der Kategorien achten?

Sobald Sie Incident-Kategorien gefunden haben, sollten Sie Ihr System in der Praxis immer wieder überprüfen und anpassen. Führen Sie nach der Implementierung oder Anpassung Ihrer Kategorien eine monatliche Überprüfung durch. Nach ein paar Monaten ist eine vierteljährliche Überprüfung ausreichend. Worauf Sie beim Prüfen Ihrer Kategorisierungen achten sollten:

Prüfen Sie die „Diverses“-Kategorie. Beinhaltet sie viele Incidents? Erwägen Sie, ob Sie eine neue Kategorie erstellen sollten. Benutzen manche Teammitglieder diese Kategorie häufiger? Stellen Sie Ihrem Team bessere Erklärungen bereit.
Prüfen Sie die Verwendung aller Kategorien. Beinhalten manche Kategorien sehr viele oder sehr wenige Incidents? Teilen Sie oder entfernen Sie eine Kategorie. Julie Mohr nennt in Ihrem Blogartikel folgende Richtlinie: „Wenn Sie eine Kategorie haben, die 25% Ihrer gesamten Incidents enthält, dann ist die Struktur möglicherweise nicht detailliert genug. Beinhaltet eine Kategorie weniger als 2%, dann ist sie wahrscheinlich zu spezifisch.“
Ein großer Vorteil der Incident-Kategorisierung besteht in der die Fehler-Ursachen-Analyse. Ihre Incidents sind gruppiert. Eine Fehler-Ursachen-Analyse bei jeder Überprüfung hilft Ihnen, zugrunde liegende Probleme für ähnliche oder wiederkehrende Probleme zu finden und zu beheben

Sind Sie an weiteren Best Practices interessiert?

Wir teilen regelmäßig unsere Best Practices fürs Servicemanagement mit Ihnen. Hier finden Sie eine Auswahl von Artikeln, die für Sie relevant sein könnten:

Oder laden Sie sich unser E-Book Best Practice Servicemanagement herunter.