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: SBrunskil
New Today: 12
New Yesterday: 72
Overall: 139985

People Online:
Visitors: 52
Members: 2
Total: 54 .

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 - Classifying Problem Ticket/Incidents
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Classifying Problem Ticket/Incidents

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


Joined: Jan 15, 2010
Posts: 2

PostPosted: Sat Jan 16, 2010 5:48 am    Post subject: Classifying Problem Ticket/Incidents Reply with quote

We are trying to track whether our incidents and/or problem tickets are generated as a result of user's mistake or lack of knowledge, technical error from a hardware or software issue, or an issue caused by a system administrator's error (like a faulty deployment). Is anyone familiar with any processes for this within Problem or Incident Management or any ITIL processes?
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Mon Jan 18, 2010 8:34 pm    Post subject: Reply with quote

Wendy,

during the incident/problem resolution process you investigate or otherwise recognize the cause and you assign a category code to it according to the scheme you have outlined in your post. Then you pull off reports or otherwise count the occurrence of each category and use the information to inform your ongoing management and improvement plans.

There is no magic.
_________________
"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
RamaKrishna
Newbie
Newbie


Joined: Jan 17, 2010
Posts: 3
Location: India

PostPosted: Tue Jan 19, 2010 1:37 pm    Post subject: Reply with quote

Wendy,

In your statement "We are trying to track whether our incidents and/or problem tickets are generated as a result of ..", "as a result of .." itself meant that you will know the cause of the incident/problem only when you investigate. So, while logging the incident/problem, you cannot categorize, but while closing them, you can have a seperate option to provide a code/reason and then close. This may be helpful in future to generate reports based on the cause.1
Back to top
View user's profile
GCLOONY
Newbie
Newbie


Joined: Jan 19, 2010
Posts: 6

PostPosted: Wed Jan 20, 2010 11:28 pm    Post subject: Reply with quote

Wendy,

Do you want to track them or eliminate them?

IMO you analyse the incidents and categorise them according to the nature and then try to eliminate the problem. You can clube them by user errors/h/w failure etc and see what can be eliminated ASAP, getting the awareness among people shouldnt be hard if it is a small group.
Back to top
View user's profile
Wendy9777
Newbie
Newbie


Joined: Jan 15, 2010
Posts: 2

PostPosted: Wed Feb 17, 2010 5:46 am    Post subject: reporting Reply with quote

We basically want the capability to create an automated report to state how many incident and problems were the result of each of the following:
1) User Error
2) Systems Administrator Error
3) Software glitch

So we need to be able to assign each of incident or problem ticket to one of these categories. I think the resolution codes might be the best way to go, but I'm not sure how others implement this process. [/list]
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Wed Feb 17, 2010 7:50 am    Post subject: Reply with quote

Wendy,

it does not make much sense to categorize a problem as "user error" or "administrator error". I'll reserve judgement on "software glitch" because I'm not sure what that means.

If someone makes a mistake it can lead to an incident. If the mistake is being made frequently then there may well be an underlying problem. This problem could be:
- poor documentation
- poor training
- inappropriately skilled practitioner
- poor user interface
- high pressure working conditions
- inadequate lighting
- excessive noise levels
- excessive working hours
- etc. etc. etc.

But not human error.
_________________
"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
RAJITIL
Newbie
Newbie


Joined: May 04, 2010
Posts: 2

PostPosted: Tue May 04, 2010 5:41 pm    Post subject: INCIDENT MGMT OR REACTIVE PROBLEM MGMT Reply with quote

Quote:
The Automated tool reported an event ,The level 2 Team raised it as an incident in the ITSM tool , THe Incident owner analyzed the ticket found the resolution to fix it,The resolution required one CI to be changed ,The team rasied an RFC and then the change was impleemnted using proper change mgmt process and deployed using the proper release and deployment mgmt process .Later that incident was never reported (Permanenetly fixed ..never recurred).


Problem mgmt says :
Quote:
Finding the root cause (invetsigation to find the fix)of the incident and prevent recurring incidents


Bot the above conditions were done in the case explained above

AM I DOING INCIDENT MGMT OR REACTIVE PROBLEM MGMT ?

Please help to understand that once the event is reported it shud be raised as an incident or problem ,as might be the invetigation involved in incudent resolution may be the Root cause fixing itself .

Rolling Eyes
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Tue May 04, 2010 6:25 pm    Post subject: Reply with quote

sometimes incident resolution makes the thing go away for ever. But an event is not necessarily an incident.

To be thought of as an incident, the event has to have left something in an undesirable state that needs to be corrected (irrespective of underlying cause).

If this is not the case, but the event is indicative of some future threat to the service, then there is no incident to deal with and probably what is required is problem management.

The lines are blurry. for example, if the "undesirable state" is such that, without intervention, the system will crash in an hour, then you have an incident, but if it is such that the service may (but may not) crash in a month or two, then you have a problem. But there are all the in-betweens.

You need to establish policies for this, addressing risk issue and live with the consequences.

If you decide to go the incident route then you need a reliable way to determine that you have in fact sorted the underlying cause. For example, you can have Problem Management scrutinize the report and the work, or you can raise a problem anyway (just to make sure).

If you decide on the problem route, then you have to accept the lower imperative with the risk of an actual incident occurring before it even gets to the top of the pile.

One thing not to do is manage it as an incident and then record a resolved problem or vice versa.
_________________
"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
RAJITIL
Newbie
Newbie


Joined: May 04, 2010
Posts: 2

PostPosted: Tue May 04, 2010 9:33 pm    Post subject: Reply with quote

yupppy...Got It..that means even though while doing incident resolution for the Incident .. i might be a little more investigating the incident raised to find its cause and providing a workaround/permanent fix ..but this will not be called as PROBLEM mgmt and the event should not be raised as problem.

So to conclude the litmus test to report an event as problem or incident is is what i can now understand :

To be raised as an incident, the event has to have left something in an undesirable state that needs to be corrected (irrespective of underlying cause).

If this is not the case, but the event is indicative of some future threat to the service,but no present impact to services, then there is no incident to deal with and probably what is required is problem management.

Thanks a lot !I was looking for a justifiable answer since long Smile
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.