Im Tagesgeschäft eines jeden größeren Unternehmens ist es heutzutage unerlässlich, den Betrieb seiner IT und die Unterstützung der Kunden der IT mittels angemessener SLAs zu managen. Hierfür müssen geeignete Aktivitäten und Prozesse definiert und eingeführt werden, die mittels verantwortungsvollem Management den korrekten Betrieb Tag ein, Tag aus sicherstellt.

Viele Unternehmen gehen diesen Schritt und führen mit Service Operation die entscheidende Phase im Servicelebenszyklus ein. Darin ist der Incident-Management-Prozess eine der Kernaufgaben. Diese Incidents – zumeist z.B. Ausfälle, Fehler und, wenn auch eigene Software entwickelt wird, Programmierfehler- werden in den meisten unternehmen softwareunterstützt bearbeitet.

In den häufigsten Fällen ist der Auslöser eine Mail oder ein Anruf an den Service Desk, der den jeweiligen Incident in einem Ticket erfasst. Und an dieser Stelle beginnt das Malheur: Zumeist fehlt schon an der Hotline ein ausgefeilter Fragenkatalog der aus den bisherigen Problemen und deren Behebung entwickelt worden ist. Und schon stecken wir mitten im Teufelskreis.

Die meisten Auffälligkeiten in der IT sind keine gänzlich neuen Probleme – sie sind zumeist „alter Wein in neuen Schläuchen“ soll heißen bekannte Herausforderungen und nur durch die Darstellung des Betroffenen im wieder anders dargestellt oder auch Abwandlungen von schon bekannten Themen. Und was macht der first-Level-Support an dieser Stelle: Er erfasst das Fehlerbild gänzlich neu und geht – wenn er sich nicht gerade selbst an einen ähnlichen Fehler, den er behoben hat, erinnern kann – die Lösung ganz von vorne mit einer Detailanalyse an. 

Dies alles kostet Zeit, viel Zeit, die effizienter eingesetzt werden könnte, wenn zumindest bei der früheren Behebung der Fehler die Lösung in den Tickets vermerkt worden wäre und so mit einer kurzen Suche wiedergefunden werden könnte. Und hier habe wir die nächsten beiden Fallen: Lösungsbeschreibung und Verschlagwortung!

Zumeist werden die Tickets am Ende nur mit den Worten "behoben" kommentiert und mit dem Status erfolgreich geschlossen wieder aus den Augen aus dem Sinn in die Tiefen der Fehlerdatenbank geschossen. Nicht ein Wort, welches dieses Ticket zum erneuten Aufruf durch entsprechende Schlagworte helfen würde, ist hinterlegt. Selbst die Betreffzeile so nichtssagend wie irgendwas.

Und an dieser Stelle sollte eigentlich eine Aufbereitung der Tickets in regelmäßigen Abständen erfolgen. ITIL sieht an dieser Stelle den Problem Management-Prozess für IT-Service-Management. Dieser Prozess hat zum Ziel eine 'dauerhafte Problemlösung' herbeizuführen, um weiterhin sich wiederholendes Auftreten von Störungen mit unbekannter Ursache zumindest reaktiv zu vermeiden. Vorteilhaft wäre auch noch die Bearbeitung potentieller Störungen, um damit proaktiv eingreifen zu können.

All diese Erkenntnisse sollten dem Service Desk zumindest per FAQ oder alternativer Möglichkeiten, wie z.B. Handlungsanweisung, Schulung, Lernvideo zur Verfügung gestellt werden... 

Und da war er wieder der Teufelskreis: Ohne Informationen im Ticketsystem und ohne Einführung des Problem-Management-Prozesses wird das gerade erworbene Wissen wieder nur in den Köpfen der Mitarbeiter bleiben und nicht der Summe alle mit den Service-Operations-Prozessen betrauten Mitarbeitern zur Verfügung gestellt.

Dies mag in kleinen Unternehmen noch funktionieren, aber in den Unternehmen, in denen mehrere Mitarbeiter mit dem Incident Prozess über mehrere Standorte verteilt arbeiten, werden kostbare Ressourcen verschwendet. Und dies bleibt natürlich auch nicht unbemerkt beim Enduser.

Und dies ist nur ein konstruierter Fall? Nein mitnichten. Gerade im Mittelstand der produzierenden Industrie ist auch heute noch oft die IT nur ein Kostenfaktor und wird nicht als Business Enabler gesehen.

Von daher kann ich nur empfehlen: Etablieren Sie einen umfassenden Incident-Management Prozess und den Problem-Management-Prozess mit folgenden Aufgaben:

• Die Ursache für Betriebsstörungen (Probleme) untersuchen

• Probleme dauerhaft beheben und Umgehungslösungen entwickeln

• Sicherung des Wissens über bekannte Problemursachen

Die Ziele sollten u.a. umfassen:

• Senkung der Störungsanfälligkeit und nachhaltige Erhöhung der Servicequalität

• Erkennen von Beziehungen zwischen Störungen, gemeinsame Ursachen finden

Und so werden Sie am Ende folgenden Nutzen ernten:

• signifikante Reduktion der auftretenden Störungen
• Verbesserung der Zuverlässigkeit der IT Services
• dauerhafte Problemlösung
• Senkung der Qualitätskosten

Viel Erfolg!

Autor:

Alexander Reinhard

Oktober 2017