There are several workflows that this tool provides.

Some of these are standard and cannot be changed, while others leave ample room for customization.

What are the points of attention when deciding which steps and how many to include in various workflows?

We will discuss about them in this article.

What are the standard SAP GRC Access Control workflows?

Through the MSMP Multi Stage Multi Path configuration transaction (Maintain MSMP Workflows) it is possible to access the configuration of all workflows in SAP GRC Access Control, these being:

• SAP_GRAC_ACCESS_REQUEST
  • It represents the main workflow used in the Access Request Management (ARQ) module of SAP GRC. It allows managing all approval steps during the creation, modification, deletion of one or more SAP users.
• SAP_GRAC_ACCESS_REQUEST_HR
  • As above but in this case the organizational structure is used to assign roles to positions.
• SAP_GRAC_CONTROL_ASGN
  • This workflow allows managing the control owner's approvals of mitigating controls while assigning them to users and roles.
• SAP_GRAC_CONTROL_MAINT
  • This workflow allows control owner approvals of mitigating controls to be managed, to define new controls
• SAP_GRAC_FFID_REVIEW
  • Allows re-validation of links between super-users and assigned users, using the Emergency Access Management component
• SAP_GRAC_FIREFIGHT_LOG_REPORT
  • Allows an approval to be made by the superuser owner of the logs produced by the superusers (Firefighter) referred to him, using the Emergency Access Management component
• SAP_GRAC_FUNC_APPR
  • Allows you to make function change approvals (of the SoD risk matrix), using the Access Risk Analysis component
• SAP_GRAC_RISK_APPR
  • Allows you to make risk change approvals (of the SoD risk matrix), using the Access Risk Analysis component
• SAP_GRAC_ROLE_APPR
  • Allows you to make approvals when creating or editing roles (using the Business Role Management component)
• SAP_GRAC_SOD_RISK_REVIEW
  • Allows re-validation of SoD risks present on each Risk Owner
• SAP_GRAC_USER_ACCESS_REVIEW
  • Allows re-validation of the user/role link for each Role Owner or Manager

Access Request Workflow how many approval steps?

Certainly the most customizable workflow or Process ID is that of Access Requests.
This workflow makes it possible to define, in cases where users are created or modified, the approval steps that the request must undergo.

There is a standard workflow that involves the following three approval steps:

• Manager
• Role Owner
• Security

This is an off-the-shelf basis that is well suited to all companies. Assuming that it is possible to have Managers read the SAP GRC system (from LDAP or HR) and that relevant Role Owners are defined for each role, an essential figure for these kinds of processes.

Each step in the workflow can be further customized in terms of user interface.

In fact, there is a feature called EUP (End User Personalization) that allows defining which fields are visible/editable for each approver.

For example, the Manager will only be able to see strictly necessary fields, while the last actor in the workflow, Security will also see more technical fields, for example.

What considerations can be taken into account? What are the points of attention?

1. Do not define too many approval steps. Often requests, even with minimal approval steps, take several days to be approved. Increasing the number of approvers can make requests much longer in terms of time.
2. Identify clearly the responsibilities of who does what and in what way. Especially in the case of Owners (Risk, Manager, perhaps this is the easiest owner to identify, and Role Owner) read more here. This can represent one of the biggest difficulties.
3. Consider introducing a figure to control SoD in a preventive manner (in case there is at least one active SoD risk, then the workitem will go to a figure)

When to evaluate workflow management, though?

Although the Access Request Management module can be activated at any time, it is useful to remember some important aspects in my opinion.

• The introduction of this component involves the activation of approval workflows. If a formal request management tool did not already exist in your organization, it can be experienced as lengthening in terms of the time it takes to make changes or create users. Get used to having approval processes (even via e-mail) before the introduction of the tool.
• Who should open the requests? All users in the company or just a few "focal points"? In my opinion, the second option is definitely the best in order to avoid training anyone and to have a first filter to the creation of requests.
• How important, for those who choose, is the readability of the roles loaded into the tool? It is crucial; if those who have to create requests do not know which roles to choose, it becomes an almost useless tool or one that generates "troubles" without producing benefits, since IT will always be involved to explain or interpret the requests. The introduction of these tools may involve revising the authorization model currently defined in the company.

Topics: SAP GRC, sap workflow