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: WMLUI
New Today: 32
New Yesterday: 68
Overall: 139790

People Online:
Visitors: 65
Members: 1
Total: 66 .

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 - Why seperate Incident Management and Problem Management
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Why seperate Incident Management and Problem Management

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


Joined: Sep 14, 2004
Posts: 14
Location: Australia

PostPosted: Tue Sep 28, 2004 8:49 pm    Post subject: Why seperate Incident Management and Problem Management Reply with quote

Can anyone provide me with real/realistic reasons for seperating Incident Mgt and Problem Mgt. My client is not interested in what "best practice" / ITIL says , but rather on real pragmatic reasons or examples of where benefits of doing this could be realised.

Why can't one investigate a root-cause in Indicent Mgt?
Back to top
View user's profile
Jonsing
Newbie
Newbie


Joined: Sep 28, 2004
Posts: 2

PostPosted: Tue Sep 28, 2004 9:19 pm    Post subject: Re: Why seperate Incident Management and Problem Management Reply with quote

leebc wrote:
Can anyone provide me with real/realistic reasons for seperating Incident Mgt and Problem Mgt. My client is not interested in what "best practice" / ITIL says , but rather on real pragmatic reasons or examples of where benefits of doing this could be realised.

Why can't one investigate a root-cause in Indicent Mgt?


In my opinion it is important to differentiate between Incident Management and Problem management due to the different focus areas...incident management needs to be solely concerned with returning the service to an operational state, and should not be over-complicated with root cause anaylsis which would only slow the process down. Problem management process would also benefit as this would free resource for more pro-active work to comabat future incidents.
Back to top
View user's profile
Guest






PostPosted: Tue Sep 28, 2004 10:02 pm    Post subject: Reply with quote

Couldnt agree more.

Some people are good at getting people back up and running and should not suffer any distractions . OtherS - Problem Management will analyse
the bigger picture - catagorise incidents and make reccomendation for changes that will prevent re-ocurrance. Cost justifications need to be raised, impact assessed, etc,etc
Back to top
jpomales
Itiler


Joined: May 13, 2004
Posts: 31

PostPosted: Thu Sep 30, 2004 7:49 am    Post subject: 'Real life' example and reason for difference. Reply with quote

OK. Let's see how you digest this:

Let's say the Service Desk gets a call from a user. She's the secretary of the VP of Finance and she needs some documents printed on her printer STAT for the VP's 5:00 meeting. (Why do we always pick on secretaries? Razz). It's 4:15 and the Service Desk tech goes at it over the phone, connecting remotely to the secretary's workstation. He pokes here, prods there and can't make the computer print. However, the tech knows there's a printer down the hall from where the secretary sits that could probably work. He proceeds then to configure the workstation to print to that printer down the hall. He makes the connection and it works!. The secretary prints her document in the nick of time and gets them to her boss just in time for his meeting. Of course, the SD documents this information and in his Service Desk tool he inputs that, as a workaround, he configured the printer down the hall.

Now, the Incident (the secretary can't print) is solved, but the problem is not. He proceeds to create a Problem and pass it to a level 2 tech, who has more time on his hands to do deep troubleshooting. It's a bit more detailed than this and I won't go into the details of escalation and all the other stuff. But this is roughly what it is!!
_________________
audentes fortuna juvat
Back to top
View user's profile MSN Messenger
nuker
Newbie
Newbie


Joined: Sep 20, 2004
Posts: 9
Location: switzerland

PostPosted: Fri Oct 01, 2004 10:51 pm    Post subject: Reply with quote

good example. Is exactly also my opinion.

...but often in smaller companyes you will not find a explicit problem process because the same people (men) solves every incident/problem. but they do it as well.
_________________
gruss nuker

Back to top
View user's profile Visit poster's website
leebc
Newbie
Newbie


Joined: Sep 14, 2004
Posts: 14
Location: Australia

PostPosted: Fri Oct 01, 2004 11:08 pm    Post subject: Reply with quote

Thanks for your responses. They confirm what I am saying (professing).

I think the real "problem" I am facing is to get the client to understand the difference between an incident and a problem. In his eyes if the SD cannot resolve an "incident' then it is a problem.
It goes against the grain of what ITIL/best practice says. I will have to introduce terms like, minor, major and significant incidents in order to get around the terminology issue.

One terminology issue: if their primary server (running their core mission critical application) goes down (which happens from time to time) although they have a work around to bring the service back up, they see this as a problem and believe it should fall within PM.
Back to top
View user's profile
Jonsing
Newbie
Newbie


Joined: Sep 28, 2004
Posts: 2

PostPosted: Tue Oct 05, 2004 11:02 pm    Post subject: Reply with quote

Explain to them that the incident is the loss of the service, hence when the server is back (rebooted etc...) the incident is closed. The problem is what caused the server to go down in the first place, and needs to be addressed to stop future recurrences
Back to top
View user's profile
janelink
Guest





PostPosted: Thu Oct 07, 2004 10:07 pm    Post subject: .... Reply with quote

.. in a nutshell; incident management is reactive and problem management is proactive. The two together add value to the service provision by creating a culture of continuous improvement.

regards, Jane
Senior Business Consultant
Alliedworldwide Ltd.
Back to top
faznjaz
Guest





PostPosted: Mon Oct 11, 2004 1:10 am    Post subject: problem vs. incident Reply with quote

I agree to a degree. Incident management is definitely reactive as the SD the function of IM is responding to reported incidents but it is an oversimplification of problem management. Problem management has both reactive and proactive. A mature problem management process is doing both. Reactive problem management is responding to the problems as they arise. Proactive problem management utilizes trend analysis to identify problems in advance. For example the problem manager may get reports on incidents from the SD and notice a recurring issue and then raise a problem record.

I think the fundamental difference is that Incident Management's goal is to restore service as soon as possible either through a temporary fix or a workaround, or if one is lucky actually resolving the problem. Problem Management in contrast has the goal of finding the root cause.

A business justification for implementing the separate processes is the service level to the customer. If the 'resolving' team is concerned with finding the root cause it might take a long time to identify and eliminate, meanwhile the customer is out of service the entire time -- customer unhappy. Incident Management would ensure that the service is restored within the agreed time frame (SLA if the organization has SLAs). Without Problem Management the underlying cause is not identified increasing the chance of the incident happening again leaving an unhappy customer since the same issue is recurring -- degraded service level.

Having the two processes separate is ideal. In a way they balance each other out and promote the highest achievable service level to the customer. ITIL doesn't prescribe how to create the org structure, it merely states the processes that should be occurring. So depending on the size of the org and the volume of incidents and problems if the client is against investing the additional resources to have two separate teams it might be a possibility to have the one team fullfilling both processes. Not knowing the details it is difficult to say.
Back to top
ProbMan
Newbie
Newbie


Joined: Jul 09, 2004
Posts: 8

PostPosted: Thu Oct 28, 2004 11:46 pm    Post subject: Reply with quote

One other benefit of Problem Management that is often quoted is that in theory, as root cause of problems is resolved call volumes should decrease.
Back to top
View user's profile
Guest






PostPosted: Sat Nov 05, 2005 6:00 am    Post subject: Re: problem vs. incident Reply with quote

faznjaz wrote:
I think the fundamental difference is that Incident Management's goal is to restore service as soon as possible either through a temporary fix or a workaround, or if one is lucky actually resolving the problem.


Does the work order remain classified as an incident or a problem if the "problem" is resolved?
Back to top
AS
Guest





PostPosted: Sat Nov 05, 2005 7:32 am    Post subject: Reply with quote

In the printer example, the Incident Record would have been closed once the incident was resolved...the workaround to another printer. The Problem Record goes through investigation and into known error status (we hope). At this point a RFC might be opened if a change is needed to fix the secretaries printer. The bottom line is that the Problem Record is not closed until the customer indicates that the resolution took care of the problem. I'm not 100% sure how your company uses work orders or how they handle the classification of them, so I am making an assumption that they are used to dispatch techs. I am also assuming that the work order would not be generated until after the initial incident and it was known that further investigation was needed and a tech needed to be dispatched (remotely or onsite). Given the assumptions made, it would be my opinion that it would be classified as a "problem" and would remain so after closing. The reason being is for trending and reporting...but you have to do what works for your organization.

To get to one of the earlier points about justifying the reasons for separation of Incident and Problem, from a ITFM perspective it is beneficial to know the cost of doing business. This means understanding the difference between solving incidents and problems. Understanding when it is cost effective to remove a problem and when it makes sense to live with the work around. I won't go on about the advantages of keeping them separate from a process perspective, there are many comments earlier in the thread that nail this pretty good.
Back to top
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Sun Nov 06, 2005 10:28 pm    Post subject: Reply with quote

The separation of incidents and problems, and the processes that deal with them has been pretty well articualted in the previous posts, and I pretty much agree with what has been said.

Some comments on the realistic operation of incident and problem managent and how they work together....

Incident resolvers will frequently discover the root cause of an incident. The most obvious cases will be simple break/fix incidents where a phsyical component has gone belly up and needs replacing. At other times more complex root-causes may be found while the Incident resolvers are getting the service back up.

In short not every single incident has a workaround. The goal of Incident Management is to get the service restored. Sometimes the move into Problem Management is necessary to get this done.

In these cases the aspects of Incident and Problem managent come together: The goal is to get the Service restored (Incident Management), and the method is root cause analysis (Problem Management).

However you implement each process you should have clear protocols for managing the overlaps and linkages.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
ErnieB
Newbie
Newbie


Joined: Aug 19, 2005
Posts: 4

PostPosted: Sat Nov 12, 2005 6:10 am    Post subject: Reply with quote

nuker wrote:
good example. Is exactly also my opinion.

...but often in smaller companyes you will not find a explicit problem process because the same people (men) solves every incident/problem. but they do it as well.


"Who" resolves incidents/problems may be an issue from a staffing perspective. However, from an ITIL perspective, it is the management of the incidents/problems (not the people solving them) that are addressed.

One of the biggest reasons to separate incidents and problems is to provide management a view into the nature of the work their support staffs are doing. Incident solvers and Problem solvers generally have different skill sets (and different pay rates). Knowing the incident/problem workloads allows managers to make better decisions regarding the kind of support personnel on their staffs.

Granted, very small companies (IT departments of <20) won't get much benefit from implementing two separate management queues. Where I work, our IT department is <100 people. By implementing incident and problem management, we were able to outsource our incident staff and use those who were left behind to work on problems. Overall customer satisfaction went up dramatically with little increase in cost.
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.