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