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
<nils.leideck@leidex.net>
An:
"OTRS::ITSM User
questions and discussions" <itsm@otrs.org>
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