Multiple Approver for Mitigation control

[Former Member]

Dear experts,

I know in GRC 10, there is only one approver for mitigation control and multiple monitors and this is the standard functionality.  I wanted to know if anyone know how to modify this MSMP workflow for mitigating control to have multiple approvers.

Is this possible?  can we make changes in SAP delivered  workflow to make custom stages to have multiple approvers for each control. Thanks in advance.

Regards,

Faisal

[Former Member]

Hi Faisal,

you had asked for Multiple approvers for Mit. Control.So, you need to configure that in Setup-Mitigation Control, and not in MSMP workflow. Then, Workflow will go to all the approvers, assigned to the Mit. Control.

'All Approvers' and 'Any One approver', in Task Settings, will not forward workflow to multiple approvers, only if Mit. Control, has multiple approvers, assigned to it, already.

Any One approver will also forward the request to all approvers. However, workflow will move to the the next Stage, if the stage is approved by, any one of the approvers. Incase of all approvers, workflow will not move to next stage, unless all approvers have approvrd

regards

Plaban

[Former Member]

Hi Plaban,

You can't setup multiple approver in MIT. control until I follow the Ken's steps and change the MSMP workflow because I try that and put more than one approver while setting up MIT. control.  It's only allow to have one approver.

Regards,

Faisal

[Former Member]

Faisal,

I apologize for recommending that particular solution, as it seems it is not possible to assign more than one "approver" for MC.  You can, comparatively, assign multiple "Monitors", which is why I thought this was possible.

According to this thread, it is not possible:

http://scn.sap.com/thread/3533300

However, depending on your requirements we might be able to make this work using MSMP modification.  First question: how many different people are going to be MC Approvers?  My thoughts on a possible strategy are this:

1. every MC will have 1 primary approver, who will approve in the first default stage.  This primary approver is specific to a MC(s)
2. second approval stage: We can create a custom agent which will allow us to assign secondary approvers, but this will be a static list of user and they will not be specifically assign to a control.  Rather, they will be a group of approvers that will all receive EVERY MC Assignment request, which will require a single approval from one of those people, or we can include ALL APPROVERs as a requirement for this second stage.

Help me understand why multiple MC Assignment approvers are required.  Sometimes, it is best to re-think the business requirement and guide the business to a more effective solution.  What exactly was discussed and what was promised?  If a secondary approver is a single person (ideal), then this is a very simple modification that I can help you through.

-Ken

[Former Member]

Ok, Ken; I already seen the thread regarding not possible in past  but still I wanted to through this question out there.

The issue is my IC team is using some other kind of form in SharePoint to (risk acceptant form)and they are not using mitigating control in GRC at this time.  The form they are using it has a workflow that sends an email to each approvers and they have 4 approvers.  manager, then sox controller, then controller and the head of the controller.

I'm purposing to use mitigating control in GRC rather than SharePoint where put lot of effort to extract all risks out from the GRC and give it to SharePoint team to implement

I wanted to make my case solid to present this proposal if I can meet their existing process in MIT control in GRC they might convene because there are already some concerns I have for example when you create MIT C. the workflow doesn't send an email, it just sent message to the GRC owner/approver in their inbox to approve or assign MIT C. to users. which is also weak because they are receiving email in current process

I wanted to meet their existing requirement to at least look at MIT C. in GRC. I would like to introduce the MIT C in GRC rather than using this web form that has workflow.

Let me know what you think if I have solid case to convenes them.

Regards,

Faisal

[Former Member]

A few thoughts:

1. Anytime you want a user's Manager to approve or be notified from GRC, the manager MUST have a GRC account.  This can be a deal-breaker if your Org has thousands of Managers.  Therefore, we can say that Manager approval within GRC is probably not a good idea - rather you can keep the SharePoint process or ticketing system to capture manager approval.
2. Standard MSMP for MC Maintenance or Assignment workflow only contains 1 Agent for approval (see step 3 of MSMP for these process IDs).  Therefore, if we want to include additional approvers other than MC Approver or MC Assignment approver, we will need to customize.  This isn't especially difficult for SOX Controller, Controller, and Head of Controller, as we can create custom approver Agents and map users directly to each of them.  However, the approval time will increase with each additional approval, so SharePoint is probably still the most efficient solution for capturing approvals.

I recommend using a combination of SharePoint and GRC as a solution, and leaving all approvals outside of GRC:

1. Approvals are captured in SharePoint from all stakeholders.
2. A single power user in GRC is responsible for being the "Approver" for ALL MCs.  This use will be a placeholder/administrator for technical configuration of controls in GRC.  This person does not take action until approvals have been captured.  This person simply makes sure the MCs are configured properly in order to assign within ARA reports and within ARM requests.
3. GRC MCs are useful for mitigating risks in ARA reports.  Therefore, as long as each control has an Approver and Monitor, you can run ARA reports and mitigate the risks for users directly in GRC.  Then, next time you run the report it will show that the risks have been mitigated.
4. MC Monitors should be business users who have relevant functionality for the control.  For example, in my organization the MC Monitor is the Financial Controller for all Finance-related MCs.  The technical SAP manager is MC Monitor for all Basis/Security related MCs.

It is also possible to turn off workflow entirely for MC Maintenance and Assignment.  These are "workflow" parameters within Maintain Configuration Settings in GRC IMG - param 1061 and 1062.  If you choose to select "NO" for these parameters, any ARM requests that need MCs assigned will not need to go for approval in order to assign the MC.  To compensate for the lack of approval, you can report on MC assignment periodically and review with the stakeholders, which saves time and makes ARM requests more efficient (lower number of approvals needed while still remaining compliant).

Hopefully some of these points will help you determine the best solution for your Org.

-Ken

[Former Member]

Ken Golden wrote:

A few thoughts:

Anytime you want a user's Manager to approve or be notified from GRC, the manager MUST have a GRC account.  This can be a deal-breaker if your Org has thousands of Managers.  Therefore, we can say that Manager approval within GRC is probably not a good idea - rather you can keep the SharePoint process or ticketing system to capture manager approval.

We automated the creation of accounts in the GRC system for managers and it works fairly well. Whether your user data source is your HR system or your LDAP, managers are identified somehow.  I suggest that you consider it so that requiring manager approval is not necessarily a deal breaker. Taking manager approval offline is the kind of kink in the process that the GRC system was supposed to help eliminate. Automating the manager approval is one of the things that our requesters really enjoyed about our GRC 10 workflow.

Regards,

Gretchen

[Former Member]

Gretchen,

I am quite interested in how you automated the creation of accounts for managers in a compliant manner.  Without getting too specific, can you give us a high level overview of how you made this work?

Thanks,

Ken

[Former Member]

Ken,

Our IdM solution creates our SAP user IDs, and it gets user attributes from SAP HR, one of which identifies which IDs have employees that directly report to them. By my recollection it did not require extraordinary effort for them to set up a daily job that recognizes when there is a new such relationship, check to see if that manager already had an ID in the GRC system, and if not, create it, put it in the correct LDAP group, and assign it the access needed by manager approvers. I am not an IdM expert, but that it the process at a high level.

Regards,

Gretchen

[Former Member]

Thank you Ken for detail tips.

Regards,

Faisal