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
An: "OTRS::ITSM User questions and discussions"
Datum: 20.09.2010 17:16
Betreff: Re: [itsm] Discussion? Change Management, PIR
Gesendet von: itsm-bounces@otrs.org
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
---------------------------------------------------------------------
OTRS mailing list: itsm - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/itsm
To unsubscribe: http://lists.otrs.org/mailman/listinfo/itsm
