Incident follow-up transactions & SLA / ITIL?

[vervinckt_joyca]

Dear experts,

I have a question concerning SolMan's handling of Incident follow-up transactions, and how its SLA react to it.

From an incident, you can create a follow-up problem, or even a request for change.

However, by doing this follow-up, the incident stays in status "In Process".

Only when you close an incident or request for change, in standard customizing it is foreseen that a feedback is triggered to the incident. For example, SMCR's status E0006 "Confirmed" has in the customizing "Specify Status Settings for Predecessor Documents" an entry for SMIN E0008 "Confirmed".

This implies that the whole time that your Request for Change is open, the SLA on your incident keeps counting...

ITIL-wise, this does not seem correct to me.

On the other hand, if you decide to close your incident (manually) when you create a Request for Change, you are getting an error when you try to confirm the Request for Change: "The status of the previous document cannot be changed" because it is trying to confirm the already confirmed incident.

What would be a good way to handle this situation?

Kind regards,

Joyca

[vervinckt_joyca · Accepted solution]

No one who has an idea?

[Former Member · Accepted solution]

This message was moderated.

[patricio_mansillacaro · Accepted solution]

Hello Joyca,

I can give you my personal ideas on this:

- first of all, to me, SLA must represents always the final user point of view, so, if there is no solution and the incident is open while the Change Request is open too, then I think it is correct that the SLA keeps counting

- So, if you can talk to the final user and explain the situation, the incident could be closed and the Change Request can be open manually

I think that should be the most correct options

Kind regards

Patricio

[former_member187281 · Accepted solution]

Hi Joyca:

We are facing the same issue today. Well, we already faced that issue long time ago and we are trying to resolve it, because closing projects has become a nightmare due to many RfC not able to be confirmed due to parent incidents and service requests already confirmed.

Have you found a solution?  We thought the "specify required status values for successor" was going to control that [we could not confirm the incident unless its child RfCc was already confirmed], but it did not work that way.  It really works similar to what "specify status setting for predecessor document", although the latter is done from the child's document configuration, whereas the former is the same but from the parent's stand point.

Thanks for any input.   We are tempted on adding some workflow to the picture, if there is no configuration available for that.

Juan Carlos

.

[vervinckt_joyca · Accepted solution]

Hi Juan Carlos,

The only thing that I have been able to do, is to avoid the error message.

In the SPRO activity "Make Settings for Change Transaction Types", for your Req. for Change transaction type (e.g. ZMCR), in the activity "Assign Consistency Checks":

There is an entry for consistency check "PREDOC_CAN_BE_SET" which triggers on E0005 (Implemented) and on E0006 (Confirmed)

Standard its message type is "Cancel", but you can set this to "Warning" or delete the whole line.

This consistency check is responsible for setting that error message "the status of the previous document cannot be changed".

Hope it helps,

Kind regards,

Joyca

[former_member187281 · Accepted solution]

Thanks Joyca.   Really appreciated.  I can see the pain you may have gone through and the frustration.

I will try to test something Michael Vollmer mentioned in

However based on that approach, moving incidents from directly changing status to ChaRM framework to use actions to then be able to get advantage of SET_PREDOC functionality, which once in place may resolve our issue, seems like a lot of work to me for the final benefit.

Part was done.  The new challenge is to add Action button to the menu, as is not there in incidents, hence it needs to be incorporated.

We will see if time permits to try to proof that at least it works, but the I know we will go with your solution.

Have a good day,

Juan Carlos

PS.  If we have the time to do it over here and it works, we will post something here.

[former_member187281 · Accepted solution]

Hi Joyca:

Last week SAP released note 2191039 which resolves our problems in the sense that the ABAP code of the method they modified, checks if the predecessor is in status 'FINI'.  If it is, the code does not bother on checking more and conditions become true.  That is more or less.

https://websmp230.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/sno/ui_entry/entry.htm?param=69765F6D6F6465...

We tried today and it works as expected.

Many thanks specially to Michael Vollmer.   I am just impress about the care from SAP.

Regards,

Juan