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.
Posted: Wed Mar 03, 2010 7:08 pm Post subject: Problem Management Reporting
Hi.
I am new to problem management and was thinking on starting some reporting. The objective of the reports would be to get open, closed problem tickets, ageing of tickets, the responsible party, number of corrective actions taken, problem cause and resolution.
Any help in template or guidance is appreciated.
Joined: Mar 04, 2008 Posts: 1893 Location: Helensburgh
Posted: Wed Mar 03, 2010 7:21 pm Post subject:
prad,
may I suggest you re-think your objectives?
The list you offer sounded more like the contents of the reports than the objectives.
You need objectives that relate to things like
- providing information to inform management strategies
- providing information that informs auditing
- providing information that informs continuous improvement initiatives
- providing information that informs decision making
Take things like this and make them specific to your organization. When you have done this you will find that the shape and content of the reports will be more obvious and it will be clear to you that other people's templates are, at best, irrelevant. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
In addition to Diarmids prompt response. Ask your self the following:
What are you reporting?, why are you reporting it? is there a benefit from it?
What will the reports be used for. Also put in mind that you can't manage or report what you dont monitor.
Regards,
Ali Makahleh _________________ Ali Makahleh
Configuration Management(Blue Badge),
ITILV2 Service Manager(Red Badge),
ITILV3 Expert(Lilac Badge) Certified.
“If you can't describe what you are doing as a process, you don't know what you're doing." W. Edwards Deming.
Thanks Guys.
When I started to do Problem Management, the org dint have a framework. We are at a point now where the framework and process is good. The next step I want to take is to get some reporting to analyze if there is any reoccurring issues and to improve on.
I am new at this and was hoping if you can share some best practice around this
Joined: Mar 04, 2008 Posts: 1893 Location: Helensburgh
Posted: Sun Mar 07, 2010 1:33 am Post subject:
prad wrote:
I am new at this and was hoping if you can share some best practice around this
We just did.
Our answers were more or less equivalent, but TCO's was more concise, while mine had more examples.
It is best practice to provide reports and analysis that will further your business objectives.
You seem to be saying that your objectives are to identify recurring issues and to provide information to a continuous improvement programme. Next you need to refine these objectives to describe what kind of recurrence you want to identify and what are your performance characteristics that are important enough to be worthy of consideration in an improvement programme (i.e. the characteristics that underpin your service delivery according to contract or SLA).
We can't do that refinement without knowing your system. And we cannot know your system without working for you. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Also added to it may be SLA reporting. I guess you need to know the SLAs first and the breaches u have in it. This could also give u a hint towards continuous improvement.
Joined: Mar 04, 2008 Posts: 1893 Location: Helensburgh
Posted: Thu May 13, 2010 9:03 pm Post subject:
just another thought:
prad wrote:
We are at a point now where the framework and process is good. The next step I want to take is to get some reporting to analyze if there is any reoccurring issues and to improve on.
Having appropriate reporting is part of what makes a process good. And is key to proving that it is good. Adding reports as an afterthought is not the best way and it could highlight a need to redesign your process. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
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
