SAP GRC 10.0 on ECC

[Former Member]

Hi Guys,

We are planning on implementing SAP GRC 10.0. Our Basis guy has suggested that we can use ECC (EHP 6) box for installing the add on(GRCFND_A) component for it. The reason for this is to avoid adding another system to the landscape and to reduce the cost of implementation

Are there any known issues using this approach?

Thanks in advance,

Silver

[Former Member]

To give more insight about the scenario here, the GRC project is totally IT driven.

Business wants nothing to do with it. SODs are maintained through user_exits and will slowly be moved towards the GRC approach if Business decides so in future.

The key driver for the project is the ARM and the EAM module for helping IT Team to reduce workload through auto provisioning and keeping the logs intact.

So installing a new system means more infrastructure requirements, more workload on Basis which will delay the project further or which might also mean postponing it to next quarter which clearly IT does not want.

The userbase is fairly small and the upgrades are not frequent, the last upgrade happened four years back and so the next upgrade is not even in sight for 2 years.

[Former Member]

Silver Surfer wrote:


The userbase is fairly small and the upgrades are not frequent, the last upgrade happened four years back and so the next upgrade is not even in sight for 2 years.

Keep in mind that when any of the connected systems is upgraded, you might have to upgrade the GRC system, which might be more easily done with a standalone GRC. For example: our APO system is in process of being upgraded, and due to the NetWeaver release it will be on, we are going to have to take our GRC 10 from SP12 to SP14 in order for it to be compatible. We expect to have to upgrade GRC to another SP probably every year.

Gretchen

[Colleen]

Hi

the GRC project is totally IT driven.

I get why you are having to drive this - especially when you have to respond to audit requirements and your focus is on support processes.

However, GRC is all about business risk management - Governance, Risk and Compliance (well internal controls). The GRC System is just the tool to manage this. Without business buy in how is this going to be successful? Who will review business process to determine what a risk is? Who in a senior leadership position will determine what risks are acceptable? Who will determine appropriate controls, report on them, and more importantly enforce them? Who in a leadership position will champion the project and support why a user must work a certain why (including access removed from them)?

I get that you are focussing on a POC and trying to minimise cost but what happens post POC? I've given recommendations where I've said don't put in GRC until you sort your process and culture. I've done this as much as the innner techy in me knows I won't get to play with a new toy because without all the business buy-in you will have a system built and deployed that gives you a false sense of security when it comes to managing access controls.

Another way to look at the SP issues - what happens if it's on ECC and the functional team (aka the business representatives) demand an SP increase for their functionality? They proceed to increase SP and now your functionality stops working.. which then impacts the business as you can't process their access requests and give them timely access to the system (assume this is your business case). Are your basis team going to tell the business that they can't have the SP stack increase because IT needs the system on a certain level and they need to wait until next time it's compatible?

Good luck with your POC. I understand it will allow you to use the tool and check what will work for the business. If you are still undecided on system landscape post POC, take care in having that decision made for you. As you go down the POC path and time runs out the project may move from POC to design/build and now that it's working there will be reluctance to move it to a separate system.

Regards

Colleen

[Former Member]

Thanks Steve and Colleen,

The information provided is really helpful.

I have updated my Basis Team regarding the concerns that you highlighted here and suggested to have a new system for GRC.

However, we might do a POC in ECC Sandbox first to test if it runs smoothly as Basis is insisting on it. They feel they can wait for both ECC and GRC to be compatible on the same Netweaver version for doing the next upgrade.

So now for Sandbox, do we need to install plugins for GRC (GRCPINW and GRCPIERP) in ECC as now GRC and ECC are on the same box ?

My understanding is these plugins are only used for RFC connections/communications between the two systems so might not be needed here as GRC is just as addon in the same box

Thanks for all your help.

Silver

[Former Member]

Yes, you will still need to install the add-ons. GRC will be expecting to communicate via RFC, even if the target system is the same one.

 However, we might do a POC in ECC Sandbox first to test if it runs smoothly as Basis is insisting on it. They feel they can wait for both ECC and GRC to be compatible on the same Netweaver version for doing the next upgrade.

Basis may be prepared to wait. What if there's a business driver for an ERP or GRC upgrade? How happy will they be having to say to the business, "Sorry we can't give you the functionality in that ERP enhancement pack until there's also a new version of GRC?" Remember that a lot of the renewal activities are delivered in enhancement packs. I still think this is a really bad idea that you will ultimately regret...

Steve.

[Colleen]

Good summary - I am perplexed that basis are dictating the business requirement and disregarding the installation guides

[Former Member]

It is not by default a bad decision to install GRC on the ECC environment. However it is not a decision basis should make.

Did you identify all the risks that are involved not to install GRC on a separate environment? What are the cost of buying and installing additional hardware (for example 30k) etc. Are we talking LE or SME? You need to perform a good risk assessment involving all the stake holders.

Now if you are running a pilot on a sandbox or development system than choosing to install GRC on an existing environment may not be a bad call.

[Colleen]

Hi T

It is not by default a bad decision to install GRC on the ECC environment. However it is not a decision basis should make.

To an extent I agree with you - the decision should be about reviewing options and making a risk-based decision that the business can accept.

However, if a vendor-owned installation guide puts a warning/recommendation not to do this would you take that risk? If you raise a customer incident your issue may not be resolved if the vendor's recommendation conflicts with your ECC functionality.

I've already responded below - hearing the project is purely IT driven is going to cause issues beyond which system to use.

Regards

Colleen

[Colleen]

Your basis team missed SAP recommendation in the installation guide to keep GRC as own system

As Steve mentioned, support packs and upgrades will be a headache as they may have different basis stacks.

[Former Member]

Thanks Guys,

Lets say we keep this as a prerequisite for all future upgrades

a)checking GRC 10.0 compatibility with Netweaver version after upgrade

My questions are

1)Can we keep it on ECC?

2)How does applying support packages effect if it is already compatible with a lower support package level?

3)Could you please throw some light on the security risks as well?

Thanks again,

Silver

[Former Member]

The situation you need consider is what you'd do if you want to apply, say, EHP8 to ERP6 and that requires a NetWeaver upgrade - they usually do - but your GRC version isn't supported on that new NetWeaver version. So GRC is preventing you from applying EHP8. The reverse might be true if you want to upgrade GRC to 10.1 or 10.2 and the required NW release isn't compatible with your ERP/EHP combination.

I believe technically you can do it, but just to avoid a couple of extra servers you really wouldn't want to. You are just storing up difficulties for yourself in the future. Your Basis guy might think it is a good idea now, but he'll eventually come to regret it. And there's no standard way to split the two afterwards.

I'm not really sure there are any significant security concerns, are there?

Steve.

[Colleen]

Also check what licensing agreement with SAP for how they charge usage of GRC - May be non issue but still something to consider

security concerns unlikely unless activating sicf for NWBC - if wanting to keep systems isolated.

[Former Member]

I would seriously consider separate systems. Installing both GRC and ECC on the same NetWeaver system will make upgrades complicated. They will each have their own possibly different requirements for the NetWeaver stack. GRC on SolMan will have similar issues.

Steve.

[Former Member]

Apart from security issues, performance issues may occur as well.

If cost is the driver and after discussion the cost argument is still stronger than any other, then it would make better sense to install GRC on a SOLMAN environment (if possible) as most likely your ECC SAP system is your most critical system.