Issues and advice to solve problems within enterprise IT

Does Anyone Read or Act on Your ITSM Reports?


I’ve not blogged for a while I know – I write now just getting into the conference season (en route to the itSMF Finland conference, also heading to SMFusion, itSMF UK and itSMF Estonia).

It’s been a busy ITSM-consulting time recently, with many organisations starting to renew their service improvement initiatives – good to see and also challenging, as there is a real demand for new ideas and thinking.

Apart from several projects looking to procure new ITSM tools, I’ve also been working on a couple of projects that are looking to really develop the quality of metrics and reporting.  As a background to this I also produced a short BrightTALK Webinar last month with targeted, solid advice and guidance for practitioners.

This webinar got some great feedback – if you don’t have time to listen through in full, the gist is simply this:

[important]Is your reporting delivering any value? Does anyone actually read or act upon the information produced? If not, then please stop and use the time you spend producing this stuff to produce something useful. [/important]

What would be useful? Well of course, if you can produce customer-based ‘service’ reporting, based around service bundles (see previous posts on this blog and webinars on my new custom BRC BrightTALK channel), that’s great. Of course you might not be able to do that – or do it right away. So it is useful to consider how you can improve your internal IT reporting, particularly if you develop the ‘bundles’ concept into different areas of IT.

The basic concept here is to consider how you can provide a rounded view of service quality and operational reporting – as appropriate for different audiences and groups. The Service Desk reporting ‘bundle’ will include telephony, incident and request handling, customer sat and other metrics, weighted into an appropriate ‘bundle’. Resolver groups and IT Management will have different metrics, perhaps looking at incidents caused by changes, relative numbers of outstanding incidents and problems etc. (I offer full details and explanations in the webinar).

This approach is always well received within IT and ITSM groups, particularly as it doesn’t require significant alterations to current reporting, plus it also avoids the need to tackle some of the bigger and tougher SLM challenges  (dealing with customers..!?!). So it’s not the ideal end goal but a good stepping stone to get there…

CIO CEO Reporting 2Let me know what you think…

Problem Management Success – Start Using Causal Closing Codes


Many organisations struggle to make
Problem Management work effectively.

For me there are a number of reasons for this – many to do with getting the right people to do the right job.

One key area which is vital to develop for this is reporting, particularly to start to really identify underlying causes and trends – e.g. for incidents. If you close your incidents off against the initial (logging) categories that you’ve used to identify the incident, you may miss the reason why the incident actually happened. So closing against ‘software’ may be useless to you if the cause was actually a user or 3rd party error.

So it’s important and useful to use separate ‘closing’ categories or ‘causes’ for logging categories or impact etc. – these are different things.

Here is a suggested list of closing or ’cause’ codes to help you to identify trends and make some sense and provide MI around root cause etc.

Known/Standard Error

  • existing issue, fault or request known, with workaround to maintain service

Process Failure 

  • no relevant process
  • process not adequate
  • governance – process not followed

Resource Issue

  • Skill/knowledge issue
  • Availability issue

External Issue

  • 3rd party system issue
  • environment issue

User Issue

  • user error
  • training issue
  • Policy issue

Hardware Failure

  • xxx as required

Security issue

  • password reset
  • access issue

Systems Issue

  • networks
  • infrastructure
  • operating systems failure
  • xxx as required

Software Issue

  • design issue
  • build issue
  • test issue
  • service introduction issue

Contract/Commercial Issue

  • technical information given
  • ‘how to ‘ question answered

Request or Order Fulfilled

Cause Unidentified

  • service resumed, cause unknown

(Optional to be used by limited SD people only) usually should be passed to problem management, but in some cases the cause is unknown. To be used with care and to avoid having ‘other’ as an option.

How effective is the reporting in your area of influence right now?

Are you already using causal closing codes?

Do they work for you and if so, which ones in particular?