Many Greenfield SAP implementations will exclude SAP GRC from scope, treating it as an optional module that can easily be implemented post go-live. In this two part blog entry we explore how the deployment of the SAP GRC toolset at the outset of a Greenfield implementation can improve the effectiveness of internal controls in the long-run.
A conversation with one of our customers recently got me thinking about the way that most GRC projects are commissioned, and about how things could be different if a slightly more forward thinking approach was taken. This blog will explore, in two parts, how the deployment of the SAP GRC toolset at the outset of a Greenfield implementation can offer a significantly more effective implementation in the long-run. We start with SAP GRC Access Controls.
A GRC Access Controls project will typically be initiated for one of two reasons:
- In response to an audit report recommending improved controls.
- As a result of a process improvement initiative.
Unfortunately we still rarely see GRC as part of a Greenfield SAP deployment. GRC will often either be overlooked in scoping or become a casualty of tightening budgets at some stage of the project. This is a shame as there are a number of reasons why implementing GRC Access Controls at the outset of a project can be hugely beneficial.
A Compliant Role Design
Any implementation of SAP will require the implementation of SAP roles to support access control requirements and facilitate segregation of duties (SoD). Whilst SAP roles are often designed and built without a segregation of duties tool this approach will inevitably lead to some form of role remediation to align the SAP roles with an SoD ruleset. Even if SoD rules are not defined during the initial implementation a subsequent audit will almost always necessitate some form of remediation activity to achieve this.
By implementing the SoD monitoring tool (Access Risk Analysis) at the same time as the SAP roles it is possible to develop a role design that aligns with the SoD ruleset from the outset, avoiding this subsequent re-work and the associated costs and disruption to the business. This approach is also likely to result in a role design that is easier to maintain as, in the absence of a complete re-design, most post go-live role remediation projects will necessitate some compromise in role design.
A Complete Audit Trail from Day One
Although not widely used in pre-production systems the Emergency Access Management (EAM) module comes into it’s own in a project environment. There are a number of scenarios during a project where elevated access needs to be allocated in a controlled way and EAM is the ideal tool to achieve this. For example, during cut over it will often be necessary for project team members to execute business transactions as part of a data load. Similarly, fire fighting during the hypercare period immediately after go-live will often necessitate higher access privileges than a ‘normal’ business as usual support environment. Making the EAM module available to the project team is an excellent way to provision this elevated access in a controlled way and it will also ensure that an audit trail of high privileged access is available from day one.
Modern Access Control Processes
A Greenfield SAP implementation will most likely require some changes to the IT support model in order to provide an adequate run and maintain environment post go-live. User Access Management processes will vary significantly if an SoD tool is in scope as these processes will need to incorporate SoD analysis. Today’s GRC applications also enable automated provisioning which will further change the UAM process. By deploying these tools into the Greenfield implementation it is possible to design UAM processes that incorporate the most effective use of the GRC tools available from the outset. This will not only save money but will also avoid some of the challenges that many GRC implementations face in failing to secure sufficient business engagement to make best use of the GRC tools.
Conclusion
Many Greenfield SAP implementations will exclude SAP GRC from scope, treating it as an optional module that can easily be implemented post go-live. Clearly this over simplifies things. My hope is that readers of this blog entry will challenge the assertion that the deployment is of GRC is not part of the initial project scope and will argue that GRC should be treated as part of the core solution infrastructure in a similar way to solution manager. After all, why wait until your first audit to be told that you should have included it?
