4

Jedes Unternehmen hat den gleichen Incident-Management-Prozess

Der Incident-Management-Prozess ist in jedem Unternehmen gleich. Der ist in den meisten Tools perfekt abgebildet. Dennoch stecken wir viel Aufwand und Energie in das Customizing. Anstatt in das Incident-Management selbst. Du bekommst Denkanstöße, damit Du etwas anders auf Deinen IM-Prozess schaust und so effektiver wirst!

In den letzten beiden Folgen habe ich Dir ganz eindringlich vor Augen geführt, dass es für Dich als interner oder externer Provider essentiell ist, den Kunden und die Services, die Du ihm anbietest, in den Mittelpunkt Deines Handelns zu stellen. Denn das ist das, was Du lieferst. Du erfüllst damit ein Kundenbedürfnis. Damit die Qualität dauerhaft stimmt und eine hohe Effizienz erreicht wird, darfst Du alles um den Service herum optimieren und soweit sinnvoll automatisieren.

Das ist der Teil Service aus dem Wort Service-Management. Heute rede ich mit Dir über das Wort Management. Das Wort kommt aus dem Lateinischen und bedeutet so viel wie „an der Hand führen“. In der Bedeutung heute von „zielgerichtete und nach ökonomischen Prinzipien ausgerichtete menschliche Handlungsweise der Leitung, Organisation und Planung in allen Lebensbereichen.“ So eine frühere Version der Wortdefinition aus dem Duden.

Management: Prozesse, Rollen, Anweisungen, Ziele, Teams und alles, was dazu gehört. Im Service-Management in der Regel vor allem Prozesse.

Prozess oder Praktiken wie das Incident-Management, Change-Management, Problem-Management oder all die anderen.

Incident-Management

Jetzt zu meiner Hypothese aus dem Titel der heutigen Episode: Jedes Unternehmen hat den gleichen Incident-Management-Prozess. Oder auch: Jedes Unternehmen hat den gleichen Change-Management-Prozess. Das lässt sich soweit fortsetzen.

Bleiben wir beim Incident-Management – der läuft überall wie folgt:

1. Incident detection – ein Inicdent wird über verschiedene Wege der Bearbeitung zugeführt
2. Incident registration – der Incident wird im Tool erfasst und das Fehlerbild wird aufgenommen und der Incident wird versucht, so genau wie möglich zu beschreiben
3. Incident classification – es findet eine Klassifizierung und Priorisierung des Incidents statt und er wird einem Team oder Bearbeiter zugewiesen
4. Incident diagnosis – das Fehlerbild wir analysiert und es wird versucht die Ursache der Störung zu identifizieren
5. Incident resolution – der Incident wird beseitigt
6. Incident closure – der Incident wird dokumentiert und abgeschlossen

So weit, so einfach und übersichtlich. Und genau so wird der Prozess beispielsweise in Deinem ITSM-Tool mit ausgeliefert. Den kannst Du direkt verwenden und umsetzen. Den Aufwand für das Customizing an dieser Stelle kannst Du Dir sparen.

Es besteht aus meiner Sicht kaum eine Notwendigkeit, aus diesem einfachen Prozess eine neun Meter lange Prozesstapete zu fertigen. Auch wenn Du zwischen Incidents und Major Incidents unterscheidest, gibt es bei der Klassifikation einen Abzweig zum Major-Incident-Prozess.

Am Ende der Klassifikation wird die zuständige Bearbeitergruppe identifiziert und das Ticket weitergeleitet. Das musst Du nicht im Prozess modellieren – das ist dann die Arbeitsanweisungsebene. Das dürfen wir auseinanderhalten.

Bei der Zuweisung helfen Dir Deine Services. Du ordnest jeden Incident einem Service zu und dann ist klar, welche Bearbeitergruppe diesen erhält.

Bis dahin ist alles gleich – egal in welchem Unternehmen Du arbeitest.

Ja, aber – egal!

Ja, aber. Bei uns. Alles anders. Wenn der Mittwoch auf einen 13 fällt, dann werden Tickets nur angenommen, wenn sie grün angestrichen sind. Das kann sein. Aus meiner Sicht kein Problem. Die Frage: Müssen wir den Prozess auf jede Eventualität und jeden Einzelfall ausrichten?

Was ist der Sinn eines Prozesses? Der Prozess soll Dir und Deinen Kollegen den notwendigen Rahmen geben. Er soll Orientierung geben.  Er soll sicherstellen, dass wir in wiederholbarer Qualität liefern können.

Insbesondere hier im Incident-Management wird deutlich, dass es nicht viel mehr sein kann und auch nicht sollte.

Warum ist das so? Dazu möchte ich Dich ein wenig mit dem Cynefin (Kü-NE-win)-Framework vertraut machen. Die Aussprache ist etwas schwierig, weil mein Walisisch schlecht ist. Du hörst wahrscheinlich häufig Cynefin-Framework – dabei heißt es „Kü-NE-win“.

Dieses bietet uns die Möglichkeit anstehende Aufgaben, Probleme und Herausforderungen einzuordnen, um zu entscheiden, welche Vorgehensweise für die Bearbeitung die sinnvollste ist.

Einfach

Da gibt es den einfach, geordneten Bereich. Ursache und Wirkung sind aus bereits bekannten Fällen klar. Ich kann also genau aufschreiben, was ich tun muss, um diese Art von Fehlern zu beheben. Funktioniert wunderbar. Hier leisten uns die sogenannten Best Practices einen guten Dienst.

Kompliziert

Der zweite Bereich ist der Komplizierte. Viele Störungen sind kompliziert. Ich brauche Experten, um den Fehler herauszufinden und zu beheben. Es besteht hier immer noch eine Beziehung zwischen Ursache und Wirkung. Die ist nur durch den Experten zu erkennen. Ich kann auch gar nicht mehr so detailliert aufschreiben, wie die Störung behoben wird. Ich weiß aber, dass ich die Störung erkenne, analysiere und behebe.

Das klingt sehr nach unserem Incident-Prozess. Denn auf dieser Flughöhe ist es Dir auf jeden Fall möglich, den Prozess zu definieren. Der gilt dann für alle Störungen, die erkannt werden. Im komplizierten Bereich kommen wir sehr gut mit den sogenannten Good Practices weiter.

Allerdings, was sich in den Schritten Diagnose und Behebung abspielt, ist unter Umständen gar nicht mehr so klar.

Komplex

Es gibt auch Störungen, die sind komplex. Das heißt, eine Ursache-Wirkungsbeziehung ist erst im Nachhinein erkennbar. Hier müssen wir Dinge ausprobieren, beobachten, was passiert und entsprechend darauf reagieren. Dadurch kann sich im Nachgang eine funktionierende Handlungsweise herausbilden, die es uns erlaubt zukünftig mit solchen Fehlern besser umzugehen. Wir können sie unter Umständen sogar in den komplizierten Bereich verschieben. Die Vorgehensweisen, die sich herausbilden, nennen sich emergente Praktiken.

Chaotisch

Und dann haben wir noch chaotische Störungen. Hier ist die Beziehung zwischen Ursache und Wirkung nicht erkennbar, sie besteht dennoch. Hier kannst Du eigentliche nur handeln, um zu beobachten, was passiert und darauf zu reagieren. Selbst eine Hypothese aufzustellen, wie im komplexen Bereich, ist nicht möglich. Ziel ist hier, sogenannte innovative Praktiken herauszubilden, wie man mit solchen Situationen umgeht.

Je nachdem, in welchem Bereich wir uns bewegen, können wir mehr oder minder detaillierte Prozesse aufstellen. Alles was in ITIL als Prozesse oder Practices drin steht, bewegt sich im geordneten Bereich ist also höchstens kompliziert. Zum geordneten Bereich gehören einfach und kompliziert. Ursache & Wirkung sind klar, was ich zu tun habe, ist definierbar. Manchmal brauche ich eben einen Experten.

Je weniger bekannt eine Situation ist, umso mehr versuchen wir alles Mögliche in einen Prozess zu gießen. Je unsicherer, umso detaillierter der Prozess. Das ist der Versuch die Realität zu trivialisieren.

Das ist allerdings die falsche Reaktion. Wenn ich von einfach über kompliziert und komplex zu chaotisch gehe, kann der Detailgrad eines Prozesses nur abnehmen.

Das was in ITIL oder in FitSM zum Thema Incident-Management beschrieben ist, ist genau das, was wir für einen komplizierten Vorgang beschreiben können. Natürlich können wir versuchen, das zu trivialisieren, indem wir dort auch die einfachen Vorgänge im Detail auswalzen. Dass das sinnvoll ist, bestreite ich hier mal.

Das ist für mich auch gut und in Ordnung, weil es Dir und Deinen Kollegen die notwendige Freiheit gibt, mit allen möglichen Situationen adäquat umzugehen. Zusätzlich ersparst Du Dir ganz viel Aufwand und Diskussionen, wenn es beispielsweise um die Implementierung des Prozesses im Tool geht. Wie zuvor erwähnt, die Tools bringen den fertig mit.

Was braucht Deine Organisation?

Die zwei entscheidenden Fragen, die sich für mich ergeben, sind:

• Wie viel Rahmen braucht Deine Organisation?
• Wie viel Rahmen kann überhaupt gegeben werden.

Danach richtet sich der Umfang Deiner Prozesse. Achtung: Wenn Deine Organisation mehr Rahmen braucht, als möglich ist, dann erscheint mir das problematisch.

Was Du da tun kannst, kann ich Dir nicht beantworten. Ich würde im ersten Schritt hinterfragen, warum das so ist. Wie sieht es mit Vertrauen aus, wie sieht es mit Verantwortungsübernahme aus, wie sieht mit der Kommunikation und Zusammenarbeit aus und wie sieht es mit den Fähigkeiten aus?

Ich glaube, der Ruf nach detaillierten Prozessen ist nur ein Symptom dafür, dass es in einem oder mehreren der genannten Bereiche ein Defizit gibt.

Bitte verstehe mich richtig: Wenn das Serviceteam oder der Service-Owner beschließen, dass sie sich aufschreiben wollen, wie gewisse Fehler behoben werden, dann ist das wunderbar und ich befürworte das. Einfache Vorfälle lassen sich wunderbar dokumentieren. Alles was dokumentiert ist, kostet weniger Kraft, bringt bessere Ergebnisse und geht schneller. Das hat dann aber alles nichts im Incident-Management-Prozess zu suchen.