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

[Former Member]

Hi Faisal,

This should be a simple modification.  Within "Modify Task Settings" for the standard approval Stage, change "Approval Type" to "All Approvers" instead of "Any One Approver".  The result, all approvers must approve the request (in parallel) before the request advances past the stage.  You can do this for any type of workflow.

FYI you also need to click "Modify" (instead of Modify Task Settings) and make sure the change is found here too:

Regards,

Ken

[Former Member]

Thanks a lot Ken,

Have you ever tried this?  did it work? I was under the imprison that SAP delivered MSMP will not be modifiable.  I'll try it and let you know if that works.

Also I wanted ask you another question regarding MSMP workflow.  I'm also in process of configuring ARM the (Access request manager) but do not have solid grasp to configure  SAP_GRAC_ACCESS_REQUEST.  Is there lot of changes I have to do or just minor? Is there any step by step document out there I can use to configure my access request MSMP workflow . I know it is depend on my company requirement but just wanted to find out how to setup for two or three approvers and what  is the best practice around it..

Regards,

Faisal

[Former Member]

Faisal,

The modification I described above should work.  This modification isn't actually changing any standard delivered SAP content; rather it is modifying Stage Task settings, which are designed to be customizable.  I do not think there will be an issue with making this work.

The ARM configuration is a bit more complex.  I do not have any guides available to share with you, but I can give you some guidance.  What you really need is the GRC 10 training for Access Control, but to help you get started, keep these steps in mind:

Configuring ARM:

1. All SAP requests in ARM begin with an Initiator rule.  You can try leveraging the standard delivered rule, but I recommend creating one from scratch.  An initiator rule includes a decision table that reads Input and results in Output based on the criteria you configure.  A great starting point is to make an Initiator rule based on Request Type.  Then, you can create different workflow paths and approval stage requirements based on the Type of Request, ex New Account, Change Account, Firefighter, etc.
2. You must map your Initiator rule to MSMP in Step 2 (at the bottom, called Global Imitator rule).  Keep in mind that the Process ID you select in Step 1 of MSMP will directly relate to ALL other steps following.  For example, all settings in Steps 2-7 relate ONLY to the process ID that you select in Step 1 of MSMP.  The Initiator Rule's ID is not the Decision Table's rule ID; rather it is the "Function" ID # that you find in BRF+ under the application that you created.
3. For each Rule Result, you can map a workflow path in Step 6 of MSMP.  Here, you choose your initiator rule, the rule result, and then map to a path that you create.
4. Each path can have approval stages.  These stages have independent Task Settings and Notification Settings that can be configured for your business requirements.
5. ARM requires you to map Integration Scenarios and Logical Group scenarios in the IMG within tcode SPRO.  Much of the ARM configuration needs to be done from SPRO.
6. Standard delivered "Agents" will work fine for you.  Agents represent Approvers or Notification Rules.  Each stage needs an Agent to be mapped if approval is required.
7. You can find any errors in MSMP configuration in step 7 when you "Save and Simulate".  The simulation will call out the areas of MSMP that are not configured properly.

I hope this gets you started in the right direction.  ARM configuration can take 1 day if you know what you are doing, but it can also take months of trial and error if you are new to it. 

Message me directly and I can help you along the way.

-Ken

[Former Member]

Thank you so much Ken, it is really helpful, I'll let you know how it goes and get back to you if I have issue during the  process of configuring ARM.

Regards,

Faisal

[Former Member]

Hello Ken again,

I just tried the above changes and still Mitigating control doesn't take more than one approver, when I was setting up I assigned two approvers while I was trying to create control in Access risk tab, it says only one approver can be assigned to mitigating control.  any other suggestion or I'm not doing the right way.

Please let me know, thanks in advance

Regards,

Faisal