Kann ein Incident geschlossen sein und trotzdem daraus ein Problem entstehen? Oder entsteht aus einen Incident ohne Lösung generell ein Problem? Bzw. wie sieht ein Bsp. aus bei dem ein Incident geschlossen ist aber dazu ein Problem existiert? Wir dann auch im geschlossenen Incident auf das noch offene Problem referenziert?
Bzw. kann ein Problem geschlossen werden obwohl es dazu einen RFC ( Request of Change) gibt.
Wie ist da der Ablauf?!
Kann ein Incident geschlossen sein und trotzdem daraus ein Problem entstehen?
Bitte sieh’ Dir hierzu den Incident Workflow an.
„Geschlossen“ heißt normalerweise: „Vollständig bearbeitet - es erfolgt keine weitere Aktivität“.
Je nach Implementierung des Workflows kann es aber einen „Reopen“ Status geben (ist in vielen Unternehmen unerwünscht, da es einem brauchbaren Reporting tierisch in die Quere kommt) oder es wird anhand des Incidents ein Clone erstellt, den man dann zum Problem forwarded.
Damit wäre es dann denkbar.
Oder entsteht aus einen Incident ohne Lösung generell ein Problem?
Dazu verweise ich am besten auf die Definitionen.
„Incident“ ist erst einmal ganz neutral ein Ereignis, welches gemeldet wird.
Am Service Desk kann man dann entscheiden, ob es sich bei diesem Ereignis um ein Problem, oder wasauchimmer handelt.
Im Normalfall gibt es Geschäftsregeln, die besagen, wann ein Forward in eine bestimme Klasse erfolgen soll. Denn hinter jeder Aktivität stehen natürlich Kosten für das Unternehmen, und die möchte man nicht für jeden Incident in voller Höhe tragen.
Ein ganz reales Beispiel:
Ein Kunde möchte das Online-Zahlsystem der Firma „ABC-Def“ nutzen.
Leider bekommt er beim Anmelden eine Fehlermeldung. Er meldet dies natürlich erst einmal als Incident.
Dann probiert er das Ganze noch einmal, und es funktioniert.
Das eigentliche Problem, dass ein Kunde beim Einloggen eine Fehlermeldung erhält, ist nicht gelöst. Aber da es nicht wieder auftritt, ist eine Bearbeitung des Incidents nicht ökonomisch, man schließt den Incident.
Wenn jetzt allerdings viele Kunden über das Gleiche (bitte, wir sind nicht beim ITIL-„Problem“ sondern beim freisprachlich-deutschen) Problem berichten, dann scheint dort ein Prozess- oder Softwarefehler vorzuliegen.
In dieser Situation könnte anhand eines Reportings über Incidentklassen das Management entscheiden, aus den einzelnen Incidents einen Sammelincident zu machen, und jenen zum Problem zu eskalieren.
Das wäre aber nicht im Standardprozess des Service Desks verankert.
Bzw. wie sieht ein Bsp. aus bei dem ein Incident geschlossen ist aber dazu ein Problem existiert? Wird dann auch im geschlossenen Incident auf das noch offene Problem referenziert?
Ahum… das ist alles eine Frage der Realisierung. Ich behaupte jetzt einfach mal „Nein“.
Aus objektorientierter Sicht sind sowohl Incidents als auch Problems usw. - lediglich Service Objects.
Diese Objekte gehören zu einer generalisierten Basisklasse (am Einfachsten - Incident) und können im Rahmen der weiteren Bearbeitung im Rahmen eines Interfaces aus verschiedenen Perspektiven betrachtet werden, z.B. Problem. Damit bleibt das „Problem“ datentechnisch ein Incident, nur halt über das „Problem“ Interface referenziert.
Da ein eindeutiges Objekt jedoch nicht gleichzeitig im Status „Offen“ und „Geschlossen“ sein kann … naja, genau wie ein Fenster halt.
Die Ausnahmen wären halt, siehe oben, ein geklontes oder ein Sammel- Objekt.
Wobei… mit dem Klonen halst man sich in solchen Situationen ziemliche Schwierigkeiten auf.
Bzw. kann ein Problem geschlossen werden obwohl es dazu einen RFC ( Request of Change) gibt.
„Request for Change“, oder kurz „CR“.
Natürlich! Das passiert in der Praxis täglich, typischerweise eben aufgrund der Hauptfaktoren Budget und Zeit.
In einem lebensfähigen Prozess sollte daraus allerdings im Rahmen eines möglichst automatisierten Mechanismus der CR auch schnellstens gestoppt werden - sonst entstehen unnötige Kostentreiber (Stichwort: KVP)
Gruß,
Michael