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: KDehaven
New Today: 10
New Yesterday: 48
Overall: 146038

People Online:
Visitors: 64
Members: 4
Total: 68 .

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

Target Problem/Incident percentage

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


Joined: Apr 27, 2006
Posts: 8

PostPosted: Fri Jun 09, 2006 1:20 am    Post subject: Target Problem/Incident percentage Reply with quote

Hello everyone,

Is there such thing as a best-practice target/guideline for the percentage of Incidents that should be related to a Problem, on a month-by-month basis.

Our percentage is lower that I think it should be. I believe we can attribute this to needed improvements in Incident classification and overall quality assurance.

Can anyone share their percentages so I can get an idea. I would guess these percentages would depend on maturity levels of the institutionalized processes and maybe even industry and complexity of the organization's IT infrastructure.

Thanks!
Back to top
View user's profile
Itilitarian
Newbie
Newbie


Joined: Apr 27, 2006
Posts: 8

PostPosted: Sat Jun 10, 2006 5:08 am    Post subject: Reply with quote

On this topic, I think there are a number of factors that affect this percentage in a negative way.

I was speaking to a colleague who's recently come back from the ITIL Practioner Support and Restore training. She shared an interesting story about the instructor's method of getting his point across about the relationship between Incidents and Problems. The instructor asked the audience if everyone agreed that Incidents gave rise to Problems... everyone looked around at the rest of people in the group and eventually everyone nodded in agreement. He then got their attention by stating that's not the case. "Incidents don't give rise to Problems" he said, "................. Incidents are Problems!" The point he was making was that support staff tend ask themselves if a Problem is necessary for each Incident that comes in, when in contrary, the oposite should happen.... Assume it's related to a problem (new or existing) unless you can prove otherwise.

From my experience this is paradigm shift that companies need to make if they're going to become successful at Problem Management. Too often, I've seen support/SD staff say "but we know why why the incident happened....". Ah yes, but what can be done to prevent it from happening again?!? Or they'll say "But there's nothing we can do about it" Ah yes, but what if we uncover exactly how many times the company is impacted by this issue, and we discover it costs less to fix it than deal with it?!?

Another conflicting factor is that some organizations are structured so that the same group who perform incident management are also responsible for conducting problem investigation. In a hectic IT environment, it's easy to see how this conflict of interest can impede the progress of Problem Management, afterall service restoration should always come first!!

Also, as my original note mentioned, Incident classification is critical in making Problem Management a success. If the support organization is not reviewing a Problem/KE database before starting the troubleshooting, they're potentially missing out on key support knowledge that already exists that may very well help them in restoring service for their incident.

These factors among many others will affect how companies recognize Problems and leverage the Problem Management process to its fullest.

I've love to hear from people who have similar/differing views.
Back to top
View user's profile
ProbMan
Newbie
Newbie


Joined: Jul 09, 2004
Posts: 8

PostPosted: Fri Jul 14, 2006 1:13 am    Post subject: Reply with quote

One factor which has always puzzled me that can skew your stats is the habit of service desks of putting messages on the phones when they have a high level incident to prevent users from calling in. If you don't log all calls how do you know how big the impact is on your userbase.
Back to top
View user's profile
eisbergsk
Senior Itiler


Joined: Nov 01, 2004
Posts: 81
Location: Sask, Canada

PostPosted: Sat Jul 22, 2006 2:53 am    Post subject: Reply with quote

ProbMan wrote:
One factor which has always puzzled me ... is the habit of service desks of putting messages on the phones when they have a high level incident to prevent users from calling in. If you don't log all calls how do you know how big the impact is on your userbase.


For Problem Mgmt, focus on the Incident Classification, rather than the call volume. When an incident is 'Severity 1' (high severity), the volume doesn't really matter. Putting a message on the phone actually provides better service to the customer, so it shouldn't matter how many calls there actually were. Our system lets us put a message in front of the IVR menu, so that clients don't have to waste time navigating thru the IVR just to find out that there is a problem. This frees up our IVR system for other issues that may be occuring at the same time, too (the "never rains but it pours" syndrome). This process has proved to be valuable for Incident Mgmt for our organization more than once.

Our focus for Problem Mgmt is 'severity 1 incidents' (the high ones) and our percentage of Sev1's that have problems identified is... 100%. Itilitarian's "Ah yes, but"-type questions help achieve that. Metrics I use include: how many of these problems are actionable (current target is 95%), how many problems have no further Severity 1 incidents after they were first identified (target is 99%), and how many problems (that are not resolved immediately) are resolved within a reasonable timeframe (current timeframe is 1Q, and target is 95%).

Does that make sense?
Back to top
View user's profile Send e-mail
szwden
Newbie
Newbie


Joined: Jun 13, 2006
Posts: 1
Location: The netherlands

PostPosted: Mon Jul 24, 2006 6:22 pm    Post subject: Reply with quote

hi,

i think that problems are defined, where as incidents occur.

because problems are defined, there highly dependent on the categorisation of the incident. on estimating the impact and the problem area.

we have one incident severity of wich always a problem is defined, that severity is "calamity". If a calamity incident occurs incident management works his butt off to resolve hat inciden. afterwards problem management investigates the incident and takes action to stop it from happening again. for us it's the first step to pro-active problem-management.
Back to top
View user's profile Visit poster's website
Globis
Itiler


Joined: Apr 17, 2007
Posts: 36
Location: Cape Town

PostPosted: Thu May 03, 2007 9:18 am    Post subject: Reply with quote

Quote:
Is there such thing as a best-practice target/guideline for the percentage of Incidents that should be related to a Problem, on a month-by-month basis.

No, because that's not how it works. One incident can raise one problem or 1000 similiar incidents can raise one problem, and lots of incidents may not raise any problems at all.

As Sharon points out, it's not so much the numbers of incidents as the severity of an incident that drives the problem management process. The last corporate I did some work for had the rule that any severity 1 incident (severe impact to the business) always required a root cause analysis, i.e. 1 severity 1 = 1 problem record.

Quote:
The point he was making was that support staff tend ask themselves if a Problem is necessary for each Incident that comes in, when in contrary, the oposite should happen.... Assume it's related to a problem (new or existing) unless you can prove otherwise.

Er, I don't know if this instructor has ever worked on a Service Desk (I doubt it somehow) but helpdesk process step 1 for managing incidents is usually 'do we know about this incident already?' In other words 'is this a known error, does a problem record exist for this incident?' In fact my experience is that you have to work bloody hard to convince a helpdesk that this is not a known error, but something unusual and new (and hence more work for them).

I'm not sure about any paradigm shifts happening here although I do agree with everything else Itilitarian says (except for the gratuitous use of the word leverage - this is not a management consulting forum, what were you thinking? ;-) Support desks have followed these processes for years, ITIL has just formalised the framework for it.

Dave
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.