hello list,

the supporters of the group that advocate first determining the success of the change and then, optionally/sporadically and time-delayed, having a PIR after that, argue that a change's results should be determined twice (quoting from http://technet.microsoft.com/en-us/library/cc535081.aspx , emphasis mine):

„After the release has been successfully deployed to all target groups selected for the rollout, the release is considered to be complete.

[…]

This, however, does not signify the end of the change management process. The change(s) now move to the change review process to evaluate and measure the success of the release in the production environment. This final review is called the post-implementation review (PIR).“

How could this be done in OTRS::ITSM?

Is taking the linked RfC ticket into account an appropriate way, closing the linked RfC ticket and using the change object to determine the overall, long-term success?


Thank you for all your opinions and comments,

Sven Ehret





Von:        sven.ehret@comdok.de
An:        "OTRS::ITSM User questions and discussions" <itsm@otrs.org>
Datum:        20.09.2010 16:30
Betreff:        [itsm] Antwort: Re:  Diskussion? Change Management, PIR
Gesendet von:        itsm-bounces@otrs.org





well certainly!

There is a discussion in our workplace about the proper usage of PIR in OTRS changes and I'd love to know your opinions.


One collegue is of the opinion that the change's state should be “pending PIR” until PIR has been performed. PIR should then determine if the change's state should be “successful” or “failed” and the change is complete. State Machine diagram:

(deleted)

The other collegue thinks that the change, after completing every work order but the PIR one, should be stated as “successful” or “failed”. The change should later be reinvestigated by PIR and after PIR, the change state should either be confirmed or changed. State Machine diagram:

(deleted)
(the direct connection between in progress and pending PIR would be for reasons of compatibility)


What would you think is better, more correct, more sensible? Or is it that both methods are flawed, would you do it differently?


I am looking forward to reading your opinions and comments! Kind regards,


Sven Ehret





Von:        
Leonardo Certuche <leonardo.certuche@itconsultores.com.co>
An:        
"OTRS::ITSM User questions and discussions" <itsm@otrs.org>
Datum:        
20.09.2010 16:04
Betreff:        
Re: [itsm] Diskussion? Change Management, PIR
Gesendet von:        
itsm-bounces@otrs.org




Hello,

I'd love to share my thoughts about this interesting topic but unfortunately I don't speak German. Any chance it could be translated and discussed in english?

Thanks,

Leonardo Certuche

www.itconsultores.com.co
Medellín, Colombia



2010/9/20 <
sven.ehret@comdok.de>
Hallo Liste,


in unserem Kollegenkreis gibt es einen kleinen Disput über die korrekte Anwendung des PIR und da interessiert mich natürlich die Meinung der Fachwelt.


Der eine Kollege meint, Status' eines Change bliebe stehen auf „Warten auf PIR“ bis der PIR durchgeführt wurde. Dann würde mit dem PIR der Status des Change auf „erfolgreich“ oder „fehlgeschlagen” festgelegt werden und der Change wäre fertig. Diagramm der State Machine:


(gelöscht)


Der andere Kollege ist der Meinung, dass der Change nach Abarbeitung aller Work Orders bis auf den PIR als „erfolgreich“ oder „fehlgeschlagen“ gekennzeichnet werden müsse. Einige Zeit später kann der Change dann wieder mit einem PIR aufgegriffen werden und der Status ggf. geändert oder bestätigt werden. Diagramm der State Machine:


(gelöscht)
(die Direktverbindung zwischen „in Arbeit“ und „warte auf PIR“ wäre nur aus Gründen der Kompatibilität)


Was wäre eurer Meinung nach richtiger, sinnvoller, besser? Oder sind beide Entwürfe schlecht, würdet ihr ganz anders vorgehen?


Ich freue mich über jede Meinung und jeden Kommentar! Beste Grüße


Sven Ehret


---------------------------------------------------------------------
OTRS mailing list: itsm - Webpage:
http://otrs.org/
Archive:
http://lists.otrs.org/pipermail/itsm
To unsubscribe:
http://lists.otrs.org/mailman/listinfo/itsm
---------------------------------------------------------------------
OTRS mailing list: itsm - Webpage:
http://otrs.org/
Archive:
http://lists.otrs.org/pipermail/itsm
To unsubscribe:
http://lists.otrs.org/mailman/listinfo/itsm ---------------------------------------------------------------------
OTRS mailing list: itsm - Webpage:
http://otrs.org/
Archive:
http://lists.otrs.org/pipermail/itsm
To unsubscribe:
http://lists.otrs.org/mailman/listinfo/itsm