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: VDzqAUelki
New Today: 76
New Yesterday: 73
Overall: 150126

People Online:
Visitors: 55
Members: 0
Total: 55

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 - Questions about problem management
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Questions about problem management

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


Joined: Jul 02, 2007
Posts: 3

PostPosted: Tue Oct 09, 2007 1:15 pm    Post subject: Questions about problem management Reply with quote

I am newbie for ITIL. need some valuable advice from you guys. thanks in advanced.

I am working on problem management process. ITIL only tell what to do in problem management, but never say how to do it. for example:

1.how to identify the standard of severity and priority? I know it is business related. but I need a model or method to define them.

2. do we always perform root cause analyst for every problem? what does "root" means? for example, a network connection down because of network card is broken. This is "root" or we need to dig deeper to find out why the card is broken....how many "why" we should ask...

3. how to define the resolved target day of the problem? 2weeks?3weeks? or half year? since in reality, it is difficult to tell how long should you take to find out "reason" for a problem.

4. what is the criteria for problem close?if we spend monthes and can't find the reason, or we know the reason, but there is no way to fix it, or we do have the solution, but cost of implementation it too high, can we close the problem?
Back to top
View user's profile
TomS
Newbie
Newbie


Joined: Oct 08, 2007
Posts: 4

PostPosted: Wed Oct 10, 2007 5:11 am    Post subject: Reply with quote

1. Problems often have a much longer time-scale than incidents, as there it usually isn't know how long it will take to fix; there's usually quite a lot of investigation and sometimes trial fixes (preferably not on a live system!)

You need to identify levels of service you provide that can be grouped into severity. There must be some services/functions, if unavailable, would have a critical effect on the business - a bank unable to process BACS transfers, for example. Work out your "essential", "must have" and "nice to have" services and work from there.

2. Root cause should be as accurate as possible. You should also try and get as close to the exact reason for the problem, because you could end up with either:
- Root is a defective network card
- Root is the fact the server is at ground level and sucks in dust through the vents, coating the card making it overheat.
One appears to be a root cause and the other is the real root cause, in this example.

3. How critical is the service? Can the business function while you test solutions, or have you got to just slap in a replacement and get the failed item on the bench for testing?

4. If you can't fix a server that reboots itself, then take the problem to the supplier. If the kit is out of warranty then you heed to consider replacement of an identical part or new equivalent. If management bitch at the cost, then you need a serious buttock-covering letter stating that senior management are happy to run without or run 'at risk'. Make sure management know (in writing!) what services/functions will be unavailable, and make sure your service desk know what's going on - if it impacts the users, they'll be the first to cop the flak!
Back to top
View user's profile
ehon
Newbie
Newbie


Joined: Jul 02, 2007
Posts: 3

PostPosted: Wed Oct 10, 2007 12:16 pm    Post subject: Reply with quote

thank you very much toms. It is great help. I understand what you say. It would be nicer if you can give me some examples. I can use them as reference to setup my own.
Back to top
View user's profile
dam
Senior Itiler


Joined: Sep 05, 2007
Posts: 57

PostPosted: Thu Oct 11, 2007 12:45 am    Post subject: Reply with quote

Hi,
I just don’t agree on point 2 :

2. Root cause should be as accurate as possible

If you set up an accurate problem management process is to improve the general customer satisfaction from an outer point of view, but with an inner view you mainly want to improve the ratio (resources used)/ (result obtained)

Remaining on the example you proposed (network connection down) for me the root cause is the broken network card. Going further in problem investigation is a waste of resource.

If -and only if- you start to get several broken network cards, and so you start to look at the broken card as an incident, it make sense to go further on with the investigation and so look at the root cause of the broken network card.

regards,
DAM
Back to top
View user's profile
pac666
Itiler


Joined: Sep 15, 2006
Posts: 22

PostPosted: Fri Oct 12, 2007 10:27 pm    Post subject: Reply with quote

DAM , I disagree ...

Problem Management is about permanently fixing something (economically) and avoiding future occurance. If you don't know the 'real' route cause your not getting the real benefit from problem management.

Intelligent Problem Management should be asking the question Why? In this example the why is the positioning of the server, and this should result in an RFC for rectifying the route cause.
Back to top
View user's profile Send e-mail
dam
Senior Itiler


Joined: Sep 05, 2007
Posts: 57

PostPosted: Fri Oct 12, 2007 11:21 pm    Post subject: Reply with quote

Hi pac ,
This is one of these questions where there is no true/false answer; the better choice is more a trade-off depending on the context.

Problem management is of course a more “intelligent” practise than incident management but still far from academic research, where the aim is to give a detailed answer to the starting question, and so getting to the root cause most close to the root.

If you are talking about ITIL problem management you talk about a business reality, where the cursor between the search for the truth (or more concretely the most satisfactory answer) and the evidence that an answer could be considered as acceptable is always driven by an economic logic.

So back to this example if the interruption of the network connection happened just on one machine and the network card costs 4 dollars, replacing the network card for me is the solution to the problem. I won’t put an engineer spending two days on the issue to discover why the card broke down.

If the network card costs 3000 dollars maybe I’d hesitate in considering replacing it a solution to the problem.

On the other side if the card gets broken again in the next future as I told you in my previous post this become en incident and of course replacing the network card a workaround asking for a deeper investigation of the root cause.
Back to top
View user's profile
andy1971
Newbie
Newbie


Joined: Sep 24, 2007
Posts: 12

PostPosted: Mon Oct 15, 2007 10:15 pm    Post subject: Reply with quote

Just to add my views to the debate above. I agree you need to consider the cost of the fix to the problem / incident, but I think the critical factor which has been ignored is the cost to the business of the failure. A network card may cost $4 to replace, but the failure of a network card could cost the business $000's, or expose you to unnacceptable risk.
Back to top
View user's profile
Jules
Newbie
Newbie


Joined: Dec 22, 2005
Posts: 10
Location: South Yorkshire, UK

PostPosted: Sat Nov 24, 2007 12:49 am    Post subject: Reply with quote

Forgive me for sharing my thoughts....

Problem Management is about Problem Control and Error control.

If we know it's the network card at fault, then its a (Known) error, not a "Problem".
Error control requires that we assess the error, considering factors such as cost and risk and may choose to either apply the resolution or leave it as-is.

Is replacing the Network card a workaround our a permanent resolution? I guess it depends on your root cause analysis
Back to top
View user's profile
ehon
Newbie
Newbie


Joined: Jul 02, 2007
Posts: 3

PostPosted: Wed Feb 27, 2008 12:36 pm    Post subject: Reply with quote

I agree with andy. The decision to do deeper investigation or not should be based on the impact of the business. But in reality, especially in network problem, since the impact sometimes is difficult to tell, people tend to raise it to higher priority. How to convince customer that the problem is fixed can be headache...
Back to top
View user's profile
m_croon
Senior Itiler


Joined: Aug 11, 2006
Posts: 262
Location: Netherlands

PostPosted: Wed Feb 27, 2008 4:25 pm    Post subject: Re: Questions about problem management Reply with quote

ehon wrote:
ITIL only tell what to do in problem management, but never say how to do it.

If you are interested in a method of 'how' to analyse problems, have a look at ATS (Analytical Trouble Shooting) from Kepner & Tregoe. It is a nice addition to ITIL's problem mgt.
Back to top
View user's profile Visit poster's website
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Thu Feb 28, 2008 6:43 am    Post subject: Reply with quote

I have also heard the 5 questions rule of thumb for determining Root Cause:

What happened? The network went down
Why? A server's network card failed
Why? The card overheated
Why? There was dust coating the card
Why? The floors in the server room are never vacuumed
Why? There is a policy against letting cleaning crews into the data center due to the sensitive nature of the equipment

So what is the root cause of the failure? A policy that is preventing the floors from being cleaned.

Again, it's just a simple rule of thumb that can be taken less far or even further.

Don
Back to top
View user's profile
Skinnera
Senior Itiler


Joined: May 07, 2005
Posts: 121
Location: UK

PostPosted: Thu Feb 28, 2008 11:04 pm    Post subject: Reply with quote

dboylan wrote:
I have also heard the 5 questions rule of thumb for determining Root Cause:
Why?
Why?
Why?
Why?
Why?
Sounds like the same rule of thumb my 2.5 year old has for anything...
Of course the ultimate answer then is either "Because I said so" or "Because it just does!" Wink
Back to top
View user's profile Send e-mail
shaster
Newbie
Newbie


Joined: Dec 18, 2006
Posts: 2

PostPosted: Thu Jun 05, 2008 10:57 pm    Post subject: Reply with quote

I've used the "5 Why's" tool successfully for a couple of years now, and find that by first defining a set of possible reasons for a failure, grouping those failures together into similar kinds then performing the 5 why's on each group usually gives you from one to a few different root causes.
I guess in a perfect world we would all like to see one root cause, which has been identified as the real root cause of the problem. In the real world, however, this may not be the case. It could very well be a combination of several things that highlights the problem. By eliminating each one in turn, however, then reviewing the Root Cause Analysis, you usually find that some of the other possible root causes then disappear.
It's not a perfect science, but it does work in the end !!
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.