I know what you are thinking restoration of service is Incident Management, but one should keep this in mind that Incident management and Change management is also connecting to each other. Later we Shall look more into this while discussing the KPI’s.
Some of the Key areas of determining the process and service value per change management, by the means of KPI’s are as follows :
Number of successful Changes performed in a particular time frame (Month/Quarter/ Half Yearly)
This will give you a clear output of work value that has been delivered to the client. However there are other factors which are required to look in for attaining this with high ratio.
Number of changes failed due to unforeseen or technical difficulties.
These are required to be minimal but often we have observed that even after doing the successful test run at the time of performing the change it gets failed.
This could be because of any hardware of software glitches.
While performing a critical change minute mistake such reading the disc allocation space would result in disaster , this are pure human error at engineering level.
While performing the change logged into the test server instead of Production machine…
Such instances are rare but not completely ignored while gauging the process and assessment of delivery.
Number of Emergency Changes performed due to or without Incident.
ECR request help in understanding the service flaws and need for improvement in services be it hardware upgrade/ script maintenance/Incident reporting /lead time issue that could have caused this ECR.
Number of Changes performed and completed successfully within the SLA
This gives you a clear idea of how SLA is being met at all level irrespective of priority of CR submitted.
Number of changes followed the lead time process correctly.
Lead time process and its adherence is important in the lifecycle of a CR any request failing this could easily be rejected or denied. This will cause further delay in service improvement.
Number of changes failed to approve due to some XYZ reason.
This factor will give insight into the approval process and would focus on checking if there is an improvement required to map the process more efficiently to improve the communication and notification among the service provider and customer.
Number of changes rejected during the lifecycle of a CR
Changes rejected due to failure of test results, Impact critical services, not following proper lead time, insufficient impact summary and details…etc
Number of high priority changes performed or high impact CR’s
This will give a clear value and understanding of ability to deliver and carter critical services at any given point of time. However this should have high success rate.
Changes performed during the business hours
There are certain changes which can only be performed during the business hours, due to non availability of different teams and the criticality of the CR’s being minimal and none impacting. Example is change raised to unrack the decommissioned a router as pick and delivery can only be feasible during the business hours.
Changes causing any service interruption during business hours.
There are certain go live projects which would require live users testing and analysis and thus required to be conducted during business hours as service provider one should not overlook this point. It could be rare but not illusive.
Related Post : KPI’s for Incident Management per ITIL