"Day in the Life" Demonstration

IT Change Manager

<< 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 >>

Status Change Flow Chart

Various stages in the change life cycle

Status = NEW

A User creates the RFC in Giva eChangeManager. When created, Giva eChangeManager automatically the Change Manager. The Change Manager approves the change in concept or rejects it. If he approves it, status = PLANNING. The service group field is completed and Giva eChangeManager automatically notifies the service group via an email. If he rejects it, he makes status = REJECTED and completes the rejected reason fields. The Change Manager should also write a brief description of the rejected decision in the Change History field. When the Change Manager updates the record, Giva eChangeManager automatically notifies the requester.

Status = PLANNING

The implementer or service group develops the implementation, test and backout plans. He documents this information in the change record or in attached files. By the end of the PLANNING stage, the Service Group must complete the "Implementer," the "Builder" and the "Tester" fields. When the planning is complete, the service group or implementer notifies the Change Manager as follows. They put a note in the Change Record History and they click the "Notify Change Manager" button. He will get an email with a copy of the note requesting his review. The Change Manager sets the status = PENDING and selects one of the Waiting Codes.

Status = PENDING

If the Waiting Code is "AWAITING APPROVAL," and the priority is "URGENT," then Giva eChangeManager notifies the CAB and the EC. If the Waiting Code is "AWAITING APPROVAL," and the priority is anything but "URGENT," then Giva eChangeManager notifies the CAB. If the Change Manager selects any of the other codes, Giva eChangeManager notifies the service group or the implementer if designated. Some other Waiting Codes might be "Implementation Plan Development," "Test Plan Development," or "Backout Plan Development." When the Change Manager gives his approval, he changes the status = APPROVED.

Status = APPROVED

The Change Manager changes the status to APPROVED if: (1) receipt of all change documentation has occurred and (2) approval from the CAB and/or EC. The approval process usually includes a meeting to discuss changes. This is where any objections or modifications to the implementation process take place. The CAB and EC give their approval for the Change Manager to move forward with the change process. When all is in order, the implementer is designated, the scheduled date set, the status = SCHEDULED and Giva eChangeManager notifies the implementer.

Status = SCHEDULED

When the status is SCHEDULED, the change appears on the Forward Scheduled of Changes Report. This is the most critical of change reports for the helpdesk. It provides them with all scheduled changes and allows them to prepare their support accordingly. When the implementer is ready to implement the change he changes the status to status = WIP.

Status = WIP

When the status moves to this state, Giva eChangeManager notifies the Requester and Customer. Upon completion of the change, the implementer updates all relative fields in the change record. He notifies the Change Manager that he is complete by clicking the "Notify Change Manager" and updating the record. After the Change Manager completes a post change review, he changes status to status = CLOSED.

Status = CLOSED

Status changed to "CLOSED" after: 1) Requester confirms change; 2) all documentation is entered into RFC, 3) negative impact of change noted in the Induced Problems field and 4) the Change Manager completes a post-change review. At this time, the Change Manager selects a "Closed Code" and updates the RFC.

Status = REJECTED

Status changed to "REJECTED" can happen at any time. Notification automatically goes to the requester.

<< 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 >>