Peeling Back the Reporting Onion

There is a question that gets asked over and over again. “With so much information available, what should I report on?” More often than not we find ourselves reporting on more than we really need to in the absence of knowing what is really required. But the real answer is that we need to report on what makes our business outcomes a reality.

 

This is why I refer to reporting in terms of an onion. Sometimes peeling it back will make you cry, well maybe only figuratively, but sometimes it might feel this way.

 

For a moment let’s call the outer layer of the onion the customer experience. This is the service(s) that the business consumes each day. Overall we need to report on our ability to provide an exceptional customer experience.  This might be where some of the crying starts, but this is only because we tend to over complicate things.

 

Start small

What does the business see in terms of the service that is provided, the key question – is it available? If not, how often are outages occurring and for how long? You are starting to see how the scope starts to increase which is why the reporting gets out of control. One of the most important questions you should ask is whether the service enables the business to achieve its outcomes. Your business has a purpose, whatever it might be, and we need to make sure from an IT perspective that we are enabling them to achieve whatever that goal is.

In the onion analogy there are several layers, so too is the level of reporting available. Assuming that we want to report on service availability we need to know what is making that happen, or when it isn’t what the cause for the downtime is.

Start small… yes again

First IT needs to know what makes your services work in the first place. What are the ‘things’ that make up your service? Some of you might be thinking to yourselves we have a “CMDB”. While others may have a less formalized configuration management in place with an understanding that there are several components supported by several teams. Whether you have a formalized system or a spreadsheet or even if it is on cocktail napkins, gather together what you know about the service and start to report on what makes it function. Understand the service

This is where we need to ensure that we have some alignment on the goals to enable your business outcomes. Remember, this is not a finger pointing exercise. In one report we may identify application issues and in the next reporting cycle there may be a network outage. Working together we can ensure that we are putting our best foot forward to provide great service by correcting issues accordingly.

Initially we should be able to identify any gaps which are holding us back. Some of these may present themselves as issues while others may be issues with our ability to report. Either way this information will allow us to make improvements each time we collect data and report our findings.

Overall we may see from our IT layers of reporting that the service is operating consistently but if our customers indicate otherwise we need to investigate where reporting may be inconsistent. For example, we report to our business that the service was up 100% last month; they may challenge that indicating that there were 2 relatively small but impactful outages that may have not been escalated. While there is an expected feeling of embarrassment that we missed something, put that aside and welcome this information.

Identifying this inaccuracy allows us to look for a hidden gap in our reporting. Whether it is a challenge in our escalation process, training or if our IT monitoring or reporting is incorrect we can still learn from this and make some improvements which will move us closer to achieving our goals of providing a great customer experience.

 

 

 

 

 

1 thought on “Peeling Back the Reporting Onion”

  1. My reporting philosophy:

    1. Keep reports as few as possible
    2. Make reports as graphical and understandable as possible
    3. Wherever possible: Show financial impact or benefit
    4. Use a drill-down schematic for more detailed analysis of root-causes – all is connected somewhere!

    That`s it – KISS!

Comments are closed.