With the go-live of our Governance, Risk, and Compliance (GRC) version 10 Access Control finally past us (hallelujah!), I have been thinking about the learnings, from my previous GRC 10 projects as well as from this one. Last year at SAP TechEd, I hosted an Expert Networking session , discussed
hereThe rest of the story: what else I learned at #SAPTechEd , where the most common response to my question about GRC 10 was that customers were still thinking about it. Maybe you, too, are still thinking about it, working on a roadmap, or planning your project. Even if your project is already underway, here are some readiness questions to consider.
What are the pain points of your current GRC related processes?
Be sure to get input from your key users. Pain points could include these:
- Too many manual hand-offs in the access request process
- User access reviews tedious due to manual processes, and not particularly value added besides
- User interfaces for access requests confusing to requesters and approvers
- Confusing/ inconsistent role names making it difficult to know what role to request
- Roles not well aligned with either tasks or jobs, leading to a need to make a big security change, such as complete security rewrite or implementation of Business Roles
- Manual security team processes like maintaining organizational segregation with manual reviews and hit or miss efforts to manage critical sensitive authorizations
- Confusing/ inadequate information in firefighter logs, so they are not reviewed timely
What is your long range plan?
If yours will be a brand new GRC implementation, do you have a company policy for Segregation of Duties and critical access rules that can be the basis of your new GRC rule sets, are you planning to start with the rules out of the box, or will you take the time to customize them? If you are on GRC 5.3 (or earlier release), have you been maintaining your ruleset all along with the updates from SAP and custom transactions? A “lift and shift” of your current rules can be fine if they have been maintained; otherwise, it is like bringing dirty, threadbare rugs from your old house into your brand new one. The sooner you get them cleaned up, the better.
Have you thought about your long term roadmap and identified which components you plan to implement? Some customers start out by just implementing Access Risk Analysis, to get the system up and running, and then take on Access Requests and more later. With all the shared master data across Access Control and Process Control, decisions you make early on could come back to haunt you later down the road. If you are planning to use your current GRC system as the model for the new one, has all the master data been maintained, or are there obsolete mitigation monitors who have left the organization, mitigations configured for risks that do not exist, and other bad data that will not work in the new, better integrated, system? It can be a real challenge if you have no “golden” client to use to validate the configuration of the new one.
Do you have the right resources for your project and enough of them?
Colleen Lee wrote an excellent blog about all the friends who helped her on her own GRC projects.
Depending on which components you plan to implement and the architecture, the resources needed for your project could include some who may not have come to mind. Of course you will need security, GRC, and Basis expertise, but you may also need LDAP expertise if your user master data resides there, or HR expertise if you plan to use your SAP HR as the user data source and/or implement HR triggers. But are all your users, including contractors, even in SAP HR? Are you sure? If you plan to use your LDAP, has it been properly maintained, or does it need clean up before you can rely on the data fetched? For implementing Access Request Management, workflow expertise including MSMP and BRF+ is a must , and if an Identity Management system performs your user creation, count those experts in, too. How will the users access your system - Enterprise Portal, NWBC, something else? Whatever you plan to utilize, be sure to budget for skilled resources on your project team for that, too. If a new rule set is needed, expertise from the business and internal controls will be key.
Then there are the ABAP resources. As I mentioned in a comment on Colleen’s blog, on my current project we badly underestimated the demands we would make on ABAP resources, needed for implementing the hundreds of corrections into our system. Better to budget for them and not need them than be wishing you had the funds.
And about those hundreds of corrections: someone needs to stay on top of those issues. If the people managing the fixes and corrections are also project managers, and also doing system configuration, configuring the workflows, migrating master data from the old GRC system, creating documentation, designing testing and training, and leading the change management effort – well, good luck with that. Yes, two resources can wear 8 or 10 different hats, but your project timeline will need to be adjusted accordingly. If your project management tool tells you that your project’s resources are way over committed, a six month project could run on with slipped deadlines and missed go lives, possibly impacting other projects that they were expected to be working.
On top of that, the longer your GRC project drags on, the likelier that the systems connected to your GRC will be upgrading. If a connected sytem goes to a new NetWeaver release, you may have to install new plug-ins and start testing all over again.
I hope I have provided some food for thought for anyone considering or planning an implementation of GRC 10. Time spent now in considering these questions will pay off in the long run.
