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 embarassment 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.
Labels: ITIL, ITSM, Service Management, Service Management Reporting