Proactive Problem Management activities are concerned with identifying and resolving Problems and Known errors before Incidents occur, thus minimising the adverse impact on the service and business-related costs.

Identifying and eliminating problems beffore they cause incidents is the high-value end of problem management.

I agree. That being said, we do not open problems without opening an incident first. Granted, the incident may be closed as soon as it is transferred to the problem management process, but we do a significant amount of analysis from our incident management database with regards to workload, number and character of issues, etc.

If we want to do some analysis on incidents, it is difficult to include problems if they were not initiated as incidents. We can always exclude them from analysis by filtering them out. However, it's hard to pull them into an analysis when they come from two different sources.

You cannot have a problem ticket opened for an issue that does not have an incident ticket. For the simple fact that you are doing problem managment not incident managment.

Incident managment in which ever case may be is the first had information provider to the problem managment team.

As you said unless proactively problem managment team being incident management team for time being ( Which is definately possible because ITIL is just a framework and no complusion as to how your service support should work together)

I only hope the above covers the lid for the question you had.._________________Regards,
Catchjack

I look at this way, if somone reports he cannot print then that's a problem, if 15 people report the same problem then it becomes an incident. To my way of thinking an incident is something that affects a system not a user.

Multiple incidents cause a problem. However, it is quite possible to have a problem with no incident record. It is the old, I noticed an alligator in the pool. It hasn't bit anyone, but maybe we need to get it out of the pool!

ITIL is a framework - not a set of rules. There are, however, some concepts that are pretty central. The difference between Incidents and Problems is a core concept in ITIL. Or to put it a different way you would deffinitely drop points in any of the exams if you didn't have this straight.

An Incidnet is a disruption or degradation to agreed services (regardless of cause).

A Probelm is the root cause of one or more actual or potential incidents.

They are different 'things' - they are kept in different record structures, they have their own related but independent processes, and most importantly unique objectives, KPIs, and measurements.

Business is business, and we are all free to 'define' incidents to fit the current requirements of the site we are working in.

But be willing to acknowledge that at the point you start to differentiate problems and incidents on the basis of what's been affected, or number of users impacted, or other abitrary boundaries - it aint ITIL. And this is after all an ITIL forum.

There is, however, scope within the ITIL for different approaches to the topic at hand - the cardinality of the Incident -> Problem relationship. Also it is an open question whether you wish to keep separate Known Error records or simple have the Known Error as a status on your Problem Record. Both perspectives are there in the book.

I recommend a many to one relationship between Incident and Problem records, and separate Problem and Known Errors, but this is one of many possible approaches. This is, however, only a way of managing the interface between the Incident and Problem Management processes, it has nothing to do with what Incidents and Problems are in ITIL.

Oh oh. Based on the tension in this thread, I'm sure I'm entering dangerous territory, here...

My clients have used the following categorizations:

Incident: A disruption to a service, environment, product or system that is used by someone (such as an end-user) or something (such as a test system). Ex: Lights flickering, computer glitching, password needs changing, etc. Typically, an Incident is any reported disruption, such as those coming through phone calls or email to support or through testing systems that show failure in regression tests but for whose root cause has not been determined.

Problem: A defect or issue, whose root cause is known or unknown, that can be traced to one or more repeatable Incidents. Ex: a bug in software, a defective hardware component, etc. A Problem can be reported from any source, such as the help desk, testing staff, developers, etc. Finding defects before they're reported as incidents is a good thing, no?

Risk: A symtomatic side effect of a potential or existing problem that will lead to one or more significant Incidents, if not addressed. Ex: Y2K fallout.

As far as whether or not a Problem can exist without an Incident, I guess it's a matter of semantics. Can you have a bug in software that you identify before it leads to a reported Incident? I'd say yes. That bug would be a Problem that needs to be fixed, yet has no reported Incidents associated with it. The Risk is that if you do not fix the Problem, an Incident of some level of significance may occur, with side effects to your end-users and/or your organization.

An potential for an outage (an error) has been discovered which exposes a service to an outage. no outage has ocurred yet, hence no incident.

ITIL defines an incident as

Quote:

any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in, the quality of that service.

That's right "which causes, or may cause, an interruption to, or a reduction in, the quality of that service". The fact that a "potential" error has been discovered would lead me to believe that this should be tracked as an incident. It may be immediately closed afterwards but it should still be identified as an incident first. Then a problem record should be opened and the incident should be related to it.

An potential for an outage (an error) has been discovered which exposes a service to an outage. no outage has ocurred yet, hence no incident.

I think this is really a procedural issue. An incident can be a "service request", hence, if an incident is required in a given procedure before a problem can be opened why not simply request that "someone take a look at X"?

if you go through the incident and problem data, you will discover potential problems even without an incident/degredation to performance. I would log the problem, make the determination if a CRF should be entered and...

Can a potential incident be recorded as an incident? Answer is 'yes'. Ideally it should be - the benefits of doing this:

1. you bring visibility to this potential incident by recording it
2. steps to avoid it can start (though you can, even without recording it, but formally an incident is born)

An incident is "any event....which causes, or may cause, an interruption to, or a reduction in, the quality of that service"

Now should it be recorded as a problem as well?

Perhaps not immediately. Some investigation is called for...if no workarounds could be found or when the imact is likely to be high, yes, then is the right time, you can go ahead to flag it as a problem as well.

It doesnt matters whether an incident ought to exist before a problem can. What matters in my opinion is whether or not some record is made so that knowledge of a potential Inc/Prb is shared and not getting pondered over in someone's mind. Such visibility is important for the reasons mentioned above.