Thanks dboyes and guenther. Feedback much appreciated. Guess I had missed a role somewhere along the line! Guess I had been trying too hard with SysConfig, to move the states manually!! I am testing before roll-out and have almost everything else running except for CMDB and Change Management. Your input should see me through!
On 11 June 2012 07:33, David Boyes <[email protected]> wrote: > I think what he's looking for is a walkthrough of what the roles are in > the change process, and what the steps are to walk through a change (who > does what at what point). The existing documentation doesn't really address > this at all at the moment. > > Madlenkosi: > > The major roles involved in changes are: > > Change Requestor – the person requesting the change and submitting the > change request and change documentation. > Change Approver – decision maker, often aka change management board > Change Manager – person in charge of guiding the implementation of the > change > Change QA – person in charge of verifying the change was completed (may be > same person as change manager). > > Using your states: > > The Change Requestor creates a change request using a change template, > producing a Change in state "Requested" and specifying a id or group that > is capable of approving the change (defined in the Change module as a > Change Approver. This is usually your change management board or a similar > part of your organization). > > The Change Approver goes through the change request, ensures that all the > documentation required at your site is present and complete (and delivers > whatever justification your company thinks appropriate), and sets the > change to Approved or Denied. If the change is approved, a Change Manager > is assigned from the pool of OTRS ids defined as Change Managers. > > The Change Manager schedules the change and moves it to state Under > Implementation. He/she manages the preparation of delivery of the change > and associated work orders. > > When the change is executed, the Change Manager sets the state to PIR > (Pending Internal Review) at the completion of the changes, and passes it > to the Change QA person. If the Change QA person is different than the > Change Manager, the Change QA person verifies the that the change is > complete and operating as required. If correct as specified in the change > and the change tests out as operating correctly according to the change > test plan, the Change QA person sets the change state to Successful and > sends it back to the Change Manager. If the Change QA person is the same > person as the Change Manager, the Change Manager performs the verification > and setting the state appropriately. > > If the change fails verification, then the Change Manager should initiate > the backout of the change according to the backout steps in the change > request. > > If successfully verified, the Change Manager then sets the state of the > request to Closed. This should notify the Change Requestor that the change > is complete. > > So, at a high level, what you need to do is: > > > 1. Define the required change documentation in your organization. > This is by far the hardest step… 8-) You should make sure that backout > steps are part of the change documentation unless your change management > process has the power to yank people out of bed at 3 AM when a change > fails. Yes, it's more work for the change requestor, but consider the 3AM > case. No one wants to get out of bed at 3 AM for a skipped step, and it's a > self-correcting problem if the submitter's manager gets an escalation and > gets hauled out of bed too. 8-) > 2. Outline and publish the change process as described above and get > top-executive backing to enforce the process (also hard, but critical to be > successful) > 3. Define change templates (usually one for pre-approved small > changes, an emergency change template that contains a way to describe the > emergency and justification, and one for complex changes that require full > change business cases and documentation will do for starters) > 4. Define the OTRS ids that are allowed to initiate changes in the > ITSM change module. > 5. Define the OTRS ids that can approve changes in the ITSM change > module > 6. Define the OTRS ids that are designated as change managers in the > ITSM change module > 7. Define the OTRS ids that are designed as change QA (if different > from 3) > 8. Train people in your organization for the roles explained above. > 9. Execute. > 10. Declare victory and move on to the next impossible task. Breakfast > is waiting. 8-) > > > Note that for effective change control you should NOT allow arbitrary > manual changes to change requests. If you can circumvent the process, then > you don't have control over the changes you make. If your id is correctly > defined in one of the roles, the commands to advance requests to the next > step will appear in the Change menus. > > > > * > * > Hello, you can set these states under conditions or also go into the > sysconfig and allow manual setting of states. Regards Günther > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > Mandlenkosi Mketwa <[email protected]> wrote: >> >> Hie, >> How do I get the change module to work? I need flow of how it works as I >> get stuck with a ticket staying on "Requested". How do I change status >> from, Requested ->Approved->Under Implementation->PIR->Successfull->Closed >> ? >> >> -- >> >> Mandlenkosi Mark Anthony Mkhethwa[ESQ] >> >> >> > --------------------------------------------------------------------- > OTRS mailing list: otrs - Webpage: http://otrs.org/ > Archive: http://lists.otrs.org/pipermail/otrs > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs > -- Mandlenkosi Mark Anthony Mkhethwa[ESQ]
--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
