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: MarioGsc
New Today: 37
New Yesterday: 72
Overall: 139527

People Online:
Visitors: 50
Members: 0
Total: 50

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

Incident to Problem

 
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message
Phil Howlett
Guest





PostPosted: Thu Nov 10, 2005 11:11 pm    Post subject: Incident to Problem Reply with quote

We are about to roll out some notes to IT support users on how to promote an incident to a problem and what the criteria for this should be.

The users will be requested to use an email form to the IT Problem Management Team and we can then assess the information received and either or accept/reject and open the problem record if necessary.

Does anyone have a similar process in place and if so, what criteria do you use (repeat incidents, impact, users affected, time lost etc).

Many thanks for any responses.
Phil.
Back to top
ErnieB
Newbie
Newbie


Joined: Aug 19, 2005
Posts: 4

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

We have two criteria.

The first is simple--any non-critical incident which cannot be completely resolved within 3 business days is automatically raised as a problem. Incidents which are resolved with a work-around are also automatically raised to problem status.

The second involves repeat offenders. Any incident which occurs more than once results in opening a problem report. There are exceptions, of course, such as password resets and the like. Most problem reports opened for repeat offenders are closed, after review, with no action taken. The rest are worked as problems.

Impact, users affected, time lost, and other criteria are not used. The basic reason is to keep things simple. Adding many criteria can cause confusion as to whether an incident should be raised to problem status.

It's important to keep true incidents in the incident management process. If too many are incorrectly converted to problems (in order to reduce queue length or increase turn-around time), the weekly review of problems becomes a many hour ordeal that no-one wants to do.
Back to top
View user's profile
rjp
Senior Itiler


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

PostPosted: Sat Nov 12, 2005 5:02 pm    Post subject: Reply with quote

Don't view PM as simple a 'fourth' level of incident escalation.

Work being done, is 'by definition' Problem Management when those doing it are investigating the root cause of an incident and applying changes to erradicate it.

In real Incident resolution, praticulary that concerning small break/fix incidents with standard changes applied, Problem resoultion is ocurring. Incident resolvers should be able to log and record this work in the Problem Management process.

You need a planned Problem Management process for intractible service disrutpion incidents, and for types of incidents which are ocurring repeatedly , regardless of the effectiveness of any available workarounds. But you also need to acknolwedge that often the only way to resolve an incident is to resolve the underlying problem, and allow that work to procede smoothly (and un-officiously) without undermining the difference between Incidents and Problems.

In short, the definition of a Problem is not: A service disruption that goes on too long or has too high an impact to be tolerated.

A Problem is the root casue of one or more incidents.

The critera you have described for creating is fine if you are actually switching to problem resolution at that point, but it sounds ecxlusive in a bad sense. What a about incidents that obviously need to be resolved "as problems' from the moment they are reported?
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
taiger
Newbie
Newbie


Joined: Dec 28, 2005
Posts: 8
Location: The netherlands

PostPosted: Fri Dec 30, 2005 9:28 pm    Post subject: Reply with quote

Hi,

we're thinking of making a problem record when an
incident has occurd that has ( or had ) a great impact on the
business when the root coase is not clear.

though it may be an incident, it might be an incident
that you're not want to see again.
In my opinion in this way you are working proactively

regards
Frank
_________________
"if you aim at nothing, that's what you're likely going to hit"
Back to top
View user's profile
Jules
Newbie
Newbie


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

PostPosted: Wed Feb 01, 2006 8:49 pm    Post subject: Reply with quote

RJP said:
Quote:
In real Incident resolution, praticulary that concerning small break/fix incidents with standard changes applied, Problem resoultion is ocurring. Incident resolvers should be able to log and record this work in the Problem Management process.


May I discuss this a bit? It seems to me that its risky to talk about problem resolution occurring as part of the incident process, because

    * root cause analysis is not necessarily happening
    *incident analysts are probably not trained in problem resolution and need to concentrate on incident resolution

Of course incidents do trigger problems but that is a distinctly different process. The incident process has to be able to record the resolutions or workarounds without reference to Problem.

I welcome any comments that can help me understand this better!
Back to top
View user's profile
rjp
Senior Itiler


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

PostPosted: Sat Feb 04, 2006 12:11 am    Post subject: Reply with quote

Jules,

to clarify... it was not my intention that a break/fix resoultion to an incident be logged in a PM record instead of an IM record - but that where appropriate problem management (and indeed change management activity ) of a simple nature should be recorded without overly officious procedures.

Eg. Someone reports a dead desktop. Incident resolver spotting scorching on the power supply correctly identifies the root cause (power supply shorted out) and implements a standard (pre approved) change by replacing the part.

Incident, Problem and Change Management activity has taken place here. I was suggesting all facets of the activity should be captured - not the IM activity alone.

However, this is merely an 'idea' and I am aware there are some gotchas here, and that, equally, it would not be sutiable in all environments.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Jules
Newbie
Newbie


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

PostPosted: Sat Feb 04, 2006 12:55 am    Post subject: Reply with quote

RJP

Thanks; yes, I see where you are going, but I dont recognise a root cause analysis, hence no Problem process. The guy has an Incident - and found the fault - and from that he can jump straight to a Change.
In this example, I feel the best way to determine if a root cause analysis was done is to ask if the 'resolution' did anything to prevent repeat incidents of that type. So root causes might be:

    *overheating lack of ventilation - (check environment)
    * under spec equipment (review change process for adding periphs).
    * manufacturing fault (identify batch, contact manufacturer)
    * mechanical damage (secure cables)

- resolutions in ()

Preventing repeat incidents is one objective of Problem of course.
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Sat Feb 04, 2006 3:25 pm    Post subject: Reply with quote

Hi Phil,

There is no hard and fast rule, here. What's important is that you're capturing everything and using it to drive controlled work.

Many of the companies we help with this problem, especially the larger ones, like to view Incidents as a way to record "disruptions" associated with an End-User's experience. They use Problems as a way of documenting a potential or known "defect" in a product, service, or environment that will most likely require "Change" at some point.


Most of the companies we deal with use three primary drivers for Changes: 1) Problems, 2) Risks, and 3) Requirements. They like to think of a Problem as something that is "known to be wrong" and that must be fixed to avoid it from reoccurring. They like to view a Risk as a "potential future Problem" that they want to avoid. And, they like to view a Requirement as a "request for something new" (Although, if you think about it, Problems and Risks that drive work are actually requirements, too). Incidents, on the other hand, tend to be viewed as drivers for Problems, Risks, and new Requirements.

FYI, there is no section to cover Requirements, in ITIL, nor does there appear to be a clear linkage between Risks and Changes. While ITIL is a great place to start, there appear to be some very significant gaps in it, as it doesn't cover the whole process associated with managing bigger picture IT operations. It's strictly intended for the support side of IT operations and, therefore, leaves things out of the bigger picture. Use your common sense to address that picture. Look to things like ITIL, RUP, MSF/MOF, etc. as guidelines and not defacto standards, since not one of them, alone, is perfect.

If you're interested in some of the reference information we have, please feel free to contact me, either through this site or directly. I'd be glad to help out.

Again, there is no hard and fast rule. Just common sense. Good luck with all of this.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
rjp
Senior Itiler


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

PostPosted: Sat Feb 04, 2006 5:22 pm    Post subject: Reply with quote

Frank,

good post, and I agree that practical concerns are paramount. On this forum I allow myself space to focus on the theoretical because it is an ideal space for it, and balances out the challenges of my more practical working life.

One (freindly) disagreement Smile - ITIL does address 'requirements', in a few places - In the the Service Level Management chapter of Service Delivery, as well as in the Infrastructure and Application Management books.

Lifting management understanding of SLM from drafting SLAs and monitoring the 'nines', to the key process area where services are assessed, planned, and developed in partnership with the customers - within a formal business cycle - is a constant challenge for me, and one that has only seen small incremental gains.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Mon Feb 06, 2006 1:23 pm    Post subject: Reply with quote

I stand corrected. Thanks for the info. I will check it out.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Globis
Itiler


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

PostPosted: Thu May 03, 2007 7:22 pm    Post subject: Reply with quote

Quote:
It's important to keep true incidents in the incident management process. If too many are incorrectly converted to problems (in order to reduce queue length or increase turn-around time), the weekly review of problems becomes a many hour ordeal that no-one wants to do.


Incidents are always incidents, and cannot be converted to something else. If an incident happens often enough, or has a significant impact on the service, it will prompt the creation of a problem record, but it does not become a problem.

You cannot stop recording incidents simply because it is a known error. Incident management goes on business as usual irrespective if a problem record exists or not. And in any case if you do not record the incidents how can you measure the effectiveness of problem management?

Quote:
While ITIL is a great place to start, there appear to be some very significant gaps in it, as it doesn't cover the whole process associated with managing bigger picture IT operations. It's strictly intended for the support side of IT operations


ITIL is much broader than people think, check out:
    The Business Perspective Vols I/II
    Security Management
    ICT Infrastructure Management
    Application Management
    Planning to Implement
    Software Asset Management


Dave
Back to top
View user's profile
entivo
Newbie
Newbie


Joined: Jan 12, 2008
Posts: 17

PostPosted: Tue Aug 12, 2008 9:03 pm    Post subject: Reply with quote

This is an interesting thread. We use CA Unicentre as our service desk tool where an Incident ticket can have a status of Open, Closed, Awaiting Supplier, Hold - Pending Change, Hold - Pending User, Fix In Progress, Researching or Service Desk Follow-Up.

It is suggested that an Incident status should be changed to Resolved when a new Problem record is opened to identify the root cause. After all, Incident Management is concerned with getting service resumed asap.

I am toying with the idea of including a new Incident status of "With Problem Management" to identify incidents that have triggered problem records because I don't think the end-users will understand the difference between incidents and problems and when they get an email stating that their incident has been resolved they will probably not be happy especially if they know they have been issued a temporary work around.

The trouble with this new status is that the incident remains open, when in reality it is resolved and merely being looked at by a different team.

Any opinions or feedback would be welcome.
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3292
Location: London, UK

PostPosted: Tue Aug 12, 2008 10:43 pm    Post subject: Reply with quote

You can do what you want witht the tool

The use of a flag to say that the incident is still 'active' not closed and has been refered as a candiate for a problem record is a good thing

The problem (nice phrase) --- the issue I see is that a lot of companies intermingle incident and problem and forgot that incident management does have some diagnostic and troubleshooting

Problem mgmt should be used when the IM diagnostic and troubleshooting can not restore service (other than reboot - grin- which works with microsoft products always. TG MS is not used for flight control)

PM should be used to find 'real problems'.

NOTE: The issue about the bad power supply frying the computer. I dont see why a problem record / prob mgmt process beign invoked. Unless this is the Nth desktop in that office which has blown. then there is a 'problem'

And Changes can result from Incident as well as problems. They are usually called emergencies ;00
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
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.