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"
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
An: "OTRS::ITSM User questions and discussions"
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
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
