thank you. Your idea to implement a stat “implement” is interesting. If I understand correctly, the change's state machine would be as in this diagram:
But there is someting that I do not understand. From my point of view, the change's states are changed automatically by the states of its work orders. Appropriate conditions for such a case without the new “implemented” state would be: if the change's approval work order has the state canceled, set the change state to rejected. if the change's approval work order has the state closed, set the change state to approved. if any work order but the PIR work order has not the state created, set the change state to in progress. if any work order has the state canceled, set the change state to failed. if all work order has the state closed, set the change state to pending PIR. if the PIR work order has the state closed, set the change state to successful. if the PIR work order has the state canceled, set the change state to failed. Is this the right approach? If so, how could the “implemented” state automatically be set? Does anyone find it adviseable to implement “successfully implemented” and “unsuccessfully implemented” as new states? Thank you and best regards Sven Ehret Von: Nils Leideck - ITSM <[email protected]> An: "OTRS::ITSM User questions and discussions" <[email protected]> Datum: 20.09.2010 17:16 Betreff: Re: [itsm] Discussion? Change Management, PIR Gesendet von: [email protected] Hi english guys, ;-) On 20.09.2010, at 23:05, Nils Leideck - ITSM wrote: On 20.09.2010, at 21:04, [email protected] 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 [email protected] [email protected] http://webint.cryptonode.de / a Fractal project --------------------------------------------------------------------- OTRS mailing list: itsm - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/itsm To unsubscribe: http://lists.otrs.org/mailman/listinfo/itsm
<<image/jpeg>>
--------------------------------------------------------------------- OTRS mailing list: itsm - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/itsm To unsubscribe: http://lists.otrs.org/mailman/listinfo/itsm
