For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
The Itil Community Forum: Forums
ITIL :: View topic - Useful and Effective Reporting
Posted: Mon Jun 05, 2006 10:20 pm Post subject: Useful and Effective Reporting
HELP!!??!?!?
Within the past 12 months, i have developed a set of 5 reports based on the common requirements from all the intended report users (i.e. Service management - on all levels - about 40 in all). The reports pull information out of our incident management system and are run on a monthly basis.
I find that there is little interest in the reports (they get used by approx 20% of the intended) and a push to review the suite has proved unsuccessful with very little buy-in.
This suite of reports has been produced as a generic-one-for-all suite - to be used by different IT support teams, Account Managers, and team management on all levels.
I am getting requests for other reports which are of a more bespoke nature and i simply do not have the resource to develop them.
Is it feasible to say that the generic suite of reports we have is too generic and do not suit all needs? How do others go about this? The other extreme is that every report requested is bespokely developed and this can lead to all sorts of problems - more resource required and inaccuracies are at the top of the list there.
If any one has any advice on managing reporting effectiveness then your advice would be much appreciated. _________________ Paul R Baxter
IT Support Analyst/DBA
University of Leeds, UK
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Thu Jun 08, 2006 1:25 pm Post subject:
Hello Paul,
Some questions about the 5 reports:
Specifically, what does each report contain?
Who is each report intended for? Which stakeholders?
Also, what are the new types of reports you're being requested to develop?
What ITIL constructs is your organization managing and capturing statistics around? (Problems? Incidents? Changes? Etc.) And, what systems do you use for each? Or, are you using things like your own custom forms/spreadsheets?
Regards, _________________ [Edited by Admin to remove link]
Thanks for your reply and apologies for the delay in response.
The 5 reports are as follows:
::an overall summary report - which is too top level to be of use to anyone, showing calls for all areas...
::2 customer reports showing information based on customer information (i.e. calls per department) - which are not viewable by our customers and hold no valuabable data anyway... used internally.
:: a report showing data on assignments per support team - frequently used but could be better...
::call information per support team - showing root cause classifications per call types. used quite often by small percentage of readers
I think the only 2 reports that are used are the root cause per team and the team assigments reports. The others hold no value in my opinion.
There are no reports that our customers can access.
I am thinking of redoing the assignments per team report and grouping the data by the 5 service managers - in a name and shame method. this would drive a little emotion and there is also peer management there too - at the top of the manageent structure. they will then drill down and see the same report for their sub managers and so on right down to engineer level. i see this as a very effective operational reporting method. this would force buy in at certain levels.
as for the other reports, well they were based on a concesus of what people thought they needed, which isnt actually what the business requires. But the question is - what does the business need???
Does that help at all? I hope it makes sense. sorry for the length.
Regards,
Paul. _________________ Paul R Baxter
IT Support Analyst/DBA
University of Leeds, UK
Joined: Mar 12, 2005 Posts: 255 Location: Melbourne, Australia
Posted: Fri Jun 16, 2006 9:40 am Post subject:
Hi Paul,
WRT -
Quote:
But the question is - what does the business need???
I can't answer the question specifically - obviously each business has different reporting needs. I can however offer a few pointers that I am confident from experience will help you answer the questions you are ruminating on.
First, reports are (obviously) related to a) the data you are collecting, and b) the measurements you are taking - a subset of 'a'.
There are only four reasons to measure anything in a business context:
1) To direct normal activity. (Control)
2) To intervene when events deviate from set parameters. (Control)
3) To justify a future course of action (Analysis)
4) To assess a past course of action (Analysis)
What you will always be reporting effectively is a 'history' of one or more of these measurements.
I always find it helpful to look at the information a process is gathering and ask how does it support one of these measurement/reporting objectives. If there isn't an answer, or the information confuses these objectives, then I either must remove or redesign somethign until that clarity is achieved.
Another point to bear in mind is that it is very important you keep separate the measurements and data collection activites that give you a history of a) The quality and effectiveness of the services you are delivering, and b) the quality and effectivenesss of the processes you are using to deliver those services. The two are quite distinct and the business won't be interested in the latter at all - nor should you offer it to them.
When approaching the business go back to the four objectives for measurement and try and ask what it is they want to control and analyse, and look at how your reports can support that. Remember that with regards to IT they might not really know what they want. But it isn't really too hard. For example when reporting on incident management remember that it can be summed up in the catch phrase 'we feel your pain' . So you should be reporting back to them a) The pain tech-problems are causing them - not the pain you are suffering, and b) How well your people are stepping in to ease that pain. So I would not like to see incident management reports going to the business that had breakdowns of break-fix component failure events (how many servers crashed, how many monitors failed, etc).
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
. So you should be reporting back to them a) The pain tech-problems are causing them - not the pain you are suffering, and b) How well your people are stepping in to ease that pain. So I would not like to see incident management reports going to the business that had breakdowns of break-fix component failure events (how many servers crashed, how many monitors failed, etc).
