Promoting an incident to P1 or P2 assigns the ticket to the Major Incident Management Group

[IanW27934052924]

When we promote an incident ticket to a Major Incident it auto assigns it to the Major Incident Management Group. (MIMG). 

This causes us a problem when it comes to reporting on resolver group for Major Incidents as the vast majority of MIs will sit in the MIMG queue instead of the queue that resolved those incidents. 

Should we switch off auto assignment of promoted incidents to the MIMG?

[IanW27934052924]

Unfortunately you haven't understood my issue. 

(By the way I am ITIL trained). 

MIMG - we only have one MIM team. This is the process owner for MIM - the process owner for MIM does not resolve the incident. 

This means when the incident it promoted to a Major Incident and gets assigned to MIMG, it is getting assigned to a group that does not resolve the incident. 

When I then do my reporting - for example looking at Major Incidents over 12 months by Resolver Group. It shows me the MIMG group with lots of tickets assigned to it. 

The answer apparently is for MIMG to manually assign back to the resolver group but I find that solution lame. Why should we have a manual step to assign back to resolver group in order to report on who resolved the issue. 

As MIMG isn't a resolver group but a management group the ticket should not be assigned to MIMG. It's becomes an admin burden with inefficient manual intervention. 

This is my issue. 

[Dr Atul G- LNG]

Hi @IanW27934052924 

I respect your experience and knowledge, and I’m glad we’re having a constructive discussion.

MIMG - we only have one MIM team. This is the process owner for MIM - the process owner for MIM does not resolve the incident. 

This means when the incident it promoted to a Major Incident and gets assigned to MIMG, it is getting assigned to a group that does not resolve the incident. 

Atul:  “I agree, MIMG is not a resolver group. If that’s the case, then why would you want to assign the incident to MIMG if it isn’t resolved? We assign tickets only to the teams responsible for resolving them.

When I then do my reporting - for example looking at Major Incidents over 12 months by Resolver Group. It shows me the MIMG group with lots of tickets assigned to it. 

The answer apparently is for MIMG to manually assign back to the resolver group but I find that solution lame. Why should we have a manual step to assign back to resolver group in order to report on who resolved the issue. 

Atul:

The solution is not weak. Let’s take an example: as per my earlier statement, if MIMG is not going to resolve the incident, then it should not be assigned to the MIMG group. If it is assigned, both your SLA and reporting will be impacted. Alternatively, you could create a rule or job to reassign the incident back to the resolver group once the state is marked as ‘Resolved,’ but in that case, all SLA work and mappings would still appear under the MIMG group.

So technically, the process needs to be corrected. MIMG is a process group that oversees the call process, not the ground-level resolution. Therefore, please adjust accordingly as per the earlier response and keep MIMG out of the ticket assignment.

[IanW27934052924]

Hi,

You ask me why it's assigned to MIM: 

Atul:  “I agree, MIMG is not a resolver group. If that’s the case, then why would you want to assign the incident to MIMG if it isn’t resolved? We assign tickets only to the teams responsible for resolving them.

But also you have told me that the assigning to MIMG is the Out of the Box Functionality of the tool? 

Now I am confused. 

[IanW27934052924]

manual reassignment by MIM is not ideal. But I take your point. 

[IanW27934052924]

the MIMG is not a resolver group. It's a management group - the incident do not need to sit in the MIMG group - the MIM process can happen outside of that.  and so manually having to reassign to the correct resolver group is an overhead that is troublesome.