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: EBaber
New Today: 2
New Yesterday: 56
Overall: 139548

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

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 - ? Problem Mgmt, Known Error, Work Around
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

? Problem Mgmt, Known Error, Work Around

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


Joined: May 03, 2005
Posts: 1

PostPosted: Tue May 17, 2005 10:40 pm    Post subject: ? Problem Mgmt, Known Error, Work Around Reply with quote

We are in the process of starting ITIL implementation; I have the Incidents, Requests and Change Management done. The Problem Management has me confused.

I understand the concept but I donít understand where the known errors are recorded and work around are captured. What types of categories need to be created for Problem mgmt? Do problem categories get created on the fly as problems occur?

All help is greatly appreciated,

Stydani Question
Back to top
View user's profile
Guest
Guest





PostPosted: Wed May 18, 2005 10:14 pm    Post subject: Problem management Reply with quote

Problem management is a tough cookie as most organizations do not have the resources or toolsets to implement it properly. Problem Management, in my opinion, is typically implemented as reactive triage rather than proactive detection, diagnosis, and remediation.

Try this whitepaper as a starter...
bitpipe.com/detail/RES/1110995399_466.html
Back to top
shajij@gmail.com
Guest





PostPosted: Tue Jul 19, 2005 8:58 pm    Post subject: Reply with quote

Work around is ideally provided by Incident Management even though Problem Management also uses them depending on the urgency of the fix required. A Workaround can lead to being a Know error once a way to circumvent the error is identified. A good way to start problem management is as mentioned using Reactive approach. Identify, Record, Classify, investigate, Diagnose(say error identified), Identify & Record Error, Assess Error, Record Error Resolution, Close Error and Associated Problems.

Now if there is a record of error and problems then each time you receive an incident you check if known error for the incident exists if so use error resolution, else if problem is open for the incident then add to incident to the problem list, else if routine incident then treat as applicable.

If none of the prior mentioned exists then create new problem record and proceed with steps mentioned before.

Hope this helps.
Back to top
GordNovoselnik
Guest





PostPosted: Fri Jul 22, 2005 7:21 am    Post subject: Reply with quote

To answer your questions:

Known Errors are Problem records which have a work around identified and/or RFC initiated.

Work arounds are used in/derived from Incident Management. Think in terms of 'how can I restore service in this incident? How can I work around the issue?'. In most cases, the work around is derived out of the investigation that takes place during the lifecycle of the incident, which makes sense since Incident Mgt's goal is to restore service in the most quick, efficient way possible. The Service Desk, when resolving the incident can choose to raise the issue to the Problem Mgt team to have a problem record created to help determine a more permanent solution and to vet the work around that's been used. The problem mgt team would create the problem record and invesitage a permanent solution. The next time the incident occurs (with most likely the same symptom) the SD can search the K.E. database for an approved workaround to expedite the resolution of the incident. At the same time, the SD would also relate the incident to the problem, hightenning the urgency and impact of the problem, and thus raising the priority of the related problem investigation. Before long a permanent solution is identified, and RFC is applied and the possibility of incident re-occurence is theoretically eliminated.

To answer your other question, it would be prudent to align your problem categories with the likely root causes that would represent your environment. The official CCTA ITIL documentation (Service Support)gives a good recommendation on how the categorization structure should be organized. The book isn't cheap, but it's an invaluable resource.

Hope this helps!

GordNovoselnik
Back to top
Guest






PostPosted: Thu Aug 04, 2005 12:37 am    Post subject: Reply with quote

Gord,
can Problem management ever create a workaround?
Is merely restoring service a workaround?
Some of the doc I've seen defines workaround as a method of avoiding the problem (even though the root cause and perm. fix has not beend found).

If for example a server hangs, is rebooting the machine (to restore service) considered a workaround?
Back to top
rjp
Senior Itiler


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

PostPosted: Thu Aug 04, 2005 1:12 am    Post subject: Reply with quote

Well I'm not Gord, but I reply anyway....

Yes Problem Management can find and record work-arounds.

Problem Management differes from Incident Management in that it looks for the root cause of one or more incidents. Once it does it creates a Known Error record, and ideally raises an RFC to fix the Error. Incident Management may find a root cause, but it doesn't look for them, (but if it does find one that's a bonus).

A fix may not be found by Problem Management for every Error - in fact one source of Known Errors are the 'bug reports' that vendors put out. These, and any work arounds, should go into your Known Errors Database - but finding a fix may be beyond the reach of your team (obviously they won't recompile an application the source code to which they don't have access).

So the example you gave is quite a good one - an app might run some services that are a bit 'twichy'. The symptoms are known and the work around is to bounce the service. Putting up the Known Error and Work Around records is something Problem Management would be expected to do.

Remember that the real difference between Incident Management and Problem Management is not the tasks they undertake - there are a lot of overlaps, and access common information. It is their objectives (and sequence) that sets them appart...

Incident Management aims to restore normal operations as fast as possible.

Problem Management finds and eliminates the causes of Incidents.

The 'health-check' for activities within each discipline is: Is undertaking that activity going to undermine the capability of the process to acheive its objectives. Finding a work around for a known error where:

* it is not possible to raise an RFC for a fix,
*or where for cost (or other reasons) a concsious decision is made not to spend resources on a fix,

does not undermine the objectives of Problem Management.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Guest






PostPosted: Thu Aug 04, 2005 1:51 am    Post subject: Reply with quote

thanks for clearing up some things, Rip.
I agree about the overlapping between IM and PM and we're finding out just that.

However, the example of bouncing a server while it resolves the incident and restores service does not avoid future recurrences.
As a result, we're not cosidering that an example of a workaround.
Back to top
Guest






PostPosted: Thu Aug 04, 2005 1:56 am    Post subject: Reply with quote

Me again...

If we go with the strict definition of a workaround, then the other example we're debating is if a workaround results in fewer occurrences of the problem but does not completely prevent it... what is that?

Example, a memory leak causes a server to hang after running for about a week. The root cause is not known yet but we know that if we reboot
the server on Wednesdays we lessen the chance. However on occasion,
depending on system load the problem occurs.

We're using 'partial workaround' for now.
Back to top
rjp
Senior Itiler


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

PostPosted: Fri Aug 05, 2005 1:02 am    Post subject: Reply with quote

Interesting point. (And glad to have help in some small way)

Perhaps 'workaround' is a concept that shifts its meaning slightly when going from the Incident Management to Problem Management contexts.

Frim the IM point of view I tend to think in terms of recovery - getting things going again. Often that action isn't going to prevent the incident recurring.

And this is after all why PM is there. PM has a brief to eliminate problems, and following on from that, where not able to eliminate the problem itself it would try to eliminate the 'impact' of the problem by looking for a stable work around.

But now we are in a territory where work arounds look like 'fixes' and strcitly speaking that should go through change management via an RFC.

And how many work arounds do people find that are both stable and not changes?

So for my part I think I would call any activity that ameliroates a known error, that isn't a change, a 'work around'. I'd just say there are better or worse 'work arounds' depending on how stable the service delivery situation.

A 'partial' work around seems to me like a perfectly reasonable term to employ in the case of less-than-ideal responses to a known error. And I agree, the goal should be to find work arounds that prevent incidents recurring.

Perhaps the Known Errors Database needs something that indicates Known Error, no work around, recommended incident resolution procedure is....

Which would use the best know action for resolving incidents with this Known Error indicated as the cause - and going back to your original example that would be restarting the service.

That would be a good thing - simplicity of the example aside - because you want to ensure that once a resolution to an incident is found, staff don't have to go through the investigation and diagnosis every time it occurs - until a real work around is found.

As I said, Interesting point Smile
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
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.