Report on useful stuff

Stop producing piles of reports; report on services and on what’s important for the customer (not what IT does).

How do you do this? Read on:

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 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 don’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 to 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 in 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 customer and business-relevant SERVICES, not systems or it processes, and where possible it should relate to specific BUSINESS OUTCOMES.

We have to step out from behind the the PC and really demonstrate to our customer that we understand what they do and need from us, and then ‘walk the walk’ on this this by presenting them 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.

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 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 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 its not as if the existing reporting that you have bee producing is now irrelevant or useless – its just that its 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

Use the service structure and business input to drive reporting
Think about a single page RAG view and work backwards
Give teams and individuals the right information for them – in appropriate format and media for them
Establish a variety of regular reporting views and outputs Keep checking and reviewing for relevance and currency
Regularly refresh the reports and check for relevance and actual use
Its 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.

Supporting Documents

ITSMGoodness 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
Lets move our reporting from systems to servies
Understanding technology is good, but understanding people and culture is even more useful
Metrics in isolation are dangerously misleading – its an eco-system which 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 cost to the business
Don’t think that anyone cares about blanket 99.9% ‘availability’ – 100% when it matters is what matters

More Information

<< view previous step | view next step >>