Serio IT Service Desk & Helpdesk Blog

Customer Billy asks for help in producing his first management report. He’s read our IT metrics white paper and other KPI posts, but writes ‘my problem is one of interpreting the data. I’ve got a lot of data and interpreting it all is doing my head in. My predecessor never did any reports‘.

First of all, be clear about why you are writing the report, and who the report is for. Is it for your own benefit to help you manage the IT service more effectively, or is it to show someone else how well or otherwise IT service is managed & delivered? Be absolutely crystal clear in your own mind about this. Having asked Billy about this, the audience is primarily himself and his team.

Right now, their team has a functioning Incident Management and Asset Management process, so this is what Billy should look at first. The next six months will see them define a Problem Management process, and begin work on their Service Catalog.  Both of these will increase the options for reporting.

One of the things that the white paper does is group different types of performance data together. Some of the data is really easy to understand: Input data and Output data. Input data is primarily the raising of Incidents, and Output data is the resolution of those Incidents.

If you are reporting monthly, why not look at 3 things:

Incidents logged month-on-month over the past 3 months
Incidents resolved month-on-month over the past 3 months
Backlog at the end of each month

First of all, you can get all three values from report ES1 – it’s an Executive Summary report you’ll find in SerioReports – just put in your data range and run it (there is a lot more data there as well, which I’ll ignore for now).

Billy’s question was about interpretation. So, where’s some things you can ask yourself:

Is the number of Incidents logged rising or falling, when looked at month on month? If it’s falling then great, if it’s rising then try to examine why that is.

Remember some fluctuation is to be expected (’statistical significance’) but a significant jump of (say) 15% or more is something to look at more closely..by running more reports. For example, run reports by Problem Area or Department – is one particular technology or use group responsible for the increase? If so, why? (at this point, examination of individual Incident records can often be quite revealing).

When looking at the number of resolutions, is it broadly in keeping with the number of Incidents being logged, or is there a backlog developing? If there is, why do you think this is so?

Asking these questions will help you identify problems, but will also (hopefully) lead you to solutions. As an example from my own career, an increasing backlog (and worsening timeliness of resolution) at a company I once worked at was due to increasing amounts of staff sick leave. I already knew we had problems in this regard, but it was revealing nonetheless to see the results on service delivery (the IT service chart and the sick leave chart correlated).

My own reporting schedules have typically been: run some standard reports (report I always run each month) and then, from time to time, run others to ‘dig a little deeper’.

In addition, you can look at timeliness of resolution from a Service Level Agreement perspective (you’ll also find this on ES1, amongst many others).

Bottom line: obtain data that reflects your own IT service management disciplines, and apply some though about what this means for your IT service group.

• Supplier Management – Data Available (if you want it)
• Customer Satisfaction Surveys – Interpreting the results
• Making a Start with ITSM Reporting

First of all, thanks to Kirstie for filling in on this blog whilst I was away on extended sick leave. Thank you for an informative set of articles on ITIL V3 Kirstie!

My own thoughts are mixed on V3 – some of which was covered in this post on ITIL Qualifications.

Whilst not welcoming everything that has happened with V3, one thing I do welcome is a clearer focus on end-user experience, especially for monitoring. One thing I do see those involved in monitoring focus on is component-based monitoring (such as routers, individual servers) rather than the actual services that they provide to customers.

Now, I’m not saying it’s a good thing to monitor individual devices, but the focus, as much as possible, should be on the end user service and experience. If you are producing Availability or Downtime statistics (for examples of which, see our white paper on Availability) then the most important graphs should not be component related, but end-user related. Specifically, I mean that systems that are important to your customers should be the focus – so rather than have Availability graphs that show

Router: Trillian 99%
Server: Zephod 98%

I prefer to see

Payroll System 95%
Sales Order Processing System 99%

(Note: I prefer the second example over the first because the first does not accurately tell me what the end user experience has been. For example, it’s not clear if Trillian and Zephod were down at the same time, or different times – so how much downtime did our users experience?)

Which means, in many cases, your Availability statistics are going to be more accurately mined from your Incident data (because you log all your downtime, right?).

Although Command Center users sometimes view that tool as a component-level monitoring application, they usually ignore one of it’s most powerful features – it’s ability to log-on to websites, interact with them (examining the responses) and logging off again. So, if you deliver web-based services to users, it can act as a thoroughly tireless user, logging on every few minutes, performing the tasks you set it, and then logging-off again – recording the results of this as it does so.

It doesn’t deal with AJAX (if you don’t know what AJAX is or think it refers to the son of Telamon, a mythological Greek hero, google for ‘AJAX Programming’). However, for most websites it works perfectly well.

Adopting this kind of approach to monitoring goes past components, and straight towards the end-user experience.

If you want to find out more, look-up the HTTP functions in the SerioScript reference, which you’ll find on the Command Center help menu. The functions are targeted at those who have some familiarity with how web applications work. A worked example is also distributed with the tool.

• More on our Command Center changes
• Updating Command Center Web Pages with Device Values