Incident Management vs. Incident Control

[Matthias]

Hello Everybody

I have a little question concerning the difference between Incident Managmeent as one of the ITIL Processes and Incident Control as a subprocess of Problem Management.

Of course Incident Management is responsible for all kinds uf incidents and has to classify the requests. But what is the role of Incident Control as a part of Problem Control? Does incident control only support Incident Management (for example concerning the serious incidents which can't be solved during 10 minutes)? Or is Incident Control just responsible for all the major incidents?

The other subprocesses as Problem Control and Error Control are no problem to understand because they are really different to Incident Management. Their aim is to find the rootcause and they are not as time critical as Incident Managment. But I don't know why ITIL makes a difference between Incident Management and Incident Control. I really have difficulties to draw a line between these two (sub-)processes and I hope that somebody is able to help me.

Thank you

[rjp]

Hi,

I'm not sure of the source of your confusion. Incident control is mentioned in the Service Support chapter on Problem Management - but not as a sub-process of Problem management. Eg.,

"6.5.3 Risks The benefits of Problem Management can be weakened by: Absence of a good Incident Control process..."

"6.3.2 Problem control The process of Problem control is very similar to, and highly dependent on, the quality of the Incident control process. Incident control focuses on resolving Incidents and on providing Work-arounds and temporary fixes for specific Incidents."

But in each case these sections are talking about the similarities and dependencies between the two processes.

There is an Incident-matching process - and a flow chart for it in section 6.6.1, but it is important to bear in mind that incident records in this case are input for the Problem Management process, and that is part of the problem identification tasks which will review incidents to see if a significant number have (or may have) the same root cause - in which case they will be related to the problem record.

But they will not be altered by Probelm Management and incidnet matching is not intended to be a step to resoultion - ie., part of the incident life cycle. In fact the Problem Management process is just as interested in closed and resolved incident records as those that are still active in some way.

Perhaps you are thinking of 'errors' and 'incidents' as synonyms? Problem Management does have an Error control sub-process but this is not another Incident Control process.

If that is the source of your confusion, the following may help...

A common (and perfectly natural) missunderstanding about Incidents is that they are what happen when something is faulty.

It can be a bit of a jolt to notice that nowhere in the definition of either an Incident or a Problem will you find a concept remotely connected to the idea of something being faulty, broken, in-error, or just a little off colour

I did this in a bunch of familiarisation session I took with technical support staff.... First I explained the difference between a problem and an incident. Then I asked them if the 'got it'. Some wanted to argue the value of it, but everyone felt they understood it. Then I wrote the definitions up on the white board and asked them if they could see anything that had to do with things being faulty or breaking. You could just about see the shift in understanding on every face in the room. They had got the 'Problems are the root causes of Incidents' part, what they hadn't got was that Incidents aren't faults.

Incident are service disruptions, and problems are the root causes of incidents.

ITIL however does allow for the situation involving incidents and problems that arise because thing break - and that is what Errors are for...

6.7.1 An error is identified when a faulty CI ... is detected. (Of course 'faulty / CI' could mean inaccurate instructions somewhere - it isn't always a breakage as such.

It is counter-intuitive, but Incidents, Problems, and Errors are quite separate things - and only the error is by deffinition about faults.

Of course it's common sense that many Incidents, (disruptions), and Problems (causes of one or more dusruptions) will only come into existence because there was an error somewhere, but neither Incident nor Problem managment are literally about 'how' you 'fix' things - there are actually about how you control and manage how things are 'fixed'.

Anyway I don't know if this addresses your confusion or makes it worse - if the later I apologise in advance.

Bit I think it's safe to say at least that Incident Control is not a sub-process of Problem Control. So really there is no need to try and work it out.