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 <mkheth...@gmail.com<mailto:mkheth...@gmail.com>> 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
