Giva ChangeManager ITIL Change Management Workflow Approval Process & Automated Notifications
Various Stages in the Change Management Life Cycle
What is the workflow approval process as a Request For Change (RFC) moves from the status of New, Planning, Pending, Approved, Scheduled, WIP, Closed and Rejected?
What are all the automated email notifications as a Request For Change (RFC) moves through the ITIL workflow process?
Giva ChangeManager Status Changes: Various Stages in the Change Life Cycle
Status = NEW (or REJECTED)
A User creates the RFC in eCM. When created, eCM automatically notifies 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 eCM 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, eCM 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 Pending Actions.
Status = PENDING
If the Pending Actions = "AWAITING APPROVAL," and the priority is "URGENT," then eCM notifies the CAB and the EC. If the Pending Actions = "AWAITING APPROVAL," and the priority is anything but "URGENT," then eCM notifies the CAB. If the Change Manager selects any of the other codes, eCM notifies the service group or the implementer if designated (i.e. if there is an implementer, eCM only notifies the implementer, not the service group). Some other Pending Actions 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 eCM notifies the implementer.
Status = SCHEDULED
When the status = 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, eCM 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 entered into RFC, 3) Service Desk enters negative impact of change and 4) the Change Manager completes a post-change review. At this time, the Change Manager selects a "Closed Code: and updates the RFC.
Giva ChangeManager Sample Notification Scheme
