Irgendwann wird folgender UseCase besprochen: Ein Anwender hat eine Störung. Dieser meldet die Störung bei unserem Support, der dafür einen Incident aufmacht. Eine Analyse ergibt, dass ein Fehlerzustand (aka Bug) in der Anwendung Schuld daran ist. Es gibt keinen Workaround, der Anwender kann seine Arbeit nicht fortführen. Der Bug wird in Form eines Problems an die Entwicklung weiter geleitet, die Auslieferung erfolgt im Zuge eines Hotfix (Minor Release) 3 Tage später. Der Incident wird sofort geschlossen mit dem Vermerk dass der Incident sich erledigt hat, da in 3 Tagen „eh“ das Problem gefixt ist.
Jetzt die Gretchenfrage: Ich das richtig? Hat sich der Incident dadurch erledigt und ist zu schließen? Oder muss der Incident solange offen bleiben bis das Problem ausgeliefert wurde? Was sagt ITIL dazu?
Also ich bin mit meiner Meinung wie der UseCase abzuarbeiten ist alleine auf weitem Flur gestanden. Der Bulle vom Märchenpark hat sich beim Mittagskaffe auf meine Seite geschlagen, womit wir zu zweit auf weitem Flur waren. Welche Seite das war verrat ich nicht. Ich will ja niemanden beeinflussen. Eure Meinung zu dem UseCase?
Antworten bitte in Form von Comments zum Post und Abstimmung im Poll (rechts oben).
Posts
9 Kommentare:
Ganz klar. Incident bleibt offen, Request for Change wird angelegt und implimentiert. Das Service wurde ja nicht wieder hergestellt. Wird der Request geliefert, wird der Incident und der Request nach einem PIR geschlossen.
Der Argumentation meines Vorgängers kann ich nicht folgen. ServiceDesk eskaliert Incident in Form eines CFR in den 2nd Level weiter. Damit ist die Sache im Service Desk gegessen. Incident wird abgeschlossen. Service kann nicht hergestellt werden. Aber die Behebung wird in die Wege geleitet. Siehe Buch 3.
Indident ist zu schliessen. Lösung konnte nicht herbei geführt werden. Rest ist Sache der nachfolgenden Einheiten. In dem Fall würden die Incidents die RT beeinflussen und verfälschen. So wäre keine SL-Management haltbar. Da würde jeder Vertrag platzen. Der Incidentmanager würde den Bach runter gehen. Aus dem Auge aus dem Sinn.
Alles ist richtig. Wie jeder Mann und jede Frau weiß ist die Infrastructure Library eine Sammlung von Best Practices. Es kann also jeder machen was er/sie will. Wichtig ist das der Vorfall aufgenommen wurde und die weitere Bearbeitung getrackt wird.
MIKE
Incident nicht erledigt.
Support meldet Bug ein - wird an Entwickler weitergeleitet die das Problem beheben (sollten) - nach erfolgter Behebung des Fehlers wird der Fix in eine Testumgebung eingespielt um die QA testen zu lassen - QA gibt dann dementsprechend OK/NOK (=Incident erledigt/nicht erledigt).
Incident bleibt offen. Störung nicht behoben. Grüzzi aus der Schweiz!
VGW: INCIDENT erfassen - Analyse - PROBLEM daraus machen - CFR generieren - CFR umsetzen - schließne - PROBLEM schließen - INCIDENT schließen
Nicht schließen weil der Zusammenhang zum "Caller" (nebst Metainfo) sonst verloren geht - was ist wenn aus irgendwelchen Gründen der fix doch nicht deployed werden kann? Wie informiert man dann den Caller wenn der Incident bereits geschlossen ist? Was ist wenn der Fix das Problem des Callers (warum auch immer, z.B. Missverständnis) nicht löst? Den Incident im Problem zu duplizieren ist da ja noch schlechter.
Der Inc darf erst geschlossen werden, wenn der Caller die Lösung "confirmed" hat.
Incident bleibt offen bis der Kunde meldet, dass der Fehler gefixt ist. Aber nach Auslieferung des Fixes kann er auf solved gestellt werden.
Kommentar veröffentlichen