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.

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.

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.

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