Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: MCilley
New Today: 34
New Yesterday: 55
Overall: 148156

People Online:
Visitors: 63
Members: 0
Total: 63

Languages
Select Interface Language:


Major ITIL Portals
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

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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 - How to close a problem ticket that is used only to find RC
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

How to close a problem ticket that is used only to find RC

 
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message
prasadabr
Newbie
Newbie


Joined: Feb 25, 2008
Posts: 9

PostPosted: Wed Apr 30, 2008 1:15 am    Post subject: How to close a problem ticket that is used only to find RC Reply with quote

Hi,

How can a Problem ticket be closed if it was opened only to find the Root cause.Assume that the end result of the problem ticket is not any of the following -RFC Submitted/Completed/Denied.
For example- a CPU spikes drastically- and then a problem ticket is opened for the investigation.On analysis it was found that a sudden surge in the no of sessions creates this load.
In such a case how do i close the problem ticket.

ANother question
Can a problem ticket be closed if the error is known and accepted?.
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Wed Apr 30, 2008 3:43 am    Post subject: Reply with quote

Hi prasadabr,

What is your conclusion regarding the surge in sessions? Is it something that has to be catered for? Should you place limits? Should you increase capacity or have standby capacity? Should you schedule work patterns? Why did it happen? Will it become more frequent? Should you set up periodic reviews? Increased monitoring?

The answers to questions like these define the closure.

As for your second question: an error/bug/flaw/defect is not a problem if you decide it is not a problem. That means extrapolating the consequences, risks and impacts, and deciding they are not important. However, it is difficult to come to this decision if incidents are still being caused since incidents mean costs. It is also difficult to do if your customer(s) do not fully understand the situation and are not 110% in agreement.
_________________
"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
Back to top
View user's profile Send e-mail
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3318
Location: London, UK

PostPosted: Wed Apr 30, 2008 4:17 am    Post subject: Reply with quote

I am sorry. But I see this as wrong

..................It should be............................

The CPU spikes.

An Incident ticket gets open

The incidentg ticket gets completed or resolved

The incident is recommended to the PM team for an Problem ticket
because it meets the criteria for a problem

The pM team has tro either accept or decline to make it a problem
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
prasadabr
Newbie
Newbie


Joined: Feb 25, 2008
Posts: 9

PostPosted: Thu May 01, 2008 12:22 am    Post subject: Reply with quote

The CPU spikes.
An Incident ticket gets open
The incidentg ticket gets completed or resolved
The incident is recommended to the PM team for an Problem ticket
because it meets the criteria for a problem
The pM team has tro either accept or decline to make it a problem


Let us assume that PM team acknowledges this as a Probelm Ticket.
On Analysis- it was found that since it was quarter end- the load on the CPU spiked .
If this is the case- how should the problem ticket be closed.



Can an Problem ticket be closed without rectifying the Know Error.The aim of the PM is to resolve incidents from Reoccuring-i.e its goal is to resolve the know Error completley(i.e resolution with other than a workaround)
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu May 01, 2008 12:50 am    Post subject: Reply with quote

prasadabr,

you close the problem because you have determined that the incident was not harmful. You document that that spike at quarter end is normal behaviour of the system and you don't raise an incident when it happens again.

Your problem never had a known error. No error existed unless you want to say that your threshold for reporting spikes was too low. But this is all a bit of a sledgehammer. What was done to "resolve" the incident? presumably it was simply noted that the spike had gone away. Why would you go into problem analysis for a single spike that did not break a service? Why not let Capacity Management worry about it (sorry, analyse it)?

A pro-active Problem Management can pick it up if it recurs because that might suggest that there is an underlying problem.
_________________
"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
Back to top
View user's profile Send e-mail
prasadabr
Newbie
Newbie


Joined: Feb 25, 2008
Posts: 9

PostPosted: Thu May 01, 2008 2:00 am    Post subject: Reply with quote

If there is a request for an analysis/Investigation - what type of ticket should be raised.

Assume that this reuqest doesnt qualify for a problem ticket( the PM is aware that this request is just for some analysis and also are sure that this is a one-off issue)

An incident ticket ccannot be open for investigation since it is tied up with SLA.

It doesnt qualify for a service Request Ticket either.

How can the service desk keep track of the this request.



Someone answer this question
Can a problem ticket be closed without solving/rectifying the know error.
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu May 01, 2008 3:08 am    Post subject: Reply with quote

prasadabr wrote:

Someone answer this question
Can a problem ticket be closed without solving/rectifying the know error.


I thought I had answered that question earlier. In brief, yes so long as you have identified the consequences and there is no longer term need (or practicality) to do anything else.

prasadabr wrote:

If there is a request for an analysis/Investigation - what type of ticket should be raised.

Assume that this reuqest doesnt qualify for a problem ticket( the PM is aware that this request is just for some analysis and also are sure that this is a one-off issue)

An incident ticket ccannot be open for investigation since it is tied up with SLA.

It doesnt qualify for a service Request Ticket either.

How can the service desk keep track of the this request.
.


Request from whom? To whom?

I need to understand your management organization structure to answer this.

In some organizations it would just be the day job for the infrastructure management team that looks after servers or for the Capacity Management function; it would only reach the service desk if things got a bit serious.

In other organizations all such work goes through the service desk; this allows tracking using the same tools as for incidents etc.

In either case there will be procedures in place for commissioning, tracking and reporting.

I don't see how to answer your question (which ticket) without knowing what tickets you have and how you use them. ITIL is not designed to answer that kind of question because it is specific to your organization.
_________________
"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
Back to top
View user's profile Send e-mail
asrilrm
Senior Itiler


Joined: Oct 07, 2007
Posts: 441
Location: Jakarta, INA

PostPosted: Thu May 01, 2008 10:13 am    Post subject: Reply with quote

Hi prasadabr,

I quote the following definitions from ITIL Open Guide

"The objective of Problem Management is to minimize the impact of problems on the organisation. Problem Management plays an important role in the detection and providing solutions to problems (work arounds & known errors) and prevents their reoccurrence."

"A 'Problem' is the unknown cause of one or more incidents, often identified as a result of multiple similar incidents."

"A 'Known error' is an identified root cause of a Problem."

Further reading of the ITIL guidelines would say something like this:
"Update Problem Records (solved problems records if the known error is resolved)"

"A Known Error is a problem for which the root cause is understood and there is a temporary workaround or a permanent fix has been identified. Note that the implementation of the permanent fix may be some time in the future."

My conclusion from the above definition is that a fix of the known error doesn't have to be technical bug-fix or such, but it also could be recommendations.

To your last question:
Unsolved known error?
C'mon, you IT people are smart people.
For the case of CPU spike, I assume a client/server configuration.
There are many ways to resolve the spike issue like recommendation of restructuring the configuration, f.e, by enhancing the tier (e.g from 2 to 3 tiers), using virtualization, using distributed config, etc.

But referring Diarmid's post, which I fully agree, CPU spikes is normal along with the number of sessions accessing it. If it doesn't affect the service or the CPU usage is still below threshold, why bother in relation with service support? Let Capacity Management Process take care of it.

Regards,
Asril
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.