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]

You've got some great partners over there, ask one of them for ideas at the next SNUG, NOWevent, etc.

Good luck!

[Ulrich Jugl]

Dave, I agree to what Michael is saying. If you want to follow ITIL standards, I would change your current logic to always create incidents instead of problems. You can also route the CI incidents directly to your groups with Assignment rules easily. Depending on the amount of work you have done in your problem process, it might not be a so big deal to move to the incident process and use the processes individually to what they are supposed to do.

[olufemi-richard]

While I agree with Michael, I will recommend that your team establishes the right process framework from ITIL perspective before you embark on how to drive the solution on ServiceNow platform. Hence, faults on CIs should be first treated as an incident. An incident does not have to be recurring or random before it becomes a problem. As long as you believe it is necessary to perform RCA, then a problem record can be opened while a change ticket will be created to fix the issue. You can equally tie your incidents with problem ticket through the related list and or related records tab.

To be proactive for future recurring incidents that lead to problem, I will also recommend that you build knowledge base articles for issues you have resolved in the past or currently so that when they reoccur, you apply the KB articles to resolve them without the need to put yourself in a reactive mode.

I don't know the ServiceNow version you are in but if you are on Jakarta, it comes with operational intelligence that utilizes analytics to proactively identify anomalies in your IT landscape. So by identifying this anomaly before the event occurs, it allows the IT teams to take actions and prevent the issues.  

Does this help in anyway?

[Dubz]

Thanks for your input on this guys. It's given me a lot to think about!

It would have been really helpful if you all could have responded with 'yes David, your way is the best way' but i suppose arguing for best practice and ITIL standards is a good second best!

Thanks again and enjoy your days ahead.