ich habe ein, zwei Fragen zum Problem Management.
Nach Analyse, Workaround- und Ursachenermittlung mit Erkennen eines Lösungsansatzes wird ein Known Error Reocord erstellt.
In einem Ticketsystem, ist es immer zwingend ein separates Ticket, oder kann auch innerhalb eines Problemtickets ein Statuswechsel das Ticket als „Known Error Reocrd“ markieren?
Dann wird von Klassifizierung, Kategorisierung und Priorisierung gesprochen.
Meinem Verständnis nach Ist Klassifizierung der Oberbegriff, in dem neben Fehlerbeschreibung die Kategorisierung und Priorisierung durchgeführt wird. Richtig, oder habe ich nur noch keine ordentliche Beschreibung gefunden?
Zum Prozess selbst, welche Prozessschritte sind verpflichtend? Erkennen, (Klassifizieren),Diagnose,Behebung, Prüfung, Abschluss? Fehlt noch etwas?
Womit auch auch noch auf dem Kriegsfuß stehe ist das Mayor Problem. Eine Rückschau auf ein Problem, damit es in Zukunft nicht mehr auftritt, da mit der Behebung die Ursache doch vollständig behoben werden sollte (wir ja schließlich im Abschluss geprüft), sollte ein derartiger Fehler doch sowieso nicht mehr auftreten. Aber gut, wenn ich davon ausgehe, dass es Fehler gibt, die so übergreifend sind, dass hier ein Audit auf den ganzen Fall durchgeführt werden muss - oder Mayor Problem - wird dazu dann eine Separate Protokollierung benötigt, oder nimmt man zur Dokumentation einfach ein Standard Problemticket und „benennt“ es einfach dementsprechend?
Und nochmal zum Known Error. im IT Process Wiki steht „Ein Known Error ist ein Problem mit einer dokumentierten zugrundeliegenden Ursache und einem Workaround“
Weiter unten steht allerdings „Ein Vorschlag zum Erstellen eines neuen Eintrags in der Known Error Database“
Meinem Verständnis nach kann ich keinen Known Error eröffnen, da ein Known Error ein diagnostiziertes Problem ist. Also nur ein <Hier haben wir einen Fehler, der Incidents verursacht, aber wir kennen schon die Ursache und haben einen Workaround, also können wir die Auswirkungen genau eingrenzen und hoffen, es bald beheben zu können>.
Einfach einen Eintrag in der KEDB zu erstellen würde für mich bedeuten, dass man einen Fehler einprogrammiert hat, der Grund dafür klar ist und nur kein Geld da ist um ihn zu beseitigen. Aber vielleicht habe ich da nur ein Denk-Problem.
Das hängt davon ab wie Du den Prozess vorher definiert hast. Wenn Du den Prozess optimieren willst wäre das ratsam, oder?! Dann sollte natürlich auch da ein Verweis zur KnownErrorDataBase sein.
Die die Du definierst. ITIL ist ein Massnahmenkatalog den Du ja definierst. Ohne praktischen Ansatz ist das eher recht theoretisch und eher sinnfrei
Kommt auch wieder auf Deinen Prozess hierzu an. Aus praktischer Sicht ist es natürlich ratsam hier Tools zu nehmen, die eh schon im Einsatz sind also ein Ticketsystem. Wenn der Problem Manager das Mayor Problem definiert bzw. gekennzeihnet hat (durch Markierung, extra Ticket, etc.) dann wird dies mit den Infos aus den verschiedenen Quellen (z.B. Error DB) gefüllt und daraus die Lösung ermittelt. So kann man dann später wenn ähnliche Probleme (auch Majoy Problems) auftreten auf dieses als Referenz verweisen.
Ein knownError ist ja etwas, das öfters auftaucht. Das hat vorher der problem manager oder Ticketbearbeiter entsprechend im Team oder sonstwie festgelegt. Das heißt das Problem kommt, der Workaround dazu wird erarbeitet und das Ticket erfolgreich abgeschlossen. Wenn DANN dasselbe Problem beim selben System oder einem anderen auftaucht, dann verweisst Du auf das „alte“ erfolgreich geschlossene Ticket und hast somit einen knownError. Wie der genaue Ablauf dazu ist, ist eben zu definieren steht in der Prozessdokumentation.
Richtig. Du denkst schon zu weit. Oder anders… Wenn das Problem in der KEDB steht und x-mal auftaucht sollte ein anderer Prozess angestossen werden, der eben dazu führt das Geld in die Hand genommen wird. Dazu gibts aber eben entsprechende prozessschnittstellen in andere Geschäftsbereiche, etc.
Ich hoffe Du kennst schon das Paradebeispiel der Apollo Mission (eines von mehreren Szenarien in der ITIL Prüfung ) denn da merkt man recht schnell das sich der Prozess eben auf den technischen bereich auswirkt. Enjoy.
sorry, für die späte Reaktion, ich war etwas eingespannt und dann bin ich schnell in den Urlaub abgehauen.
Ich danke dir vielmals für die ausführliche Antwort und werde sie mir noch das ein oder andere Mal zu Gemüte führen.
Das Apollo-Beispiel kenne ich nicht, mal sehen, was ich dazu finde.
die das meiste habe ich nun verstanden, nur mit dem Knownerror stehe ich immer noch auf Kriegsfuss.
Der Ablauf ist nun folgender, das Problem wird nach Erkennen protokolliert und priorisiert. Dann wird die Ursache ermittelt und anschließend nach Ermessen und Kosten/Nutzen Rechnung behoben, geprüft und geschlossen.
Nebenbei „kann“ man ein Knownerrorticket eröffnen, wenn ein Workaround benötigt wird, bzw. wenn dieser einer breiteren Personengruppe zur Verfügung gestellt werden muss (Incident-Bearbeiter)
Dann kann man noch ein KE-Ticket erstellen, wenn ein Fehler innerhalb der Entwicklung aufgetreten ist, ebenfalls um die Incident-Bearbeiter mit Informationen zu versorgen.
Das heißt für mich, dass der Knownerror eher so eine Art „Nice to have“ ist, man kann ihn eröffnen, wenn man es für sinnvoll hält, oder man läßt es bleiben.
Das bedeutet für mich, dass die Anzahl an Known Error sehr viel geringer ist, als die Anzahl offener Problems.
Ist das so richtig?
