How to structure Problem Management?

[pablob]

Am I right in thinking that problem management is essentially split into two areas: 1) Linking Incidents to known errors or new problems as they come in to the service desk 2) Retrospectively analysing past incidents to determine common root cause and linking to known errors or creating new problems?

Should the linking of incidents to problems be confined to the role of the Problem Managers or should Incident Managers/Service Desk staff be allowed to link incidents to problems/known errors as they come in?

I know there are probably no hard and fast answers as it will depend upon the organisational structure and the culture within each environment, but I'd like to know what people think?[/quote]

[ElaineL]

Once we log a problem, we let anyone who enters Incident tickets link with the problem ticket. We occassionally have issues with someone linking a ticket inappropriately, but we regularly review them to keep them cleaned up.

[Guest]

You are right in your thinking. Problem Management is effectively split into two streams - proactive and reactive.

For my organisation, the inputs to reactive Problem Management are Incident Management and Event Management processes (Event Management is technically a sub-process of Incident Management under ITIL but we have split it away as it has specific tool needs).

For reactive Problem Management the inputs are the Incident and Availability reporting. Analysis is performed on a regular basis to look for realised or potential Problems.

Like ElaineL, we allow anyone logging Incidents to link the record with a Problem record.

[blamblam]