Best practices for ARM - please help!!!

[former_member356668]

Hi all,

Can you please help with any pointers / links to documents describing best practices for "who should be creating" the GRC request in below workflow of ARM in GRC 10.0??

Create GRC request -> role approver -> risk manager -> security team

options are : end user / Manager / Functional super users / security team.

End user and manager not possible- we can not train so many people. Functional team is refusing since its a lot of work. Please help me with pointers to any best practices documents.

Thanks!!!!

[Former Member · Accepted solution]

Pooja,

I very much doubt that you will find a best practices document that will give you an answer. I have done Access Request Management implementations at three organizations, and each one of them handled the request process differently. The best process is the one that works for your organization. You say that you cannot train so many people, so the end user and the manager are not possible. I get that, that is the thinking at my current organization, so there are designated key users at each plant or each department of major property locations. who were trained on the new request process. To be honest, some of them are doing well, and others not so well yet.  Some organizations train the IT Help Desk to submit the requests; that is usually not so many people to train.  Another one of the ARM implementations I did also implemented Business Roles, to make it easier for the managers to figure out what to request, and managers submit their own requests there. You may need to think about a security rewrite and/or Business Roles implementation to make it easier. Submitting the request form is not really difficult, especially if you use EUP templates to customize the screen a bit to your process.  The bottom line is that there is no "one size fits all" right answer. This is why clients should bring in experienced consultants who have done this numerous times, to advise based on what they have seen other clients do successfully. If your consultant is not experienced enough to advise you, you may need to find one more qualified. Good luck!

Regards,

Gretchen

[former_member356668 · Accepted solution]

Thanks a lot Gretchen for your reply!

I agree with all your points - thanks for providing different options possible.

Currently it has come to a point where - Either security team ( that's us - just 5 people) or Functional superusers will create the request. But since its a lot of added time no one wants to own the responsibility and we are searching for documentation to prove to higher management who is the better party to do it.

So i gather SAP does not have recommendation on this part. That's unfortunate. Appreciate your response though! Thank you. 

[former_member356668 · Accepted solution]

1. Also, we are working on creating Business role, that really seems like a much elegant option. We have not implemented the BRM module though. So facing a few technical difficulties there.

2.  EUP templates - I was not aware of this option. Let me find more info on this one. Thanks!!

[former_member185447 · Accepted solution]

Hello Pooja,

What  does this mean?

Also, we are working on creating Business role, that really seems like a much elegant option.

As far as EUP Templates are concerned, go through this link which will give you a fair idea about templates.

Regards,

Deepak M

[former_member356668 · Accepted solution]

Thanks Deepak, I came across the document in one of the blogs its useful.

We are working on Business role implementation - it will allow to create a role say - Sale Representative and under that you can assign a number of security single roles. So looking at someone position title etc. one can easily request what security role is needed.

[Former Member]

In my extensive experience, GRC AC 10 is not business-user friendly.  The technical roles aren't very easy for someone from the business to understand (until you roll out Business Roles).

Therefore, I always view the AR process as starting with the SAP Support team.  The SAP team will interpret the original Service ticket which explains who needs access and why.  Then, the SAP team (already trained on creating ARs in GRC 10) will select the roles that they deem to be appropriate.

-Ken

[former_member356668]

thanks Ken. "GRC AC 10 is not business-user friendly - until you roll out Business Roles", I very much agree!

[Former Member]

I recommend creating an "SAP Access Request Form" that you can integrate into your Service Ticketing system.  This form should gather basic user data required to create an SAP account (name, email, user ID, manager, job description, function, department, responsibilities, company codes that the user will be working with).  The managers or end users can fill this out to the best of their ability.  This form then get's sent to the SAP Support team through the main Ticketing system.  It is the job of the SAP Support team to determine which technical roles should be requested, and they can cross check with the user's manager to determine the access needed.  Then the team creates the GRC AR request.

[former_member356668]

hi Ken,

Thanks for your reply. Our current service ticketing system gathers all the mentioned data already but being a team of just 5 people entering all that data into access request in GRC every time is the problem since it is cumbersome and we are trying to solve that. we have a very high volume of service tickets and a huge user base.

[Former Member]

In this case, I recommend proposing that the department managers create GRC Access Requests.  In order for the managers to comprehend the new process, you should create a separate "Role Catalog" that describes what abilities each role enables.  This Role Catalog needs to be taught to the department Managers, and they need to fully understand what tcodes and abilities are inside of each role.  From your workflow design, it looks like Role Owners should be brought into these workshops.

You might consider a Role Catalog that the manager could filter on and make selections from.  For example, an AP manager could select "Accounts Payable" roles, and then choose from a smaller list of AP-related roles.  You could map business functions or tasks to specific technical roles.  The design flaw here, of course, is the way your technical roles have been designed.

The point being, GRC AC 10 is not business-user friendly, so using an intuitive "Role Catalog" really helps the managers understand which technical roles they should be selecting in GRC ARs.  They can use this catalog to spit out a list of technical role names that they can then search for within the GRC Access Request.

At all costs, avoid having end-users create ARs.  They usually select the wrong access, and the process then becomes very long and drawn out because the role owners or security stages need to mix and match the access after the fact.  You should choose a Requestor who has the highest chance of requesting the correct access.  This is usually the user's Manager, but you need to propose this solution in a way that won't scare off the manager - at the end of the day, they do NOT want to take on more work.

If you are using SAP HR, then you can attempt HR Triggers for New User Access Requests, which automatically fill out and submit the GRC AR upon a specific HR action (New Hire, or Termination).  I do not recommend going down this path, however.  It is very confusing, time consuming, and difficult to integrate properly.

Good luck!

-Ken

[pawan_amarnani]

Hi Pooja,

Could you please share your BRM implementation document?

I am currently working on ARM implementation. BRM is not the business requirement at present because of no role owner.

I want default roles to be added while creating access request.  Do i need to implement BRM for assigning default roles to access request?

EUP Template is for differentiating the two request type & pre-defining the access request values  where you can customized the request form according to your need.like for new account different field settings and for user change, unlock different field settings. you can also pre-define the many fields, back end system, role for which user wants to access. easy and fast approach for user training, also reducing system load.

thanks,

Pavan

[former_member356668]

Hi Pavan,

We have not looked in EUP so much at this point. Thats plan B. Thank you for providing info on that.

For BRM - This is one helpful document.

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/80063a8e-1da6-2e10-aaa5-fda1f0936...

I did not understand this - "BRM is not the business requirement at present because of no role owner." What do you mean by - no role owner?