Problem Management

Was ist das Problem mit dem Problem Management?

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.

Incident Management ist die Feuerwehr in der IT

Incident Management ist die Feuerwehr in der IT

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).

Problem Management

Problem 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.

9 Comments
  • Manuel Müller

    14. Januar 2013 at 14:06

    Hallo Herr Andenmatten,

    können Sie bitte einmal detailliert beschreiben, weshalb es wirklich darauf ankommt, dass der Incident und Problem Manager nicht ein und dieselbe Person sein sollten.

    In unserem Unternehmen wird diese Frage heftigst diskutiert und ich würde gerne ihre Erfahrung und Kompetenz mit in unsere Diskussion einfließen lassen.

    Über eine Antwort wäre ich sehr erfreut!

    Grüße

  • Martin Andenmatten

    16. Januar 2013 at 15:12

    Hallo Herr Müller,

    das ist eine gute Frage, welche ich auch immer wieder gestellt erhalte. Es gibt Prozessrollen, die sich gut ergänzen und welche in kleineren Organisationen auch sinnvoll zusammen gelegt werden können. Beispielsweise gehörten die Themen Change Mgmt, Release & Deployment Mgmt sowie Configuration Management sehr nahe zusammen und haben keine konkurrenzierende Ziele.

    Beim Incident und Problem Management ist dies etwas schwieriger. Sehr wohl haben beide Prozesse zum Ziel, Störungen zu vermeiden und zu beheben. Aber der Ansatz, wie dies erreicht werden soll, ist unterschiedlich. Das Incident Management – und damit auch der verantwortliche Incident Manager hat einen grossen Druck. Er muss den Service so schnell wie möglich wieder dem Anwender zur Verfügung stellen. Die Art der Lösung ist nicht im Vordergrund. Es reicht auch, wenn eine Umgehungslösung anvisiert wird – Hauptsache, der Kunde kann wieder Arbeiten.

    Der Problem Manager ist aber auf eine dauerhafte Lösung erpicht. Dazu muss er aber die Störung untersuchen und die zugrundeliegende Ursache finden. Das braucht in der Regel mehr Zeit – wenn dann der Fehler gefunden ist, kann man eine dauerhafte Lösung anvisieren.

    Nun – wieso sollen diese Rollen nicht zusammengelegt werden können? Falls die beiden Rollen einer einzelnen Person übertragen wird, muss er den Ziel-Konflikt mit Incident und Problem Management (schnell versus nachhaltig) mit sich selber austragen. Er muss immer abwägen, soll ich jetzt auf eine schnelle Lösung pochen oder soll ich eine längerdauernde dafür nachhaltige Lösung suchen. Es braucht schon eine sehr hohe Seniorität, hier immer den richtigen Weg zu finden.

    Wenn die Rollen getrennt auf Personen verteilt sind, dann sind die Verantwortlichkeiten klarer. Der Incident Manager wird auf eine schnelle Lösung für den Kunden wirken. Erst wenn er überzeugt wird, dass eine brauchbare Lösung nicht ohne Ursachenanalyse erreicht werden kann, wird er den Auftrag an das Problem Management übertragen. Incident Management hat dabei immer Vorrang und gibt die Priorität für ungelöste Störungen vor.

    Die Unterscheidung von Incident und Problem ist oft eines der grossen Probleme in den Organisationen, obwohl dies durchaus als sinnvoll erachtet wird. Wenn die Prozess Manager Rollen auf verschiedene Personen verteilt sind, dann erhalten diese beiden Theman auch ein unterschiedliches Gesicht. Wenn das die gleiche Person ist, wird man immer etwas Schwierigkeiten haben, abzugrenzen.
    Wie gesagt, mit einer hohen Seniorität und klarer Kundenfokussierung kann eine Person durchaus beide Rollen innehaben. Es empfielt sich aber, dies aufzutrennen, damit klare Zuständigkeiten und klare Abgrenzungen möglich sind.
    Um auf Ihre Organisation zurück zu kommen: es wird nichts vergeben, wenn Sie die beiden Ansätze auch einmal durchleben. Wenn Sie der Meinung sind, dass die Rollen durchaus zusammen gelegt werden können, probieren Sie das aus. Reflektieren Sie dann in 2-3 Monaten die Situation und lassen sich Ihren Entscheid bestätigen – oder aber trennen Sie das auf. Letztlich muss es für Ihre Organisation passen.
    Ich wünsche Ihnen viel Erfolg.

    Freundliche Grüsse aus Zürich
    –Martin Andenmatten

  • Martin Christen

    25. August 2014 at 12:38

    Guten Tag Herr Andenmatten, wir haben kontroverse Diskussionen betreffend dem Wording Known Error und Known Problem. Bei Known Error argumentiere ich wie die Quelle Wikipedia (Auszug:• Ein Known Error ist ein Problem mit einer dokumentierten zugrundeliegenden Ursache und einem Workaround. Known Errors werden über ihren ganzen Lebenszyklus hinweg vom Problem-Management-Prozess verwaltet. Die Details eines Known Errors werden einem Known Error Record in der Known Error Database (KEDB) gespeichert. In der Regel werden Known Errors vom Problem Management identifiziert, können jedoch auch von anderen Service-Management-Disziplinen wie z.B. dem Incident Management oder von externen Suppliern vorgeschlagen werden.).
    Known Problem taxiere ich als Problem, welches bewusst nicht gelöst wird, sei dies aufgrund Kosten/Nutzen-Überlegungen oder anderen. Wie ist Ihre Sicht der Dinge? Existiert der Begriff üin dieser Form überhaupt?
    Freundliche Grüsse,
    Martin Christen

  • Martin Andenmatten

    28. August 2014 at 18:21

    Hallo Herr Christen,

    Ihre Betrachtung eines „Known Errors“ entspricht auch dem allgemeinen Verständnis. Aber rein von den ITIL-Begrifflichkeiten gibt es keine „Known Problems“. Ein Problem wird definiert, als einen Fehler mit unbekannter Ursache. Demnach ist ein Problem ein „Unknown Error“. Ein Known Error ist grundsätzlich ein Problem mit bekannter Ursache.

    Ob mit dem „Known Error“ mit einer Umgehungslösung gelebt wird oder der Fehler durch eine dauerhafte Lösung abgelöst wird, ändert an der Begrifflichkeit im Prinzip nichts. Wenn der Fehler durch eine dauerhafte Lösung behoben wurde, dann ist es per se kein Fehler mehr. Dies wird auch so in der KEDB vermerkt.

    Wenn aus technischen oder wirtschaftlichen Gründen auf eine dauerhafte Lösung verzichtet wird, dann wird dies in der Known-Error-Datenbank vermerkt und mit der zumutbaren Umgehungslösung gelebt.

    Wichtig ist aber, dass Sie im Unternehmen eine verständliche Definition der Begrifflichkeiten haben. Wenn es für die BKW stimmt, dann muss das nicht zwingend nach dem Wording von ITIL erfolgen. Aber es stimmt schon, im Austausch mit anderen externen Partnern kann es zur Verwirrung führen.

    Hoffe, Ihnen damit etwas Licht in den Glossar-Dschungel gebracht zu haben.

    Freundliche Grüsse
    –Martin Andenmatten

  • Christen Martin

    29. August 2014 at 16:44

    Hallo Herr Andenmatten,

    besten Dank für ihre Antwort, hilft mir entsprechend weiter. Sollten wir bei „unserer“ Definition bleiben werden wir die klare Bedeutung auf alle Fälle verständlich beschreiben.

    Freundliche Grüsse,
    Martin Christen

  • Edgar

    8. September 2016 at 13:28

    Hallo Herr Andenmatten,
    Es wird immer wieder über Effizienz von Problem Mgmt diskutiert. Sie ist m.E. schwer messbar.
    Hintergrund: Effizient von Problem Mgmt transparent machen, und zwar so, dass sie mit Zahlen und Fakten untermauert ist.
    Abgesehen von „Anzahl der Incidents“ gibt es noch weitere Ansätze zur Ermittlung von Effizient des Problem Mgmts?

  • Edgar

    8. September 2016 at 13:28

    Hallo Herr Andenmatten,
    Es wird immer wieder über Effizienz von Problem Mgmt diskutiert. Sie ist m.E. schwer messbar.
    Hintergrund: Effizient von Problem Mgmt transparent machen, und zwar so, dass sie mit Zahlen und Fakten untermauert ist.
    Abgesehen von „Anzahl der Incidents“ gibt es noch weitere Ansätze zur Ermittlung von Effizient des Problem Mgmts?

    Danke Ihnen schon im Voraus

  • Martin Andenmatten

    23. Oktober 2016 at 14:13

    Hallo Edgar,
    ja – ein effizienter Problem Management Prozess ist eminent wichtig für eine feife Service Organisation. Wichtig dabei ist vorgängig eine klare Abgrenzung zum Incident Management zu haben und die unterschiedlichen Ziele zwischen dem Incident und Problem Management zu verdeutlichen. Entsprechend sind auch die KPIs zu hinterlegen.

    Beim Problem MAnagement geht es ja darum, nachhaltige Lösungen zu finden, während es bei In ident eher um den Faktor Zeit der Wiederinstandstellung des Services geht.

    Mögliche Effizienzparameter im Problem Management können sein:
    – wie schnell wird die Ursache des Problems gefunden?
    – sind die Lösungen auch tatsächlich nachhaltig (treten die Incidents nicht mehr auf)?
    – wie wird proaktices Problem Management genutzt, um Störungen vorzubeugen? Respektive, bei welchen Vorfällen wurde nachträglich entdeckt, dass seitens Lieferant ein passender Patch bereit gelegen wäre (…)

    Viel Erfolg im Problem Management

  • […] Andenmatten beschreibt den Nutzen von Problem-Management in seinem Blogbeitrag Was ist das Problem mit dem Problem-Management ganz […]

Post a Comment