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

[stud3]

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.

[Skinnera]

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...?

[stud3]

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"?

[Skinnera]

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...?

[stud3]

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.

[dailo]

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.

[rjp]

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:

[Oz]

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