Incident Vs Problem Management

[Dubz]

Hi All,

This is a bit of a general question on what you think the best process would be:

I work for a telecoms company, we have a massive physical network over which we provide various voice and data services to our customers. When we implemented Service Now we opted to log faults on individual service offerings as Incidents and faults on network devices as Problems. The justification for this was that a fault on a network device will cause multiple incidents i.e. multiple service offerings that are dependent on that device will go down and others may suffer increased latency as redundant routes become more congested.

So, now we have a new conversation going on around this build with some people claiming that a fault on a network device should be raised as an incident as well and only repeat incidents should be subsequently raised as a Problem. It has also been mentioned that the problem process involves some sort of investigative procedure so if we default to raising problems that procedure is kicked off unnecessarily when some 'problems' might have known errors and can therefore be dealt with as incidents.

I'd be interested to hear some different opinions on this, i'm struggling to see the benefit of treating faults on CI's as incidents.

Cheers
Dave

[Michael Fry1]

I would agree they should be Incidents. If the incidents are recursive or random, that are causing further incidents, a Problem ticket would be appropriate to do the root cause analysis and eventually create a Change to fix the issue. Also you can tie multiple incidents together using Parent/Child without tying them into a Problem.

[Dubz]

Hi Michael,

Thanks for the response.

Can you elaborate what the benefit would be to treating them as Incidents?

We currently benefit from getting Problem tickets passed to our higher level technical teams straight away bypassing the initial helpdesk/diagnostics phase of the incident management process and we have different systems of prioritisation for faults on services and faults on CI's. Generally speaking, most CI faults on our network will affect multiple services as well so we are populating impacted services on the Problem form and can send notifications directly to affected customers without needing an Incident for each one.

I'm concerned that our Incident form is going to become rather unwieldy if we try to accommodate everything on the Incident form whilst the Problem form will be sparsely populated and rarely used which seems like a waste.

[Michael Fry1]

Like most, we're following the ITIL framework. The goal of incident management is to resolve the issue as soon as possible. The goal of problem management is to identify what caused the incident(s), how can we prevent the issue in the future, what changes do we need to make so it doesn't happen again. If we have related incidents, we use Parent/Child to group them together. When the Parent resolves, so do the children. Most P1s require a Problem ticket. Great Problem Management can reduce the number of incidents.

Not all incidents go to Service Desk. Based on Category/Subcategory, they can route directly to the appropriate team. The incident form should be common across the platform, maybe with a few exceptions, but Related List can only appear when data exists.

[Dubz]

OK so from an ITIL perspective, a Problem is more of a retrospective look at Incidents once they have been resolved and an analysis of what went wrong and how to prevent recurrence?

We're going to have to give this more thought i think. I remain convinced that our business model benefits from having the current build but perhaps i'm being unduly swayed by the prospect of having to rebuild the entire platform from the ground up!