Das Problem Management ist irgendwie das Stiefkind in einer Service Management Organisation.  Der Prozess ist im Schatten des mächtigen Schwester, dem Incident Management und des Service Desks und steht in einem etwas seltsamen  – um nicht zu sagen ärmlichen – Verhältnis zu den Support-Aktivitäten.

Service Desk und Incident Management sind auch unumstritten. Als service- und kundenorientierte Organisation gilt es auf Anfragen und Störungen rasch zu reagieren. Da ist es selbstverständlich, dass in Form von Ressourcen, klaren Prozessdefinitionen, Tools und Training investiert wird. Problem Management ist etwas, was man als irgendwas betrachtet, das man dann später noch macht – wenn die Zeit dazu vorhanden ist. Ist sie natürlich nie.

Vielfach haben Organisationen einfach nur grosse Mühe, zwischen Problem Management und Incident Management zu unterscheiden. Sogar gestandene ITIL® Service Manager und ITIL® Experten tun sich nicht selten dermassen schwer, hier eine klare Linie und Empfehlung auszusprechen.  Die Hilflosigkeit erkennt man dann am ehesten, wenn darauf hingewiesen wird, dass halt jede Organisation für sich definieren muss, wie die Abgrenzung nun zu definieren ist.

Oft begnügt man sich auch damit, dass man Problem Management „macht“, indem auf Major-Störungen reagiert wird. Und gerade hier kommt die gesamte Unschärfe zum Vorschein. So frei nach dem Motto: „wenn ich nicht mehr weiter weiss, dann mache ich Problem Management“. Oder dann herrscht die Sichtweise vor, dass man bei einer Störung eh immer eine Untersuchung starten muss, um überhaupt was unternehmen zu können. Die Unterscheidung zwischen Incident und Problem Management wird dann aufgrund dieser Unklarheit gerne als akademische Übung angesehen. Ich sehe die Support-Truppe regelrecht vor meinem geistigen Auge: im dichten Nebel wird versucht, sich blindlings an das Problem heranzutasten und verzweifelt versucht, mit der Stange die Ursache zu treffen (…).

Ein möglicher Grund für dieses konfuse Verhalten liegt einerseits sicher auch in den Begrifflichkeiten zwischen Incident und Problem, da diese umgangssprachlich nicht unterschieden werden. Anderseits herrscht oft auch die Meinung vor, dass ein Problem nur ein erweiterter Status eines Incidents darstellt. Dabei gehört Problem Management seit der ersten Generation von ITIL® zu einem eigenen, zentralen Prozess neben Incident Management und mit ihm kann der Service Provider Organisation einen der grösste Nutzen überhaupt innerhalb des Service Managements liefern. Professionelles Service Management sorgt für Stabilität und bewirkt, dass weniger Störungen auftreten und die eh schon knappen Ressourcen planmässiger eingesetzt werden können. Letztlich sind die Support Mitarbeiter auch lieber an proaktiven, planbaren Aktivitäten beschäftigt, als andaurend irgendwelche Fehler lokalisieren zu müssen.

Incident Management ist die gut eingespielte und trainierte Feuerwehr der IT Organisation.

Incident Management ist ein reaktiver Prozess – es wird auf Störungen reagiert um diese so rasch wie möglich zu beheben. Vergleichbar mit einer Feuerwehr wird die Feuerstelle gesichert, das Feuer eingedämmt und gerettet was gerettet werden kann und muss. Wer schon mal in der Feuerwehr mitgemacht hat, weiss auch, dass die Einsätze gut eingeübt sein müssen um den Kampf gegen die Zeit und die Ausbreitung des Schadens zu gewinnen. Und jedes Feuer ist trotz guter Übung immer wieder etwas anders. Das ist in der IT nicht viel anders.

Das heisst, dass eine gute Support-Organisation nicht erst beim Auftreten von Störungen sich Gedanken machen darf, wie man dann zu reagieren hat. Wie bereits beim letzten Blog Beitrag (Availability Management ist nicht bloss Monitoring) erläutert, müssen die verschiedenen Szenarien von möglichen Ausfällen und Störungen bereits beim Design des Services analysiert und die Reaktion darauf festgelegt werden. Die Beherrschung der „Downtime“ gehört zu den Kernfähigkeiten einer Support-Organisation – und das muss laufend und immer wieder eingeübt und trainiert werden.

Eine vorbildliche Service Provider Organisation die die Verfügbarkeit als das zentrale Qualitätskriterium erkannt und definiert hat, sieht sich für alle Eventualitäten vor. Störungsbehebungsskripte liegen selbstverständlich aktualisiert und leicht verständlich in der Known-Error-Datenbank für das gesamte Supportpersonal bereit.

Das Incident Management muss einzig davon beseelt sein, den Service so schnell wie möglich wieder zur Verfügung zu stellen. Die Ursache der Störung oder die Lösung hierzu ist sekundär – Hauptsache ist, der Kunde kann den Dienst wieder nutzen.

Problem Management hat den Fokus auf Stabilität und Vorbeugen von Fehlern.

Während Incident Management gegen die Zeit kämpft, braucht gutes Problem Management seine Zeit. Die Anforderungen an den Prozess und die Vorgehensweise sind diametral verschieden. So auch die Anforderungen an die Fähigkeiten der beiden Prozess Manager. Ein grosser Fehler wird oft bereits hier gemacht, indem die Rolle des Problem Managers einem auf Reaktion spezialisierten Support Spezialisten übertragen wird. Oder schlimmer noch, wenn die Rolle Incident Manager und Problem Manager einer einzelnen Person übertragen wird. Wie er den Zielkonflikt für sich löst, bleibt  dann ein Rätsel – nein, nicht wirklich: Problem Management wird so nie zum Fliegen kommen.

Problem Management hat das Ziel, Störungen vorzubeugen und für nachhaltige Lösungen zu sorgen. Der Schwerpunkt des Prozesses liegt daher eher in der proaktiven Störungsvermeidung. Klar gibt es auch die reaktive Komponente des Problem Managements. Immer dann, wenn die eingeübten Szenarien und Wiederanlaufverfahren aus dem Incident Management nicht den erhofften Effekt bringen. Es ist dann aber immer in der Beurteilung und Verantwortung des Incident Managers zu entscheiden, ob durch die Delegation der Störung an das Problem Management das übergeordnete Ziel der schnellst möglichen Störungsbehebung durch eine mehr zeitintensive Ursachenanalyse letztlich schneller erreicht wird, als wenn im Incident Management weiter versucht wird (Try & Error). Es muss davon ausgegangen werden, dass ein Defekt vorliegt, welcher letztlich nur durch eine Ursachenanalyse gefunden (Problem Management) dann durch einen Change behoben werden muss (Change Management).

Abgesehen von diesen als Ausnahme zu betrachtenden massiven Störungen steht das Problem Management nicht unter wirlkichem Zeitdruck. Die Anforderungen an den Problem Manager oder die Problem Koordinatoren sind daher auch ganz anders, als an einen reaktiven Incident Manager oder Service Desk Manager. Der Problem Manager braucht Erfahrungen in der Koordination von technischen Teams und Spezialisten, um diese in der taktischen und methodischen Ursachenanalyse  zu coachen und zu leiten, um den Problemen auf den Grund gehen und um diese dann mit geeigneten Lösungen beheben zu können.

Die Erfahrungen und Anforderungen an den Problem Manager sind also nicht primär technischer Natur, sondern in dem Managen von komplexen Störungsverhalten eines IT Services. Es ist also nicht damit getan, in dem ein Problem einem Spezialisten zu gehalten wird mit der Bemerkung: schau mal, dass das gelöst wird (…). Gute Planungs-, Kommunikations-, Koordinations- und Motivations-Fähigkeiten sowie Durchsetzungsvermögen sind wichtiger als rasches Reagieren auf System-Events.

Siehe dazu diesen Video-Beitrag itsm TV zur Rolle des Problem Managers (English)

Probleme managen heisst, unter Beizug aller notwendigen internen und externen Spezialisten die Ursache des Fehlverhaltens methodisch zu ermitteln. Diese Ursache muss auch verifiziert werden, um sich nicht in der Behebung von Symptomen  zu verirren. Das ist ein weiteres Grundübel in der IT: dieser Schritt wird oft gerne weggelassen und man steuert zu gerne und zu schnell auf eine Lösung zu. Die Konsequenz sind oft Lösungen, die nicht zum Problem passen – viele Site-Effekte mit einem hohen Risiko, die Situation insgesamt noch verschlechtert zu haben – und der Weg zurück bleibt vielfach für immer verschlossen.

Wenn die Ursachen bekannt sind, kann an die Festlegung der Lösung gedacht werden. Dieser Schritt ist dann aus Erfahrung oft viel schneller durchgeführt. Die Lösung selber muss durch den Problem Manager hinsichtlich Aufwand und Nutzen beurteilt werden, bevor die Umsetzung an das Change Management übertragen wird. Problem

Proaktives Problem Management ist dann auch vielschichtig. Es gehört zu den festen Verantwortlichkeiten von System-Komponenten-Verantwortlichen periodisch, mindestens monatlich mit dem Lieferanten nach bekannten Fehlern Ausschau zu halten. Durch blosse Kenntnis dieser Fehler und Symptome kann im Falle des Auftretens der Störung viel Zeit gespart werden. Durch gezielte Analyse des Incident Aufkommens können zudem oft auch Muster von Störungsverhalten erkannt werden, welche wiederholenden Charakter haben. Durch sukzessive Abarbeitung solcher Verhalten lässt sich viel Stabilität und damit auch weniger Störungen im Incident Umfeld erreichen.

Typische Problem Management Fälle sind oft schleichende Performance Verschlechterungen oder häufig auftretende Störungsmuster, welche nicht auf Anhieb greifbar sind. Im Incident Management mag man solchen Fällen nicht nachgehen, weil die Kunden in der Regel rasch wieder arbeiten können. Es braucht eine vertieftere Analyse und einen Kümmerer, um das Problem in vernünftiger Zeit behen zu können.

Problem Management ist in diesem Sinne der grosse Bruder des Incident Management, welches vor grossem Schaden bewahrt und alles fein säuberlich und verständlich in der Known-Error Datenbank dokumentiert. Das Incident Management kann sich auf den Bruder verlassen, weil die Lösungen solide und getestet sind.

Einige Tipps zur Umsetzung des Problem Management

Wenn ein Service Desk und Incident Management eingerichtet ist und bereits etabliert ist, dann ist der richtige Zeitpunkt gekommen, um das Problem Management einzurichten.  Folgende Tipps sollen helfen, den Start zu vereinfachen:

• Sicherstellen, dass die richtigen Leute involviert sind
• Klares Verständnis über die unterschiedlichen Anforderungen gegenüber Incident Mgmt und Service Desk
• Störungen reduzieren und nicht nur beheben muss als Priorität gesetzt werden
• Kommunikation des Nutzens eines guten Problem Managements innerhalb der Organisation
• Erstellen und publizieren einer Top-10 Problem-Liste
• Klare Vorgaben zur Problem-Eröffnung und deren Behebung festlegen
• Sicherstellen, dass der Prozess nicht verkompliziert wird
• Durchführung von Problem-Koordinationsmeetings
• Regelmässiges Abstimmen mit dem Incident Management Prozess
• Starten – und laufend auf Basis von Feedbacks optimieren

Während Incident Management also die Feuerwehr in der Service Organisation darstellt, kann ein gutes proaktives Problem Management als eine Präventions-Einrichtung zur Vermeidung von Feuer und Brandherden angesehen werden.

Es gibt aber noch eine grosse Gefahrenquelle in den Griff zu bekommen. Gar nicht oder nur schlecht gemanagte Changes sorgen immer wieder dazu, dass die Feuerwehr ausrücken muss. Aber dazu ein anderes Mal in diesem Blog.