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


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: LaylaOReil
New Today: 27
New Yesterday: 34
Overall: 231599

People Online:
Visitors: 129
Members: 0
Total: 129



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

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.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - Problems vs. Incidents
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Problems vs. Incidents
Goto page 1, 2  Next
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message
Big Al

PostPosted: Thu Apr 28, 2005 12:44 am    Post subject: Problems vs. Incidents Reply with quote

I am still stumbling a bit on the difference between a problem and an incident. As an example, if a user calls to report an error message on his/her screen which has caused her system to hang, our support analyst would most likely record the details of the message and the other appropriate circumstances and then ask the user to reboot his/her system. I believe I'm describing an incident, which should be closed if the user reboots and is able to perform the function once again successfully. I don't think we'd spend a huge amount of time doing root cause analysis at this stage because it's a "one off".

How does this incident move to being a problem and when does this happen? Is this only done during the time when the incident manager reviews all incidents for a given period of time and determines trends? What if this is the only time this error has ever come up, is this still a problem or just an incident?
Back to top
Senior Itiler

Joined: Apr 26, 2005
Posts: 57

PostPosted: Thu Apr 28, 2005 1:58 am    Post subject: Incidents vs Problems Reply with quote

Hi Big Al, you are not the only one who is still confused. Many organizations still say problem when they refer to an incident.

What you described fits the “incident” as the purpose of incident management is to restore to normal service as soon as possible.

Problem management are linked to all incident records as there needs to be some method to correlate the tickets to find common incident tickets. The problem management team would then investigate. If it were a known error, a pre-defined solution would be applied to correct the incidents, which should result in the elimination or greatly reduce that particular type of incident. If it is an unknown error, then full root cause analysis needs to be performed to find a solution.

E.g., one of our clients had many incidents where hard drives would fail to boot up, or would crash throughout the work day. Was it applications hanging, was the image corrupted on desktop rollout, etc? Through root cause analysis, it was determined that only a certain type of drives was experience this problem. They tracked down all the drives, notified the manufacture of the drives, and replaced all of their drives, as it was a bad batch. One all of the desktops that had the drives replaced, those types of incidents decreased significantly.

Problem management needs to work with Incident Management. There should be a separate Problem Manager and Incident Manager, because they are two different roles. You have to remember, Incident Management wants to restore service as soon as possible, what ever it takes (take this with a grain of salt). Problem Management wants to get to the root cause, and this normally requires time. Of which your client usually does not have.

hope that helps,

Azard Omardeen
ITIL Expert / Accredited Trainer / ITSM Consultant
Back to top
View user's profile Send e-mail

PostPosted: Fri May 06, 2005 2:07 pm    Post subject: Reply with quote

Typically, incidents become problems when:
- Incident matching produces no Known Errors or previous problems
- Incident is of a high severity
- Incident is a repeat incident
- Root cause for the incident is unknown

The ITIL Service Support Book actually presents a flow chart table that can be referenced that describes when an Incident should be escalated to a problem. See page 102 - Incident Matching Process flow. This whole section discusses this issue.
Back to top

PostPosted: Tue May 10, 2005 1:42 pm    Post subject: Reply with quote

In your example, if the root cause is not known, then it is a problem.

No one says all problems require major effort to solve or need to be addressed right away. This would probably move to the Problem managers queue as a low priority problem. Business need would determine whether much effort would be spent working on it or whether to leave it as "under watch". This enables problem management to respond faster if it looks like more of these incidents occur again.
Back to top

PostPosted: Wed May 18, 2005 10:29 pm    Post subject: Reply with quote

Azard did a great job of explaining the traditional approach to Problem Management. This is a textbook ITIL answer - and if you're interested in a traditional textbook ITIL process implementation, this is perfect.

However, I respectfully disagree with this methodology as I believe some of the traditional assumptions are outdated. For example, traditional definitions assume that multiple incidents must occur before a problem is declared. This feeds the philosphy that PM is implemented by parent-child ticketing systems... where multiple incidents are rolled up into a single problem record. This is inherently reactive. Technology is advancing far enough to where this methodology isn't needed. While I believe that parent-chile ticketing is valuable and needed, it shouldn't be the ONLY means to PM, nor should other incident management tools be morphed into PM systems.

A second outdated assumption is that PM is implemented by a functional group of people that do nothing but PM. This sounds extremely inefficient and expensive to me. Most organizations are having enough problems affording the resources required to provide daily reactive support services.

As Randy suggested, if the root cause is unknown, it is a problem... and I suggest it is a problem at the first incident and should be prioritized appropriately. I suggest that if the incident goes through the PM process at the first occurance, future incidents will be avoided. This is the goal of PM.

I believe PM should be proactive. Technolgy has come to a point where we can proactively scan for error conditions without waiting for an incident to be reported. Those errors can go through a root cause diagnosis process and remediated to further prevent incidents from occuring. I believe most of this can be done through computer automation and analytics.

Back to top
Senior Itiler

Joined: Apr 26, 2005
Posts: 57

PostPosted: Fri May 20, 2005 5:15 am    Post subject: Reply with quote

Jacob, you definitely bring some good points to the table. The approach I mentioned maybe what you consider “traditional”, but your assumptions, I believe are made from what you infer rather than what I have actually written. Just to let you know, I take no offense being called a "traditionalist". Smile

So let me see if I can clairify.

I understand the resource issue, which is why I only identified the Incident Manager and Problem Manager as different roles. I think they should remain different roles. Ideally you would have two separate groups, one for Incident Management, and the other for Problem Management, that doesn’t mean you need to have a huge team dedicated to Problem Management as you would Incident Management.

I also think you would create a problem ticket for every incident ticket. And I do agree that problem tickets should be prioritized. Problems should be solved based on having the greatest benefit to the organization. Some problems may be such a low priority that it could a very long to find a permanent solution.

While it is hard to put all your thoughts down without writing a few pages covering every little detail, your points are taken. Ideally, it would be great to have an in depth conversation over a drink or two.

Back to top
View user's profile Send e-mail

PostPosted: Fri Jun 03, 2005 2:55 am    Post subject: Problem Management Reply with quote

Thanks, Azard.

I find the "traditional" approach to PM to be the only one that is really talked about these days - where the service desk is reacting to incidents and looking at trends, etc. to determine if there is a problem worthy of going through the PM process. And yes, my reference to your previous post being traditional was composed of assumptions, etc. Thanks for letting me be liberal.

I work for a software company that's is working on a proactive PM solution - so I suppose my perspective is a bit bent Wink I really value this kind of discuss because it helps me understand what challenges people have today and what future solutions will need to do to help solve "problems".

Good luck,
Back to top

Joined: Sep 23, 2004
Posts: 8

PostPosted: Fri Jun 03, 2005 11:54 pm    Post subject: Reply with quote

Wow! Great conversation guys! I work at an internal help desk where I lead a small team we call the Call Reduction Team (CRT). The goal of that team is to monitor incident data, identify trends in that data, then apply appropriate resources. Appropriate resources could mean a CRT member sending a broadcast e-mail to inform users of best practices or posting a solution on our IT intranet site. If the problem has a large enough impact, root cause analysis is initiated. This meeting includes representation from global desktop support team, the applicable application owner(s), and a CRT team member who facilitates the meeting.
We are currently trying to streamline our process for data analysis, as our current process in very manual and labor intensive. Is there a standard procedure or software solution for analyzing incident ticket data? Where can I look for more information on Incident/Problem management?
Back to top
View user's profile

PostPosted: Sat Jun 04, 2005 1:17 am    Post subject: Problem Management Reply with quote

Hutch... you bring up the major issue that I think most people have today... and that is gathering and analyzing the relevant incident data in order to determine the root cause.

This turns out the be the fundamental aim of a product my comapany has built - but I'll refrain from giving a commercial on this forum. Needless to say, I truly believe that the manual, human-based, and slow tasks of many of the incident and problem management tasks will be completely computer automated - including the actually root cause analysis. In brief, if a computer can gather an enormous amount of data, more than any human can analyze, and use statistical analysis and policy information to automate the root cause analysis of any error condition. What's more, the service desk can then be proactive because we no longer have to wait on the symptom to be reported by the user - rather a machine can proactively find true error conditions through automation.

Just my 2 cents at what I believe the future holds.
Back to top

PostPosted: Sat Jun 04, 2005 1:18 am    Post subject: Oops Reply with quote

oops, that previous message was from me.. just forgot to put my name in.
Back to top

PostPosted: Thu Jun 09, 2005 7:09 am    Post subject: Reply with quote

"... will be completely computer automated - including the actually root cause analysis. In brief, if a computer can gather an enormous amount of data, more than any human can analyze, and use statistical analysis and policy information to automate the root cause analysis of any error condition. "

I don't see that happening at all.

Who will analyze problems with the computer automated root cause analysis process?

Back to top

Joined: Sep 23, 2004
Posts: 8

PostPosted: Thu Jun 09, 2005 10:52 pm    Post subject: Reply with quote

Actually, we have found a statistical analysis software that will work for us. There is a bit of a learning curve involved because SQL is required for queries and such. It is still better than a human trying to analyze, re-categorize, then analyze again, attempting to locate incident trends! I can honestly tell you from my experience leading this problem management team so far, I hope what Jacob said about fully automated incident data analysis software in true! It would be a phenominal contribution to the IT community!
Back to top
View user's profile

PostPosted: Fri Jun 10, 2005 5:46 am    Post subject: Reply with quote

Incident analysis is completely different from Problem analysis.
Yes, searching for known problems is better left to automation, but root cause analysis... ?
Back to top

Joined: Apr 12, 2005
Posts: 4

PostPosted: Fri Jun 10, 2005 4:14 pm    Post subject: Reply with quote

I also work in software environment.

We are going to implement problem management process. No we are having Incidents in one database (our product) and 2nd level can force creation of Change Request in 2nd db (Starteam).

I am afraid, that implementing of Problem management will lead to big amount of problems.
Let's expect, there is a some number of incoming Incidents solved by 1st Level - I do not know exact number.
The rest is passed to 2nd level - according what I know they cannot solve about 80% of these Incidents, because they are software bugs and there is simple no quick solution! Some of the rest are questions - answered by developers usually (is this 3rd level?).
These 80% are becoming Change Requests and they are usually fixed in Release, Csp or Hotfix.

I think when the developer overtake Change Request, he starts with analysing root cause (problem control phase).
Unfortunately, there is probably no statistics how many of Change Requests handled by developers are leading to changes and the rest is solved by configuration, or...

I think the big difference here between "normal" service provider and software environment is in amount of changes.
It is often possible to solve user's Incident by quick fix:
Remove virus,
Change Toner,
Replace Desktop,
or Smile
And there is no so often neccessity to force Problem mgmt. and Change process.
Back to top
View user's profile

Joined: Sep 23, 2004
Posts: 8

PostPosted: Sat Jun 11, 2005 6:36 am    Post subject: Reply with quote

Perhaps I am speaking in the wrong context here. I am referring to the analysis of incident data, meaning tickets generated from reported computer related issues in our environment. These incidents range from software issues to network hardware issues to desktop issues to homegrown application issues.

Problems can be identified by analyzing this type of incident data and finding common incidents, or trends in the data. Are you saying I am off base on that "Guest" ? Perhaps you could elaberate on your points. They are comming across with a bit of a negative connotation. I am here to discuss this topic with colligues in similar situations. Pointing out more problems without presenting solutions does not help me. I look forward to any thoughts ...

PS: Thanks for the thougts MaP001
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
Goto page 1, 2  Next
Page 1 of 2

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

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.