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.
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.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
The Itil Community Forum: Forums
ITIL :: View topic - what is the different between incident and problem
An incident is when a service interruption takes place and you know how to fix it, by solving the incident or with a work-around. A problem can cause incidents and you do not know the root cause of the problem.
An example may help... If a PC freezes it is an incident. You resolve the incident by rebooting the PC...the user can work again. You still have'nt figured out what was causing the PC to freeze in the 1st place...You need to open a Problem record so that the root cause can be investigated.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Tue Sep 12, 2006 5:11 am Post subject:
Hello dvd777,
An Incident represents a disruption to one or more end-users' experience(s). In other words, something they expect to act a certain way, doesn't.
A Problem is a known or unknown defect or a known issue that can generate one or more Incidents, if it isn't addressed properly.
A clear example of an Incident to Problem relationship is when an end-user calls the Service Desk with the reporting of a disruption in an application they're using and someone traces it to a defect (Problem) in the application's code.
A less clear example, but one nonetheless, is when one thousand users have all called the Service Desk, over the course of a year, to have their passwords reset. The Problem will be something like "Too many calls to Service Desk for Password Reset is causing distractions from other more critical work and is eating up time and funding that could be better spent in other areas of the business.", where it might drive a Requirement for a Password Self Service feature for end-users.
Anyhow, I hope this helps.
Regards, _________________ [Edited by Admin to remove link]
It may also be interesting to add that one of the reasons why ITIL separates the two processes is mainly because the objectives, and therefore the interests, of the two groups could be competing.
On one hand, you have the Incident Management process that is essentially concerned about restoring service in the shortest possible timeframe. Time is the driving factor.
On the other hand, the Problem Management team's focus is to work deeper in strengthening the service reliability. Here, quality is the driving factor.
One must be careful when mixing the two and, from an organizational standpoint, the people in the roles of Incident and Problem Managers need to build a strong relationship. _________________ BR,
Fabien Papleux
Accenture
Technology Consulting | Service Excellence
Red Badge Certified
Joined: Aug 11, 2006 Posts: 262 Location: Netherlands
Posted: Tue Sep 12, 2006 10:21 pm Post subject:
Fabien wrote:
One must be careful when mixing the two and, from an organizational standpoint, the people in the roles of Incident and Problem Managers need to build a strong relationship.
Strong relationship: yes. However, to combine the two roles within one person is a no-no as this person will effectively have to make a choice of priorities that in real life is often in favour of incident management.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Wed Sep 13, 2006 2:22 am Post subject:
Hello All,
One thing ITIL doesn't tell you is that each Product Ownership group does it's own Problem Management work as part of it's Product Management responsibilities. Therefore, if you have "N" different products in your enterprise, with "N" different Product Owners, each group is typically performing it's own Problem Management, Risk Management, Requirements Management, Release Management, Change Management, etc.
The role of the "ITIL" Problem Manager is more of an oversight or horizontal role, that spans "across" all of the individual group. The ITIL Problem Manager does not own the Problems at a Product level. He or she is typically more concerned about the bigger picture view of Problems that span all Products and Services and how they impact the whole enterprise.
For example, Product Owner team "A" might have a very high priority Problem that they feel they need to resolve immediately. They may feel that it is a far higher priority than a Problem that is being managed by Product Owner team "B" for their respective Product. The ITIL Problem Manager may help shed light that fixing "B's" perceived lower priority Problem might actually be more beneficial to the enterprise as a whole.
Many enterprises mix the two types of Problem Management (Vertical for Product Owners and Horizontal for Product Support & Maintenance) and create contention because of it. Remember, that Product Management is a highly effective set of formal roles and responsibilites that have been around for decades, long before ITIL. It falls to the Product Owner and his or her team(s) to perform the vertical work, not the IT Service Management and Service Delivery teams, who exist to help support and maintain such Services and Products.
I hope this helps.
Regards, _________________ [Edited by Admin to remove link]
Joined: Sep 16, 2006 Posts: 3591 Location: London, UK
Posted: Mon Sep 18, 2006 5:55 am Post subject:
Incident Management is the management of incidents which impact the service that is being provided. The goal of Incident Management is to restore the service as soon as possible.
The steps in incident management should help restore service as soon as possible by finding out whether there is a work around or solution to restore service which the Service Desk can recommend to the user or whether the incident gets escalalted to the Nth Line support and resolving group.
Problem Management could care less whether the service is active or not. That is not its purpose. Its purpose is to find out why an incident(s) happened and what is the root cause of the incident. Once the root cause has been found, then problem mgmt may recommend a solution to prevent the incidents from happening again or a 'work around'
It all depends on the weight of some variables
Impact
Urgency
Priority
For example, a problem which affects all Windows 2000 Workstation machines had a solution of upgrading to Windows XP. However, the current machines dont have the RAM. Hard Drive and CPU speed.
This has a HIGH impact but a low priority. The priority bein low because of the cost _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
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