Results must be examined in the context of the objectives, environment and any external factors. Therefore after collecting the results, organizations will conduct measurement reviews to determine how well the indicators worked and how the results contribute to objectives.
Before starting to interpret the metrics and measures it is important to identify if the results that are being shown even make sense. If they do not, then instead of interpreting the results, take action to identify the reasons the results appear the way they do. The example used earlier in the chapter was of an organization that provided data for the service desk in which the data showed there were more first-contact resolutions at the service desk than there were incidents opened by the service desk. This is impossible and yet this organization was ready to distribute this report. When this kind of thing happens some questions need to be asked, such as:
n How did we collect this data?
n Who collected the data?
n What tools were used to collect the data?
n Who processed the data?
n How was the data processed?
n What could have led to the incorrect
information?
When beginning to interpret the results it is important to know the data elements that make up the results, the purpose of producing the results and the expected normal ranges of the results. Simply looking at some results and declaring a trend is dangerous. Figure 5.8 shows a trend that the service desk is opening fewer incidents over the last few months. One could believe that this is because there are fewer incidents or perhaps it is because the customers are not happy with the service that is being provided, so they go elsewhere for their support needs. Perhaps the organization has implemented a self-help knowledge base and some customers are now using this service instead of contacting the service desk. Some investigation is required to understand what is driving these metrics.
One of the keys to proper interpretation is to understand whether there have been any changes to the service or if there were any issues that could have created the current results.
The chart can be interpreted in many ways so it would not be wise to share it without some discussion of the meaning of the results. Figure 5.9 is another example of a service desk measurement. Using the same number of incidents we have now also provided the results of first contact resolution. The figure shows that not only are fewer incidents being opened, but the ability to restore service on first contact is also going down. Before coming to hasty conclusions, some questions need to be asked:
n What has happened that could drive down the
number of incidents?
n What would impact our ability to restore service
on the first contact?
n Did we hire new service desk analysts?
n Did we remove some services?
n Have we provided other means to access our
services?
n Have other processes been implemented that
could impact incident volume and first contact resolution?
In the case illustrated in Figure 5.9, the organization had implemented problem
management. As the process matured and through the use of incident trend analysis, staff were able to use problem management to identify a couple of recurring incidents that created a lot of incident activity each month. Through root cause analysis and submitting a RFC, a permanent fix was implemented, thus stopping the recurring incidents. Through further analysis it was found that these few recurring incidents were able to be resolved on the first contact. By removing these incidents the opportunity to increase first contact resolution was also removed. During this time period the service desk also had some new hires.
Table 5.7 provides a current view and year-to-date (YTD) view for response times for three service desks. It provides a transaction count for each service, the minimum response time measured in seconds, the maximum response time measured in seconds and the average for the month. The table also provided the YTD average for each service. In order to understand if these numbers are good or not it is important to define the target for each service as well as the target for meeting the SLA. When looking at the results for the three services it may appear that Service 2 is the best, and this might be because it handles fewer transactions each month than the other two services.
16,000 15,500 15,000 14,500 14,000 13,500 13,000 12,500 12,000 11,500
January February March April May June
Number of incidents
Number of incidents
opened
Figure 5.8 Number of incidents opened by service desk over time
Figure 5.9 Comparison of incidents opened and resolved on first contact by the service desk
16,000 14,000 12,000 10,000 8,000 6,000 4,000 2,000 0
January February March April May June
Number of incidents First contact resolutions
Interpreting that Service 2 is the best by only looking at the numbers is dangerous, however. Investigations will find that Service 2 is a global service that is accessed 24 × 7 and the other two services have peak time utilization between 8 am and 7 pm. This is no excuse because the services are not hitting targets so further investigation needs to be conducted at the system and component levels to identify any issues that are creating the current response time results. It could be that the usage has picked up, which was not planned for, and some fine tuning on components can improve the response time.