Major Incident Process

[steck24_00]

How do you do a major incident in Service-Now? Would anyone be willing to share their thoughts and experiences?

[gaidem]

On the process side, I frankly don't have the time to write anything on this right now.

On the technical side, it will depend on what your process dictates. You may chose to simply use a business rule with a condition set to your major incident specifications. Or use a workflow.

[troyp]

Did you implement your major incident process in SN?

I'd love to hear what you decided to do.

[Mike Malcangio]

I've seen this done a few different ways in the tool -- as Matt alluded too -- it's really dependent on your process.

I will say this -- ITIL v3 -- isn't very prescriptive in this case. It says there should be a major incident process; it doesn't really specify what that should be. This leads to all kinds of religious arguments (go search for the same topic on LinkedIn) about the process and thus different implementations in the product. I think it speaks strongly about the flexibility of the tool that it will support whatever you would like to do.

The two major camps:

Major Incident is a "kind" of incident. Perhaps it's when the urgency and impact are both set to High and therefore you have a 'Critical' incident. You may then kick in emails to certain teams based on it being a "critical" incident and have different SLAs for it, etc. In the background, you may have a crisis communication plan.

This naturally leads to another question, and the genesis of the second camp -- if the "major incident" is affecting multiple customers -- how do I capture that in the tool?

To tackle this some folks create a new task type called "major incident" and then build a parent child relationship between major incidents and "plain old" incidents. This allows them to group and collect the incidents and then close and notify in mass. The nice thing about this approach is it affords you a lot of easy customization opportunities for how you handle "major incidents" vs. "plain old" incidents.

Other folks, rather than build a separate task type, leverage Problem for the same function. The argument being that most of the functionality all ready exists to do this in problem (associating multiple incidents to a single problem) and 99% of the time you're going to create a problem to get to the root cause of the major incident anyway. Might as well just build crisis handling into the problem workflow and then once the fire is out, let the problem proceed down the normal path of digging into the root cause of the problem.

The objection to the latter is that incident and problem processes have competing goals. The incident process wants to restore service as quickly as possible; the problem process wants to resolve the root cause of the issue so it never happens again. By placing an aspect of incident in the problem space you're running against the goals of the process.

As I said -- neither is really wrong -- ITIL is vague in what it tells you to do and the system will allow you to do either.

Regards,

Mike Malcangio, Customer Success Manager | ServiceNow

[abhijats]

I have implemented Major Incident without approaching Problem Management, Provided the button to service desk agent on priority P1 to propose the incident as major then some specific fields get populated in different form section.
The service desk agent has to specify the major incident manager name to whom the notification will go and then he would be able to validate that incident as major.
Once the Incident becomes Major some tasks related to major incident will be created and team will work accordingly after the tasks get completed the normal resolution process comes in picture.

This is how I have seen Major Incident Flow.