Reporting

Many IT organisations have suffered from a poor relationship and image with their customers. Often this has been because of poor service and delivery issues, however, in many cases, this is really due to poor communications. A key recurring issue, in particular, is the inability of the IT team to present meaningful, honest, and relevant information about what they do and how it delivers value.

What tends to be produced is simply IT’s view of what is important – i.e what it does. The focus also of this reporting also often fails to capture the actual impact and relevance to the customer of what has or hasn’t been delivered.

In short, IT tends to report on what it does not how it delivers value. This has a double negative effect on the customer – if they have had a bad service experience they don’t want to then be told by IT that everything is OK and that IT has done a great job…!

This is where poor SLAs really doesn’t help as well, if they don’t reflect the real business need, and are then followed (too much) to the letter by the IT organisation. SLAs and the associated reporting output must relate to services and not just IT technical components.

Would you sign up for a warranty on just one or two of your car’s tyres? Or only certain parts of the engine? Or the axles but not the brakes? Of course not.

So if SLAs are set for server availability at 99.x – the SLA could be met but the customer won’t be happy if there is a failure within the permitted downtime but which occurs during a key business time. We still tend to churn out reports about blanket incident management and availability and SLA performance, expecting customers to be interested and thank us, whereas we could provide them with much more focused information about how we have or haven’t delivered their service to meet their business needs.

So reporting needs to be about the customer and business-relevant SERVICES, not systems or its processes, and where possible it should relate to specific BUSINESS OUTCOMES.

We have to step out from behind the PC and really demonstrate to our customers that we understand what they do and need from us, and then ‘walk the walk’ on this by presenting the information on our performance in an appropriate way for them. When we do this we start to build some trust and confidence in our relationship with our customer – there’s no trust and little forgiveness if the customer is unhappy and doesn’t believe the reports they are being given.

I am text block. Click edit button to change this text.

So How Do We Do This?

Following the previous ITSM goodness steps will move you to a position where you have engaged with your customer and defined your service structure, s well as looking at the quality of process and service desk delivery. Steps 1 and 2, in particular, provide a solid basis to drive your reporting – i.e. being based on customer engagement (what’s important to them) and service structure (how IT can focus on doing the right things.

Ideally, you will want to produce simple summary metrics and dashboards for your customers that represent the ‘bundle’ of actions that combine to deliver a ‘service’ to them. So a RAG report on the ‘finance’ service may include some key availability measures of a variety of systems (e.g. at specific times for fund transfers), plus support performance (thresholds on incidents), plus some customer feedback and perhaps a key metric (like successful processing of a purchase or sales transaction, or on a wider scale, whether financial processing deadlines are met).

One thing to note here is that it’s not as if the existing reporting that you have been producing is now irrelevant or useless – it’s just that it’s only part of the picture and needs to be developed and focused on services. Presentation is also an issue and often the same data can be transformed with a fresh, summary, and service-orientated graphic. So the traditional ITSM reports are the building blocks rather than the finished product that goes to the customer.

Key Points

1. Use the service structure and business input to drive reporting
2. Think about a single page RAG view and work backwards
3. Give teams and individuals the right information for them – in appropriate format and media for them
4. Establish a variety of regular reporting views and outputs Keep checking and reviewing for relevance and currency
5. Regularly refresh the reports and check for relevance and actual use
6. It’s important to identify what is done with reporting – i.e. does it kick off improvement activity Use service reporting as the basis for your continual improvement action – not as a separate process, but as a regular universal and ongoing activity.

ITSM goodness tips

• Overcome Customer indifference by producing useful and honest reports that mean something to them
• Customers see ‘Incidents’ as accidents, ‘servers’ as waiters, and “architecture’ as buildings – talk to them in their language
• Let’s move our reporting from systems to services
• Understanding technology is good, but understanding people and culture is even more useful
• Metrics in isolation are dangerously misleading – its an eco-system that needs balance
• We need services/SLAs to give our metrics + KPIs relevance, otherwise, we get what suits us in IT
• KPIs without balance + business context simply drive compliant behaviour – maybe at a cost to the business
• Don’t think that anyone cares about blanket 99.9% ‘availability’ – 100% when it matters is what matters