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: RSchindle
New Today: 44
New Yesterday: 89
Overall: 139462

People Online:
Visitors: 59
Members: 2
Total: 61 .

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 - Can anyone give me examples of a problem, a Workaround...?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Can anyone give me examples of a problem, a Workaround...?

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


Joined: May 03, 2005
Posts: 6

PostPosted: Sun May 08, 2005 11:40 am    Post subject: Can anyone give me examples of a problem, a Workaround...? Reply with quote

hi,


Can anyone give me examples of a problem, a workaround, an incident ? I would like to understand the differences but with examples, I had read many definitions and they make me confuse.
I would be grateful. Greetings.
Back to top
View user's profile
Skinnera
Senior Itiler


Joined: May 07, 2005
Posts: 121
Location: UK

PostPosted: Sun May 08, 2005 7:19 pm    Post subject: Reply with quote

Put simply;

An incident would be any break in service from the norm offered to end users.
eg - customer's location doesn't appear in a drop down list

A problem would be the underlying cause of one or more incidents.
eg - this location has inadvertently been removed from the drop down list

A workround would be a means by which end usres can continue to work that doesn't involve resolving the underlying problem.
eg - end users are told to select 'Other' from the drop down list

Hope that helps...?
Back to top
View user's profile Send e-mail
stud3
Newbie
Newbie


Joined: May 03, 2005
Posts: 6

PostPosted: Sun May 08, 2005 8:23 pm    Post subject: Reply with quote

hi Skinnera,
thanks for the answer, but sorry, there are things I don't understand, what do you mean, when you say "drop down list"?

Quote:

A problem would be the underlying cause of one or more incidents.
eg - this location has inadvertently been removed from the drop down list


I need examples. Which is an example for the explanation above? for a workaround too.

Any Help is welcome.

Greetings
Back to top
View user's profile
Skinnera
Senior Itiler


Joined: May 07, 2005
Posts: 121
Location: UK

PostPosted: Mon May 09, 2005 2:26 am    Post subject: Reply with quote

I was using an example of any application - say your helpdesk logging tool - that would use drop down lists to provide end users with options to choose.

A drop down list would be like you get on your internet browser tool bar, or the Topics menu at the top right of the forum page.

The examples for Problem and Workround were following on from this initial example.

The resolution for the incident and the underlying problem is to reintroduce the customer location to the drop down list (via Change Control), but in the meantime end users can 'workround' the issue by choosing the option of 'Other' from the drop down list (which, for the purposes of this example, is still available from the drop down list).

This workround means that end users can continue to work, even though the problem is still there.

Any clearer...? Smile
Back to top
View user's profile Send e-mail
stud3
Newbie
Newbie


Joined: May 03, 2005
Posts: 6

PostPosted: Mon May 09, 2005 7:07 pm    Post subject: Reply with quote

hi Skinnera,
yes now I understand. Thanks for the answer. Because I don't work with ITIL, I am only a Student, I investigate about ITIL, and there are many things in books, most theorie but not the whole informations are really implemented in companies the way these informations are described, that's why I visit this forum to ask experienced people in ITIL. Greetings.
Back to top
View user's profile
dailo
Newbie
Newbie


Joined: Jul 16, 2005
Posts: 7

PostPosted: Sun Jul 17, 2005 2:06 am    Post subject: Reply with quote

from my experiences working at a tertiary institution service desk and reading the ITIL foundation course material.

incident is an event or something that cause a disruption from the norm of business operations. e.g. ms word fails to start

a problem is when a incident or multiple incidents cause disruption to business activity. e.g. ms word crashes everytime user start it up

workaround - get user to use notepad to type documents while a permanent fix is being created.

error - is defined as a problem which a solution has been found to fix it.

known error - a known problem with a resolution to the problem but has occured again.

Usually the incident manager will look at all outstanding incidents that have turn red and breach 50% of the time taken to fix it.

then it goes to the problem manager if the incident gets escalated up.
Back to top
View user's profile
rjp
Senior Itiler


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

PostPosted: Sun Jul 17, 2005 8:59 pm    Post subject: Reply with quote

Quick Version:

* AnIncident is a disruption to an agreed service.
* A Problem is the root cause of one or more incidents.
* An Error is a faulty CI (configuration item)

Problem Management raises an RFC designed to get rid of the Error(s).
Work arounds are what either Incident Management or Problem Management do to temprarily reatore the service (not correct the Error) while they are waiting for the change.

And they are distinct; For example an Error is not a 'kind' of incident, and a Problem is not 'collection' or Incidents or Errors, or a 'more serious' kind of incident.

These distinctions will only make practical sense as your processes mature and you begin to formally implement Configuration Management and Service Level Management (in particular).

And a more lengthy discussion...

The relationship between Incidents, Problems and Errors is a common source of consternation to those trying to set up new processes. And this perfectly understandable given that in everyday-common-sense usage the meanings of all these terms overlap around the idea of a fault.

Now there is a be-practical, common-sense element to handling these ITIL 'entities' that should consider in the real world of process implementation. But for the sake of clarity, and to answer the question, I'll go over the concepts first.

In 'ITIL-speak' Incidents, Problems and Errors do not 'overlap'. They are quite distinct concepts. So, one of the tricks to sorting them out is to consider what they are not:

Incidents and Problems are not - by definition - failures, breakdowns, malfunctions, errors, or anything like that.

Errors on the other hand are (but they are failures, breakdowns, etc in the context of a specific defined service - not in general terms)

Incidents are simply events that result in the disruption or degradation in the agreed functioning (level) of a service.

(The thing to note here is the focus on the concept of a Service and makes explicit mention of the concept of 'agreement'.)

Problems are simply the root cause of one or more incidents.

(The trap here is to assume that 'root cause' is another word for a break down.)

Incidents and problems are not (directly) 'broken' components (CIs - Configuration Items), whether hardware, software or other. But what about CIs? Obviously in most environments most incidents and problems will be traceable to a wonky CI of some kind.

That's what Errors are for - in ITIL it is only the error that is by definition a faulty CI.

Less theoretically, lets look at these distinctions in the context of an 'implementation' where some ITSM capabilities are being set up, but the whole portfolio of management practices are not in place.

The ITIL disciplines are extremely cross-functional. So the inclusion of 'agreement' in the incident definition is a specific reference to Service Level Management. While the use of Services in the definition rather than components is an indication of the very strong interdependency with Configuration Management.

Incident Management is very engaged with Service Level Management (SLM). It is SLM that sits down with your customers and establishes just what services you are delivering and what they entail. So an Incident isn't simply a breakage, or even a disruption to business activity in general. It is a disruption to 'agreed' business capability (and the levels of that capability) as established in your SLM processes, and documented in SLAs.

In section 4.4.1 of the Red Book (Service Delivery) you will find the following:

Quote:
Some organisations integrate...their Service Catalogue as part of their Configuration Management DataBase (CMDB). By defining each service as a Configuration Item....the organisation is able to relate events such as Incidents and RFCs to the services affected....This can work well and is recommended.


So where there are clear definitions of services, and a CMDB that can map those services down to their constituent CIs you start to get solid process integration - and those apparently finicky and overly-theoretical distinctions between Incidents, Problems and Errors, make real practical sense.

And finally to come back to earth. Most ITIL implementations start with the Service Desk and Incident Management, with the idea that they can grow everything out from there. This is a high risk strategy because both Service Level Management and Configuration management do not have the linear process relationship to Incident Management that for example Problem and Change Management have, They are more 'foundational' disciplines around which the others revolve and not having them should be factored into your early objectives and expectations.

Until you can get the basics of Service Level Management and Configuration Management in place, your Incident Management processes will be Break/Fix Management processes with some extras. You Incident Reports will be 'effectively' error-reports: remembering that spreadsheet apps, CD ROM drives, and SAP clients are not 'Services': and remembering also that fixing components is also not a Service, but an operational activity directed at restoring services.

Of course, even with very mature processes in place, many incidents will be break/fix events, and many problems will be about serious break/fix events that are having a major business impact. You will often know what the Errors are up front (even without a known errors DB), and often you will apply the fix before you ever get to formal problem management. Which is fine, and as it should be - you don't want overly officious processes that hamper timely responses.

But (depending also on the size and complexity of your organisation) as your processes mature, and become more integrated, the formal distinctions between Incidents Problems and Errors will become more important and considerably more useful. And it helps from an 'ITIL evangelism' point-of-view to get these distinctions clear from the get go.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Oz
Newbie
Newbie


Joined: Dec 09, 2005
Posts: 8

PostPosted: Sun Dec 11, 2005 12:39 am    Post subject: Reply with quote

A person slipped on a banana skin walking by the zoo to go to work. Incident
A goriila throws banana skins out of its cage . Problem
The person take a different route to walk to work Workaround

oz
Back to top
View user's profile Visit poster's website
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.