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: 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: (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

My installation is only conducting PIRs for failed (having caused some sort of problem after deployment) and unreported (someone did something without first documenting it and got caught). If the change appeared to have achieved the desired results we set it to Successful and we are at end of job. Best regards, Jim ITIL Process Manager NCDOR 919-715-4932 919-696-0056 - cellular james.burk@dornc.com

...

...

9/21/2010 5:38 AM >>> 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 ----------------------------------------------------------------------------- E-Mail correspondence to and from this sender may be subject to the North Carolina Public Records Law, and may be disclosed to third parties. ------------------------------------------------------------------------------

Hi english guys, ;-) On 20.09.2010, at 23:05, Nils Leideck - ITSM wrote:

On 20.09.2010, at 21:04, sven.ehret@comdok.de wrote:

...

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

Position 1 ist in OTRS ITSM zunächst die richtige Beschreibung. http://doc.otrs.org/itsm/2.0/en/html/x759.html#change_state_machine

Jedoch ist dies nur die Empfehlung, wenn Euer Prozess Anderes vorsieht, kein Problem. Achte bitte darauf, “failed” und “successful” sind *END* Status, also von dort gibt es (noch) kein zurück mehr ;-)

Ein gangbarer Weg, den Deine beiden Kollegen evtl. akzeptieren, ist nach dem “in progress” einen ergebnisneutralen Status “implemented” oder “finished” oder ähnlich einzuführen. Dieser besagt dann nur das alle Aktionen (WorkOrder) “erfolgreich” durchgeführt wurden (ansonsten sollte eh’ der Change abgebrochen werden (rejected, canceled, etc.)). Danach kann dann der PIR laufen (je nach Prozess kann dieser zwischen ein paar Minuten oder mehreren Monaten dauern).

Position 1 is the most suitable description when following OTRS ITSM http://doc.otrs.org/itsm/2.0/en/html/x759.html#change_state_machine But this is just a recommendation based on our experiences, if your process has been described differently, feel free! Please take care of the “failed” and the “successful” status as these status are so called *END* status and (until now) there is no way to get back to another status from there. A practicable configuration, which could be accepted by both of your colleagues, might be to setup a resolution-independent status like “implemented” or “finished” or similar (I do prefer "implemented”). This status is then used to state that all actions (WorkOrder) are done succesful (otherwise the Change should be set to “rejected”, “canceld”, etc.). Afterwards you can start with your PIR (based on the process these part can take some minutes or even up to some months). Freundliche Grüße / Kind regards Nils Leideck -- Nils Leideck Senior Consultant nils.leideck@leidex.net nils.leideck@otrs.com http://webint.cryptonode.de / a Fractal project