Problem Management

Problem Management
by Armin Hasler
Um das Problem Management zu verstehen, muss man erst einmal den Begriff Problem definieren.
Ein Problem ist ein unbekanntes Problem oder ein Vorfall, welches mehrere Ereignisse nach sich
zieht und ein bekannter Fehler ist ein Problem, welches bereits bekannt und gelöst ist und für das
entweder ein work around existiert oder zumindest identifiziert wurde.
Das Ziel des Problem Managements
Das Ziel von Problem Management ist das Vorkommen von Fehlern innerhalb der IT zu
minimieren und deren Wiederauftreten vorzubeugen . Dies kann nur erreicht werden, wenn man die
Fehler an ihrer Wurzel packt und Richtlinien schafft, deren Methodik allgemein Gültigkeit besitzt.
Es gibt zwei Möglichkeiten auf Fehler zu reagieren. Der Erste ist auf das aktuelle Problem konkret
zu reagieren. Der Zweite, Fehlern vorzubeugen und bekannte Probleme von vornherein
auszuschließen.
Umfeld des Problem Managements
Um das Umfeld des Problem Managements zu erkennen, muss man erst die Bereiche identifizieren
in denen Fehler möglicherweise auftreten. Es gibt drei Bereiche zu denen diese gehören:
1. Problem Kontrolle
2. Fehler Kontrolle
3. Vorbeugendes Problem Management
Angaben zum Problem Management
•
•
•
Details zum Vorfall aus dem Vorfall Management
Details zur Configuration des Systems
bekannte work arounds
Hauptaktivitäten des Problem Managements
• Problem Kontrolle
• Fehler Kontrolle
• Die Vorbeugung von Fehlern
• Trends identifizieren
• Problem Management Daten archivieren und warten
• Die Probleme reviewen
Ausgaben des Problem Managements
• bekannte Fehler
• RFCs
• Problem identification
• work around
• solution
• gelöste Probleme abschließen
Idee hinter dem Problem Management
Die Verfügbarkeit von einfachen Tipps und Ratschlägen zu den Vorfällen und Fehlern und die
Möglichkeit diese effektiv zu lösen. Es gibt normalerweise nur wenige Fehler die dem Support
noch nicht bekannt sind. Und diese wurden meist von den Entwicklern bereits gelöst. Eine der
Aufgaben ist nun diese Lösungen oder work arounds den Kunden durch den Support
bereitzustellen, ohne den Entwickler erneut mit der gleichen (bereits gelösten) Problemstellung zu
konfrontieren. Grob zusammengefasst ist der Support also da, um als Schnittstelle zwischen
Kunden und Entwickler zu fungieren und die Arbeitszeit des Entwicklers vor alten Problemen zu
bewahren. Der Kunde auf der anderen Seite wird mit bereits behandelten Lösungen versorgt und
neue Kundenprobleme werden an den Entwickler weitergegeben.
Um diese Interaktion Handzuhaben muss ein geeignetes Instrumentarium her, dieses ist das
Problem Management. Eine weitere Aufgabe ist die Anzahl und die Dringlichkeiten der Vorfälle zu
reduzieren. Die Frage ist nun, wie wird das gemacht. Nun ein Teil der Aufgaben ist die
Dokumentation der Probleme und zu versichern, das diese Probleme sowie deren Lösungen in
geeigneter Weise zur Verfügung gestellt werden. Die Dokumentation alleine allerdings löst das
Problem noch nicht.
•
•
•
•
•
Die Problembehandlung muss indiziert werden, damit zusammenhängende Module
auf neue Vorfälle reagieren können
häufigere Inspektion der Dokumentation im Hinblick auf:
sich ändernde Technology
verfügbare externe Lösungen
Geschäftsanforderungen
Fähigkeiten der Mitarbeiter
Häufigkeit der auftretenden Fehler
Die Probleme sollten immer wieder reviewt werden
Das Personal sollte tiefergehende Kenntnisse der Prozesse besitzen
Das Vorfalls Management sollte durch ein geeignetes Tool gehandhabt werden
Wie aber können Probleme und Fehler identifiziert werden ?
•
•
•
•
•
Vorfälle identifizieren, wenn sie auftreten
Durch Tests
Die Struktur des Programms
Anlegen einer Wissens Datenbank
Durch Entwickler, wenn neue Produkte eingeführt werden
Ein bekannter Fehler ist ein von Grund auf erfolgreich identifiziertes Problem, welches durch ein
Work around eliminiert wurde. Das Ziel ist die Transformation von Problemen in bekannte Fehler
und die Fehlerkontrolle hat ihren Blickpunkt auf lösen von Fehlern durch das
Änderungsmanagement.
Was ist der Unterschied zwischen Incident Management und Problem Management ?
Das Hauptunterscheidungsmerkmal ist, dass das Hauptziel des Problem Managements darin liegt,
das Ursachen dieser zu erkennen und diese zu verhindern oder zumindest aufzuschlüsseln und zu
lösen. In diesem Zusammenhang ist Prävention das entscheidende Stichwort.
Das Incident Management hat dagegen die Aufgabe, dem Kunden die Unterstützung zukommen zu
lassen und ihm so schnell als möglich eine Lösung zu präsentieren. Dies wird meist durch ein Work
around erreicht und nicht durch eine permanente Lösung, die dem ursprünglichen Modell
Rechnung trägt.
Beim Problem Management ist das schnelle Auffinden einer Lösung, zumindest ein Work around,
eher zweitrangig. Meist liegt das Problem im Design des Moduls oder der Dll und lässt sich nur
durch die Analyse tieferliegender Probleme / nicht bedachter Ausnahmen und einer
Neumodellierung lösen.
Problem Kontrolle
Problem Kontrolle behandelt, wie bereits geschildert, die Auffindung der Wurzel des Problems.
Der Service Desk soll mit Informationen versorgt werden und mögliche work arounds angeleitet
werden. Das Ziel ist hier durch das Problem Management gleichzeitig, bei einer quick and dirty
Lösung wie dem work around, dieses möglichst effektiv zu gestalten. Die Priorisierung liegt hier
eindeutig auf Lösung von schwerwiegenden Problemen, welche sich geschäftsschädigend
auswirken können.
Zur Problem Kontrolle gehören:
• Problem Kontrolle und deren Aufnahme (recording)
• Problem Klassifizierung
• Problem Suche und Diagnose
Fehler Kontrolle
Die Fehler Kontrolle behandelt bekannte Fehler. Hierbei wird versucht diese iterativ, unter der
Kontrolle des Change Managements, zu eliminieren. Dies geschieht durch die Überwachung der
einzelnen Fehler und der Berücksichtigung von Kostenaspekten.
Aktivitäten der Error Kontrolle
• Fehlererkennung und Aufnahme
• Aufzeichnung über den Lebenszyklus des Fehlers
• Behebung des Fehlers
Proactive Fehlerbehebung
Ziel: Aktivitäten zur Fehlerprävention und Fehlerlösung bevor Probleme auftreten
Die Vorteile aus dem Problem Management
• verbesserte Qualität und verbesserter Service Desk
• Auftreten von Problemen und Vorfällen verringert sich
• permanente Lösungen werden gesucht und gefunden
• work arounds verringern sich aufgrund von Erfahrung (ask Google)
• Lernen aus der Vergangenheit
( A smart man learns from his mistakes, a wise man from the mistakes of others)
Probleme die Auftreten bei nur reactiver Fehlerbehandlung
• Support und Kundenbeziehung gestört
• Glaube an Qualität sinkt
• geringe Support Mitarbeiter Motivation
Planung und Implementierung
•
•
•
•
Das Incident Management muss funktionieren
bei anfangs knappen Ressourcen reactives Problem Managment
dann in Verbindung mit proactivem weiterentwickeln
zu Beginn nur die Top ten der Liste verarzten
Schlüssel zum Erfolg
•
•
•
•
einheitliche Klassifizierung und Registrierung von Vorfällen
Setzen von Nahzielen und Mitarbeitern Zeit für Problembewältigung lassen
Problem und Incident Managment müssen kooperativ arbeiten
Gleichgewicht zwischen beiden herstellen
Mögliche Risiken
• Das Management kann das Problem Management nicht richtig koordinieren und die
Entwicklung verschwendet zuviel Zeit mit dem lösen von Problemen oder work
arounds
• Das Unterminieren des Support desks führt zu Effektivitätsverlust
• Falsches Aufsetzen der Wissensdatenbank vermindert die Güte der Informationen
Aktivitäten der Problem Kontrolle
Das Auftreten von Vorfällen ist bei aller Vorsicht nicht zu vermeiden. Manche Fehler treten auch
nur durch den ständigen Ausbau der IT Landschaft auf. Durch die steigende Komplexität und den
höheren Aufwand bei Produkten kommt es durchaus zu Ausfällen, selbst bei Fremdherstellern.
Drei Phasen der reactiven Problem Kontrolle
• Problem Identifizierung und Aufzeichnung
• Klassifizierung des Problems
• Problembehandlung und Diagnose
Wann handelt es sich um ein Problem ?
• existierende Probleme und Lösungen stimmen mit dem neuen Vorfall nicht überein
• Analyse eröffnet vorhergehende Designfehler
Klassifizierung des Problems
• Kategory
• Auswirkungen
• Dringlichkeit
• Priorität
genereller Ablauf
1)
2)
3)
4)
5)
6)
Kategorisierung des Fehlers
Dadurch ist eine Gruppeneinteilung möglich
Dies ermöglicht Verantwortlichkeiten zu vergeben
Um Dringlichkeiten zu vergeben, Priorisierungsgrad erstellen
Die Gruppen lösen das Problem oder schaffen einen work around
Dokumentation des Problems + Lösung in der DB
Unterschied zwischen Dringlichkeit und Priorität
Die Vergabe von Prioritäten ermöglicht dem Management ein Instrument, um Dringlichkeiten zu
steuern. Hiermit wird auch die Fehlerbehandlung und das Vorgehen gesteuert:
•
•
•
•
gibt es eine quick and dirty Lösung ?
gibt es einen work around
kann die Planung zur Problemlösung verzögert werden ?
benötigen wir andere Zusatzprodukte / Module ?
Notwendigkeit für Problem Kontrolle
• Kooperation zwischen Vorfalls und Problem Management
• Die Unterschiedlichen Zielsetzungen zw. Vorfalls und Problem Management
müssen geeint werden und koordiniert werden
• Ein Koordinator sollte die verschiedenen Teams überwachen und Missstände
beheben
• Benutzung geeigneter Tools für das Support Personal
• geschultes Personal, welches Fehler erkennt und analysieren und priorisieren kann
• Dokumentationen müssen vorhanden sein
• Diagnose von Problemlösungen (zeitlicher Aufwand, Effektivität)
• Teile der Mitarbeiter sollten sowohl im Vorfalls als auch im Problem Management
integriert werden, um die verschiedenen Zielsetzungen zu vereinen
• Die Datenbank sollte immer mit den aktuellen Änderungen und deren
Dokumentation versorgt werden
Aktivitäten der Fehler Kontrolle
Fehlerkontrolle umfasst die Prozesse, welche sich um erfolgreiche Korrektur von bekannten
Fehlern bemühen. Das Ziel ist Komponenten zu ändern, um bekannte Fehler zu vermeiden und
Vorfälle so einzuschränken, dass Fehler gar nicht erst entstehen.
Fehlererkennung und Aufnahme
Ein bekannter Fehler ist erstellt, wenn das Problem von seinem Ursprung aus identifiziert wurde,
und ein work around erstellt wurde. Es gibt zwei Umgebungen, in denen Fehler auftreten können.
Die eine ist die kontrollierte Problem Management Datenbank und die andere ist die Umgebung mit
der die Entwickler arbeiten. Fehler die durch den Kunden identifiziert werden, müssen in der
Datenbank dokumentiert werden. Die zweite mögliche Fehlerquelle ist die
Entwicklungsumgebung. Wenn ein neues Paket released wird oder neue Sourcen ausgecheckt
werden, sind dies immer auch neue mögliche Fehlerquellen. Dies muss auch genauestens
dokumentiert werden.
Die Aktionen, die auftreten können, müssen transparent sein. So muss genauso wie das Problem
Management die Fehlermeldungen der Kunden archiviert das Change Management alle
Änderungen dokumentieren und zu den Änderungen die dazugehörigen Fehler oder Probleme
aufnehmen. Der Dokumentationsfluss muss in alle Richtungen funktionieren und zurückverfolgbar
sein.
Fehler durch Dritte
Fehler in zugekauften Komponenten müssen vom Hersteller gelöst werden. Dies hängt allerdings
immer mit dem Wartungsvertrag zusammen. Wenn dieser keine Änderungen bei einem
aufgetretenem Fehler vornehmen möchte und dies im Wartungsvertrag nicht genauer definiert
wurde, so ist die Kundenbindung wahrscheinlich dahin, aber der Aufwand für Änderungen gering.
Falls jedoch Änderungen vorgenommen wurden, so sind diese auch im Change Management und
der Fehler Kontrolle zu dokumentieren. Der Lösungsprozess für jeden Fehler sollte im Problem
Management dokumentiert sein.
Change Management ist verantwortlich für die Dokumentation und das Vornehmen von
Änderungen. Fehler Kontrolle ist verantwortlich für die Dokumentation des Änderungsprozesses
mit Bezug auf den eventuelle Lösung und dem Erstellen eines bekannten Fehlers. Das
Vorankommen sollte ebenso dokumentiert sein, wie eventuelle Prioritätsänderungen, weil ein
Fehler bei einem Kunden beispielsweise Vorrang hat.
Tipps zur Fehler Kontrolle
•
•
•
•
•
•
Nicht alle Fehler müssen oder können gelöst werden. Eine Organisation kann Fehler
als gegeben hinnehmen, wenn ihre Eliminierung zu teuer würde, oder es einfach
nicht möglich ist diesen Fehler zu lösen
Request For Change ist eines der Verantwortlichkeiten von Fehler Kontrolle
Es sollte zu jedem Fehler eine kurze Übersicht und ein Ranking geben
Fehler die aus Hardware resultieren, sollten dem Change Management unterstehen
Idealerweise sollten gemeinsame Software Tools für Vorfalls, Problem und Fehler
Kontrolle verwendet werden. Wenn dies nicht möglich ist, muss eine Schnittstelle
zur Kommunikation erstellt werden
Der Schlüssel zu effektiven Fehlerbehandlung ist die Daten, welche aus dem Fehler,
Problem und Change Management resultieren, verteilt zu behandeln
Proactives Problem Management
Die bisher beschriebenen Fehleraktivitäten umfassen das reactive Problem Management. Proactives
Problem Management befass sich mit dem Identifizieren und bekannten Fehlern, bevor Vorfälle
aufkommen und der Aufwand für den Service Desk und den Kosten minimiert werden kann. Das
Ziel hierbei ist die Vermeidung von Problemen. Dies umfasst ein besonderes Mass an Analyse, da
Fehlervermeidung vom Individuellen Verhalten des Entwicklers bis zur Bereitstellung von
Hilfemassnahmen für den Kunden reicht. Als Voraussetzung muss erst einmal ein komunikatives
Netzwerk installiert werden. Die Hauptaktivitäten des proactiven Fehler Managements beinhaltet
Analysen und hat ein besonderes Augenmerk auf Prävention.
Analysen
Vorfalls und Problem Management analysieren ständig die Software und dadurch hat man die
Möglichkeit aus den bisherigen Erkenntnissen unzuverlässige Komponenten oder
Designschwächen von vornherein zu identifizieren und diese zu ergründen.
Problemmanagement kann folgendes identifizieren:
• Probleme auf einer BS Plattform können auch auf anderen passieren
• die Existenz von immer wiederkehrenden Problemen
Die Ziel proactiven Problem Managements
Das Aufkommen von Fehlern lässt sich kaum vermeiden. Allerdings wird man immer ein
bestimmtes Gebiet haben, welches öfter Fehler produziert als andere. In diesem sollte man dann
verstärkt auf Fehlervorbeugung achten und einen „Schmerzfaktor“ einführen. Dies ist ein Konzept,
um die Dringlichkeit von Vorfällen zu kategorisieren. Dies wird in Form von Formularen erstellt,
z.B. durch:
• Die Anzahl der Vorfälle
• Die Anzahl der Kunden, welche von dem Problem betroffen sind
• Die Kosten der Vorfälle, in bezug auf Dauer der Lösungsfindung
• Die Kosten für das Geschäft
Hauptsächliche Fehler Sichten
Jedes Problem Management sollte auch ein Review auf sich selbst halten. Dazu müssen immer die
folgenden Fragen beantwortet werden:
• was wurde richtig gemacht ?
• was wurde falsch gemacht ?
• was können wir verbessern ?
• wie verhindern wir ein erneutes Auftreten des Problems ?
Schwache oder anfällige Komponenten bilden die Hauptanfälligkeit für Fehler. Diese
bestehen aus:
• der Anzahl von Problemen unterteilt durch:
Status
Service
Auftreten
Kategorie
Benutzergruppe
•
•
•
•
•
der verstrichenen Zeit von gelösten Problemen
der verstrichenen Zeit von ausstehenden Problemen
der verstrichenen Zeit um Problem Records zu erheben
irgendeiner kurzzeitigen Lösung
einer angenommenen Lösung für ausstehende Probleme
Periodische Treffen
Die Treffen sollen dafür sorgen, dass sich das Problem Management und das Support Team an
bestehende Prozeduren hält. Diese Treffen sollen aufgetretene Probleme reviewen und prüfen:
• das Berichte nach dem vorgegebenen Schema erstellt werden
• ein repräsentatives Beispiel, um den korrekten Ablauf nachzuweisen
• das Notfallpläne auch eingehalten werden könnten (theoretisch)
• Records auf ihre Eindeutigkeit und Richtigkeit
• die Dokumentation auf Korrektheit und das korrekte Einspielen von Updates
• das Reports erstellt werden und inhaltlich den Angaben entsprechen
• Trends und die proactiven Aktionen
• den Support
Tipps bei Metriken
• Keine Ziele setzen, die nicht erreicht werden können
• Metriken verwenden um Support Tools einzusetzen und den Ablauf der Produkt
Evaluierung zu garantieren
• Prozeduren entwickeln, um Berichte über Schlüsselkriterien zu erstellen
• Reviews in Hinblick auf die Anforderungen der Kunden erstellen
• den Effekt eines erfolgreichen Problem Managements sollte dokumentiert werden,
besonders im Hinblick auf den Nutzen den man dadurch erhält
• Service Management muss sicherstellen, dass Probleme die möglicherweise
auftreten, auf jeden Fall als Record erstellt werden
Rollen innerhalb des Problem Managements
Rollen werden benutzt, um Personen Pflichten und Rechte zu vergeben. Der Problem Manager hat
die Verantwortung für alle Aktivitäten innerhalb des Problem Managements.
•
•
•
•
•
•
•
Problem Kontrolle Prozess überwachen und weiterentwickeln
Die Effektivität des Problem Kontrolle Prozesses überwachen
Management Informationen erstellen
Die Problem Management Mitarbeiter überwachen und unterstützen
Ressourcen für den Support zur Verfügung stellen
die Effektivität der Fehler Kontrolle überwachen und verbessern
Reviews auf die Effektivität des proactiven Problem Managements
Wichtig hierbei ist, dass der Service Desk Manager und der Problem Manager unterschiedliche
Personen sind, da diese unterschiedliche Zielsetzungen haben.
Problem Support
reactive Verantwortung:
• Probleme identifizieren
• Probleme untersuchen
• RFCs erstellen um Fehler zu entfernen
• Überwachen des Fortschritts der Lösung von erkannten Fehlern
• Das Vorfalls Management instruieren, was der beste work around ist
• Identifizierung des Schlüssel Problems
proactive Verantwortung
• potentielle Fehlerquellen ermitteln
• RFCs erstellen, um wiederauftretende Fehler von vornherein auszuschließen
• Wiederholung von Fehlern in Modulen vermeiden