A backout change means that a change was implemented and went live, but some induced problems resulted so the change must be backed out. There could be many reasons why an RFC would need to be backed out.
There is change Wrap Up tab in the RFC that has a Backed Out Reason field to add a descriptive narrative for the reason an RFC was backed out. There is also a Close Code in the RFC to select from a menu of short descriptions indicating if the RFC was closed Successful, Backed out, Successful with problems, Cancelled, etc.
Change Managers and the Change Advisory Board (CAB) use this report to gain insight for constant change process revisions for improving end-user satisfaction. The change management backout goal should be no backed-out changes. Reviewing data from this report can help you achieve that goal.
This report allows you to manage your ITIL backout RFCs by querying the system by Service Group, Priority, Scope, Change Category, and date range.
The following reports will assist the Change Manager and the Change Advisory Board (CAB) in increasing the number of successful changes. A root cause analysis of why any changes were backed out and why some changes induced problems will help increase the number of successful changes in the future. The change team should review any induced service requests that are attached to RFCs. It is also helpful to understand why changes were rejected.
When Giva customers focused on root cause analysis with just these reports, they experienced a very significant increase in satisfaction from the business teams and customers that they serve. With Giva you can achieve the same!
- Successful RFCs Report
- Backed Out RFCs Report
- RFCs by Induced Problems Report
- Change Rejection Reason Report
- RFC Closed Code Report
