Details zum Vorfall aus dem Vorfall Management Details zur Configuration des Systems bekannte work arounds

Transkript

1 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

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

3 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

4 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) Kategorisierung des Fehlers 2) Dadurch ist eine Gruppeneinteilung möglich 3) Dies ermöglicht Verantwortlichkeiten zu vergeben 4) Um Dringlichkeiten zu vergeben, Priorisierungsgrad erstellen 5) Die Gruppen lösen das Problem oder schaffen einen work around 6) Dokumentation des Problems + Lösung in der DB

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

6 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

7 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 Periodische Treffen 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 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

8 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