The post today is on the subject of Key Performance Indicators (KPI) for Service Level Management. I’ve posted about KPIs before, see Incident Management KPIs and Problem Management KPIs and of course the metrics white paper we have on our home page.
I’ll state again what a good KPI does: it tells us, as managers of a process, that the process is working (or at least, not fatally broken). So our Service Level Management KPIs should tell us that our SLM process is functioning, and point to weak areas where need to drive improvements.
Also bear in mind that not all KPIs actually come from your ITSM tool. Recently I was asked to comment on a customer’s Incident Management process, and prior to the day on-site I asked for KPI’s of the Incident Managers choosing to be ready for me to have a look at. To the customer’s great credit, amongst the data he produced were
- Meeting notes with service teams (where he was discussing some quality issues) from which action points were produced (with a plan for checking the actions where indeed actioned).
- Evidence of him checking and correcting Incident data quality issues (such as poor descriptions, poor resolution information and bad categorisation from some Service Desk agents).
- Call logging scripts he had introduced in the past 6 weeks.
(Although I wrote a 2 page summary afterwards, my conclusion was ‘you’re doing a great job’).
But I digress. Coming back to the point of this post, let’s have a look at some data you can use as a KPI. Some of these come from your ITSM tool, others not.
1. SLA in place? Do you actually have a well-drafted, clear and unambiguous SLA in place that is agreed by all the relevant parties? I’ve blogged about this earlier this month.
2. Are you reporting regularly? I’d look for evidence of reports being produced along the lines indicated in our white paper. Namely a summary of results, conclusions, weak areas and recommendations for improvement.
3. Availability against target for key services. Most customers seem to choose to express this as a percentage (eg, email service available 99.4% of the month as opposed to 99.5% target). If you are a Serio user, without question the best way to obtain these stats is through the tool itself, as I’ve blogged about here.
4. Customer satisfaction survey results. You can either use data recovered from customer responses after Incident resolution, or a monthly/quarterly survey, or both. These results can be hard to summarise so try to determine if the trend is up, down or neutral. Something like ‘customer satisfaction with our IT Helpdesk/Service Desk improved over the month’. If you are a Serio user, report svy_6 is a pretty good way to do this statistically.
5. Number of instances of service breach over the reporting period. This is linked to 3 – how many times, per service, did we have a service outage?
I’ll follow this up with a few more ideas in my next post.
[ Note from blog admin: the follow-up post is here ]