step2.at

Das Problem ist erfasst - die Ursache ist untersucht und im besten Fall auch gefunden. - Und nun?

Workaround

Wenn im ersten Schritt keine vollständige Lösung gefunden werden kann, so soll zumindest ein Workaround definiert werden. Dies gilt insbesondere bei Störungen und daraus abgeleiteten Problemen - dh. die Störung möglichst schnell beheben - auch mit einem Workaround.

• Workaround im Problem Record vermerken.
• Das Problem bleibt aber weiterhin offen.
• Weiter, tiefer suchen, um eine Lösung zu finden.

Ziel des Problem Management ist die vollständige Behebung des Problems - also kann ein Workaround nur ein Zwischenstep sein.

Known Error

Wenn die Ursache des Problems gefunden wurde und u.U. auch ein Workaround gefunden wurde, kann das Problem als Known Error gekennzeichnet werden. Diese Informationen werden zur schnelleren Abwicklung für zwischenzeitlich auftretende Störungen und Probleme verwendet.

Der genaue Zeitpunkt wann ein Known Error erfaßt wird, hängt von der konkreten Situation ab (kann aus Informations-Gründen auch vor dem Finden der kompletten Ursachen erfolgen)

!! >> Werden neue Funktionen trotz bekannter Fehler produktiv genommen (z.B. weil ein Release trotzdem innerhalb des Zeitplan durchgehen soll), so sollten diese Fehler bereits als Known Errors mit Workaround erfasst werden. Dies wirkt sich im Nachhinein positiv auf die Supportaufwände aus.

Problem Lösung

Im besten Fall wird durch das Problem Management die Lösung zu dem Problem gefunden. Dies wird in den meisten Fällen eine Änderung nach sich ziehen, dh. es ist ein Request for Change zu erstellen.

Die Umsetzung des Changes erfolgt entsprechend den Definitionen im Change bzw. Release Management. Dies kann eine zeitliche Verzögerung bedeuten. Handelt es sich aber um ein signifikantes Problem, so kann ggf. eine Notfall Änderung angestoßen werden.

Egal ob der Change sofort umgesetzt wird oder nicht, die Lösung ist auf jeden Fall im Problem bzw. Known Error Record zu vermerken

Problem Abschluss

Nachdem der angeforderte Change umgesetzt und überprüft wurde, kann das Problem und alle verknüpften Records (z.B. Incidents) abgeschlossen werden. Alle relevanten Dokumentationen, Known Error, Wissensdatenbank, etc. sollen abschliessend noch auf den aktuellsten Stand gebracht werden.

Dies ist das vorläufige Ende meiner Serie zum ITIL Problem Management Prozess - weitere Serien werden folgen!  ;->

Einfach den Feed abonnieren 

Das Erkennen und Registrieren eines Problems ist die eine Seite - die viel wichtigere ist aber, die Ursache zu finden und eine Lösung zu erarbeiten.

Es ist davon auszugehen, daß du Ursache bei Problemen nicht ohne weiteres zu finden ist (denn ansonsten wäre das Problem schon lange gelöst). Es gilt also, spezielle Techniken und Tools anzuwenden, um eine möglichst effektive und effiziente Ursachen-Analyse durchzuführen.

Entsprechend der nachfolgenden Grafik befinden wir uns im Schritt “Problem Control” mit dem Ziel eine Ursache für das Problem zu finden.

Vortrag während der itSMF Fusion 2008 von Jay Long (gesehen im Blog IT´s About Uptime)

Oft verwendete Hilfsmittel zur Ursachen-Ermittlung:

• Recherche in den vorhandenen Wissendatenbanken (u.a. in Incidents und Known Errors)
• Fehler chronologisch nachstellen (im Detail inkl. Ablauf-Protokoll), um die Ursache besser eingrenzen zu können
• Brarinstorming - kein Kommentar ;–> Wikipedia
• “Pain Value” Analyse - (aus ITIL v3) berücksichtigt mehrerer Faktoren (Anzahl betroffene User, Dauer des Ausfalls, Kosten des Ausfalls, etc.) und versucht so die Priorisierung zu verfeinern (behandelt also nur indirekt die Ursache) –> Link
• “Kepner & Tregoe” Methode - Problem definieren, im Detail beschreiben, mögliche Ursache identifizieren, was ist wahrscheinlich, überprüfen. –> Wikipedia, dazu im Problem Mgmnt Blog, itsmsolutions Beitrag, kepner-tregoe.com
• Ursache-Wirkung (Ishikawa)-Diagram - kein Kommentar
  ;–> Wikipedia, itsmsolutions Beitrag

Eine Methode die von vielen Praktikern favorisiert wird ist die “5 Whys” Methode - übersetzt 5 x Warum. Es ähnelt ein klein wenig an Kindererziehung, aber das Ziel ist event. das gleiche - Finde heraus was wirklich dahinter steckt! Hier einige Referenzen dazu: wie immer gibt es alles bei Wikipedia, aber auch Hank Marquis von itsmsolution hat eine kurze Zusammenfassung, genauso wie Dennis Powell im StockSafe Blog.

!! >> Für eine möglichst effiziente Recherche in bereits bekannten Themen ist die laufende Pflege der Wissendatenbanken bzw. der Known Error Datenbank wichtit. Darauf ist bei der Umsetzung der Prozesse zu achten.

!! >> Um Problem nachvollziehen zu können ist meist ein Test-System hilfreich (ähnlich wie auch beim Test von Changes). Daraus  ergibt sich, bei so vielen Systemen wie möglich, zumindet eine 2-System Landschaft.

!! >> Ziel ist es Ursachen zu finden und Probleme zu lösen - immer die für die Organisation und das Problem geeignete Methode auswählen. Auf keinen Fall mit blindem Aktionismus an das Thema ran gehen.

weitere Referenzen:

• Problem Management Blog von Ronald Bartels

Bleiben Sie up-to-date und lesen Sie auch die nächsten Folgen! Einfach den Feed abonnieren 

Der Einstiegspunkt in den Problem Management Prozess ist die erste Hürde. Diese Schnittstelle zu z.B. Incident und Availability Management und der Ankerpunkt für alle Beteiligten (im Sinne des KVP) muss klar definiert und gut kommuniziert sein.

Allen Beteiligten muss bewusst sein, dass es im ersten Schritt lediglich um das Erkennen und Registrieren eines Problems geht - es geht noch nicht um die Lösung. (Motto: “Wer was sieht, der  schreibt es auf!“) Oft liegt ein Hindernis darin, dass sofort versucht wird, das Problem zu lösen. Da dies aber in vielen Fällen nicht sofort möglich ist, wird von einer Erfassung des Problems abgesehen.

Wo und wie können Probleme erkannt werden:

Erkennung durch den Service Desk (reaktiv)

Störungen, …
- die nur mit einem Workaround vorläufig gelöst wurden
- bei denen die wirkliche Ursache nicht gefunden wurde
- die immer wieder auftreten
- die ein Major Problem verursacht haben

Den Service Desk Mitarbeitern muss klar sein, in welchen Fällen ein Problem anzulegen ist.

Die gleiche Festlegung muss auch für die Mitarbeiter des Second Level (und alle weiteren IT Mitarbeiter) gelten, dh. es muss klar sein wann und wie Probleme anzulegen sind.

Hinweis von Dritten, Partnern oder Herstellern verwendeter HW od. SW (reaktiv)

Jeder Partner der IT Abteilung kann Hinweise zu möglichen Problemen geben. Dies kann aktiv durch den Partner erfolgen oder reaktiv durch Prüfung von Knowledge Base Einträgen o.ä.

Klar regeln, wer intern für die Erfassung solcher Probleme zuständig ist (z.B. alle Kontakte über Service Desk, Problem Manager, Partner Manager) - am besten der direkte Kontakt.

Erkenntnisse aus der Analyse der Incidents (proaktiv)

Sowohl Incident Manager als auch Problem Manager haben die Aufgabe durch laufendes Monitoring des Service Support-Geschehens Erkenntnisse zur Verbesserung der Prozess- und der Service-Qualität zu gewinnen.

Diese Aufgabe muss dem Incident und dem Problem Manager bewusst sein. (z.B. in die laufende Management-Tätigkeit mit einbauen oder als fixe Termine im Kalender vorsehen)

Bei der Definition der Kategorien bereits auf diese Aufgabe achten. Reports  und Trend-Analysen entsprechend definieren. (periodisch, automatisiert aufrufbar)

Jeder kann ein Problem erkennen (proaktiv)

Dies entspricht u.a. dem klassischen KVP (Kontinuierlicher Verbesserungs-Prozess). Jeder Mitarbeiter ist aufgefordert seinen Beitrag zur Verbesserung des Gesamt-Systems zu leisten.

Wichtig ist, die Kultur in diese Richtung zu verändern. Fehler und Probleme sind Chancen zur Verbesserung.

Das Verfahren, um Verbesserungs-Vorschläge platzieren zu können, muss so einfach wie möglich sein. (z.B. als Link auf einer zentralen Intranet Seite)

Dokumentieren des Problems

In allen oben beschriebenen Fällen, wo ein Problem erkannt wurde, muss ein sog. Problem Record angelegt werden. Dies dient zur Strukturierung und Sammlung aller weiteren Aktivitäten rund um das spezifische Problem.

Kategorisieren und Priorisieren

Um die gegenseitige Referenzierung zu vereinfachen gelten für die Kategorisierung und Priorisierung die gleichen Definitionen, wie im Incident Management.

Die Ursachen-Analyse kann zu einer Verfeinerung der Kategorisierung führen (u.a. für spätere Auswertbarkeit) - ist aber meist abhängig vom Tool.

Wenn die Prioritäten grundsätzlich gleich zum Incident Management gewählt werden sollen, so sollten die entsprechenden Bearbeitungszeiten u.U. etwas weiter gewählt werden. (z.B. im Wochen-Takt)

 Bleiben Sie up-to-date und lesen Sie auch die nächsten Folgen! Einfach den Feed abonnieren 

Wie im Titel erwähnt gibt es zwei grundsätzlich unterschiedliche Ansätze für das Problem Management:

Re-aktiv

• als Folge von Störungen und deren Behebung
• ausgelöst meist durch den Service Desk

Pro-aktiv

• abgeleitet aus der laufenden Verbesserung

Beide Aspekte müssen entsprechend umgesetzt werden, wobei der proaktive besonders zu beachten ist.

Schnittstellen Problem Management - in / out

• Change Management
  - an ChM: Übergabe von notwendige Änderungen
  - von ChM: Status und Feedback während der Entwicklung
• Configuration Management
  - von CMDB: Daten über betroffen CIs
• Release Management
  - an RM: über das Change Management

weitere:

• Availability Management
• Capacity Management
• Continuity Management
• Service Level Management
• Financial Management

Bleiben Sie up-to-date und lesen Sie auch die nächsten Folgen! Einfach den Feed abonnieren 

Das Problem Management versucht, wiederkehrende Störungen einer endgültigen Lösung zuzuführen. Es versucht in seiner proaktiven Ausprägung bereits zu reagieren, bevor etwas passiert. Das Problem Management ist damit Kernelement einer stetigen Verbesserung der IT Dienstleistungen und aus dieser Sicht ist es auch wichtiger als die reine Störungsbehebung (die ausschließlich reaktiv agiert).

Durch die  tiefergreifende Analyse von Problemen entsteht auch ein großer Beitrag zum Wissensaufbau in der IT. (siehe Known Error Datenbank, Wissensdatenbank, etc.)

Zusammenfassend steht das Problem Management für:

• Stabilisierung der IT-Services,
• Vermeidung von Störungen (Incidents),
• proaktive Optimierung der IT-Infrastruktur
• durch Ursachenanalyse, Erarbeitung von Lösungswegen, etc.

Prozess-Schritte

Der Prpblem Management Prozess besteht grob aus folgenden Schritten:

• Problem identifizieren / erkennen
• Problem dokumentieren / erfassen
• Problem klassifizieren & priorisieren
• Problem untersuchen (Ursachen-Analyse)
  ggf. Workaround dokumentieren
  ggf. Known Error dokumentieren
  ggf. Change anstossen
• Lösung
• Abschluss

Details zur Umsetzung der einzelnen Prozess Schritte in den nächsten Posts dieser Serie!

Bleiben Sie up-to-date und lesen Sie auch die nächsten Folgen! Einfach den Feed abonnieren 

In meiner täglichen Arbeit im Umfeld von IT Service Management stellt der Kontinuierliche Verbesserungs-Prozess im Allgemeinen und das Problem Management im Speziellen einen wesentlichen Bestandteil dar.

Viel zu oft wird das Problem Management als Vertiefung bzw. reines Abfallprodukt des Incident Management verstanden und damit zum Mitläufer degradiert. Genau das Gegenteil sollte aber der Fall sein - ein funktionierender KVP und Problem Management Prozess erzielen bei weitem mehr qualitätssteigernde Effekte als andere Prozesse.

Das laufende Erkennen von Chancen und Lernen aus Fehlern muss bewusst entwickelt werden. Jede aufgetretene Störung bzw. Abweichung von gemachten Definitionen birgt ein hohes Maß an Verbesserungsmöglichkeiten - die Fähigkeit dies zu erkennen und wahrzunehmen gilt es zu entwickeln.

Der KVP (Kontinuierlicher Verbesserungs-Prozess) ist keine ureigene IT Disziplin - es hat nichts mit Bits&Bytes, mit Programmen, System und dergleichen zu tun. Es ist am Ende (fast) eine Management Disziplin. Es kann sein, dass sich IT Leute deshalb damit so schwer tun - es ist eigentlich etwas Fremdes!

Aus diesem Grund widme ich mich in einigen nachfolgenden Posts speziell dem Thema Problem Management.

Hier die direkten Links zu den einzelnen Posts:

1. Überblick und Zielsetzung

2. Re-aktiv vs. Pro-aktiv & Schnittstellen

3. Probleme erkennen

4. Auf der Suche nach der Ursache!

5. Heureka und mehr

Bleiben Sie up-to-date und lesen Sie auch die nächsten Folgen! Einfach den Feed abonnieren 

• Sieben Sünden bei der Gestaltung einer Landing-Page
  (tags: Homepage)
• 10 Tipps für bessere Landing-Pages Webdesignblog
  (tags: Homepage)
• Landing-Page Optimierung
  (tags: Homepage)
• Neukundengewinnung im Internet
  (tags: Homepage)

• Plaxo - Stay in touch with the people you care about.
  Konzentrator für alle möglichen Social Network Sites. Mit dem Plaxo Widget kann man das gesammelte dann auf seiner Homepage einbinden. - Cool
  (tags: tools web2.0)
• www.hakin9.org - hakin9 - Security Magazin
  event. zu detailliert für mich ;->
  (tags: security)

Das Web 2.0 bietet unzählige Möglichkeiten mit anderen in Kontakt zu treten. Es gibt unzählige Sites, die zum “networken” einladen. Andrew Shuttleworth hat versucht, alle seine Web Aktivitäten an einem Punkt (in einer Grafik) zusammenzufassen. (siehe sein Blog-Post)

… Das muss doch auch für meine Web-Aktivitäten möglich sein!

Nun sind meine Aktivitäten eher als “kleine Anfänge” zu bewerten. (wenige Sites, wenige Beiträge …) Trotzdem - es wird von Tag zu Tag mehr und auch komplexer.

In Anlehnung an das Mindmap (hier als pdf) von Andrew - ein wirklich krasses Beispiel, wie ich meine - habe ich auch versucht, mein Social Network bzw. meine Internet Web 2.0 Aktivitäten in einem Chart zusammenzufassen.

(hier das Mindmap File)

Aktuell habe ich bereits alle für mich relevanten Informationen online verfügbar (Bookmarks, Dokumente!, Comments, RSS Feeds, viele Fotos, etc.)

Die Verlinkung - also der Information Flow - ist erst am Anfang. Meine Sites als Konzentratoren für meine Web Aktivitäten zu verwenden ist gerade im Aufbau!

Im Sinne des Social Knowledge Management (KM 2.0) - SHARE YOUR KNOWLEDGE !