Skip to Content

If I had it to do all over: looking back on GRC 10 projects

If you attended Alan Jackson’s performance at the 2013 ASUG/ SAPPHIRE Now Celebration Night, or if you are a fan of his, you might be familiar with his hit ballad “I’d love you all over again.”

Now that we have gone live with our Governance, Risk and Compliance (GRC) 10 system, I thought I might look back over several years of such projects to ask myself, if I had it to do all over, which choices would I love all over again.


Pilot or big bang?
One choice, to do an Access Control pilot, was the option selected by one of my previous GRC 10 projects. It allowed us to get the system configured, build the Business Roles, and do a pilot of the custom request workflows, in a few short months. The downside to that choice is that everyone else stayed on the 5.3 system, so both systems had to be maintained, and presumably audited, until all the business units were brought onboard the 10.0. It was a trade-off, but they were willing to make that choice.


On the other hand, my recent project took the “big bang” approach, bringing all the systems connected to our 5.3 GRC over and going live with everyone at once. The upside was that we were able to shut down our 5.3 system soon after the go-live, reducing the dual maintenance period. The downside was that testing identified many issues, particularly with provisioning to the SAP Portal, many corrections were implemented, one connection never did work and had to be taken out of scope, and it all took much longer than planned. Now, just a few weeks after go-live, we are already living on borrowed time: the APO system was upgraded to a NetWeaver release requiring a plug-in higher than our SP level. Everything is working for now, but sooner or later, another connected system upgrade will force us to upgrade, too.


Business roles or technical roles?


The GRC 10 project I was on back in early 2012 included implementation of Business Role Management (BRM), and I blogged about that here. BRM was, unfortunately, still pretty buggy back then. I think it was a good choice given their technical role design and their access request process, but waiting for a later support pack might have made it easier.


In that client’s process, anyone could submit an access request; in contrast, the process at my current organization has access requests submitted by key users  trained on SAP security reporting and other tools. In theory, these folks are knowledgeable enough of the business processes at their location for the users they support, and with the tools and training, can make informed role choices. While Business Roles would probably add value to our process, we chose to continue with requesting technical roles for now, with some role mapping to ease the process, and consider implementing BRM later.


Another option is to do a security re-write- concurrently, before, or after the GRC project? If you decide to do it concurrently, be sure you have enough resources for the multiple work streams. My first GRC 10 project went that path; in my view, having a small army of experienced internal and external resources was one of the good decisions, along with ensuring good executive support.


If your rule set is in good shape, maybe you want to do your security rewrite ahead of the migration to GRC 10, either with a pilot or big bang. If you lean towards a pilot, be certain that your pilot group is onboard with the project approach; trust me, you don’t want to be in the position of having the business unit for the pilot getting cold feet midway through the project, leaving you in a tough spot.


between a rock and a hard place3.jpg


Change management decisions


How much of a change is GRC 10? It all depends. If you are implementing Access Request Management, does your current access request process have a lot of manual hand-offs and detours to be automated in the new process? It may delight your users, but they still have to be trained on the new user interface and get used to the automation. On the other hand, if you are just going live with Access Risk Analysis, you probably have a smaller user community to train.


The big project I mentioned above included a team of experienced change management consultants, and I think that was a smart choice for such a huge undertaking. My much smaller recent project had excellent internal support for communications and our web page, but we were pretty much on our own for developing and delivering training. We offered live training, step-by-step video recordings, and Quick Reference Cards that were jointly produced. All were well received; however, by business decision the training was not mandatory, so you can probably guess the outcome: the users who took the training are doing pretty well and are happy with the new system, especially the new request templates and more efficient workflows, and those who opted out of training…. Enough said.


Now we are working on resolving non-showstopper issues, problems identified during testing that were not urgent enough to risk breaking something else with a possibly buggy correction before go-live. It never really ends, does it?

And what about you? If you are already live on GRC 10, what would you do all over again and what might you do differently? I invite you to share your perspectives.

between a rock and a hard place3.jpg
You must be Logged on to comment or reply to a post.
  • Hi Gretchen

    Nice to know you worked on big bang & pilot approach to implement  & migrate to GRC 10 however I always recommend to my customers, colleagues & contacts to spend enough time in proper planning the migration, upgrade or new implementation. Big bang approach is usually not recommended due to issues you already highlighted & associated risks.

    It is responsibility of GRC 10 consultant to guide the customer in right direction and come up with low risk plan. I would recommend pilot+ module wise implementation to get quick wins such as access risk management & emergency access management goes first followed by other modules.

    ARM & BRM has definetely evolved for good & is quite robust in GRC 10.0 onwards as compared to 5.3 & most of customers have chosen to go with new implementation & configuration of BRM from 10.0 onwards.

    • Malini,

      I agree that ARM and BRM are more robust in 10.0 compared to 5.3; however, not every support pack has been of consistent quality. Anyone who has been following the discussions here has seen many comments about corrections that fixed one issue and broke (or re-broke) something else, and some SPs that got bad reputations because of it, depending on which components were being implemented.

      I don't know that I would necessarily put EAM in the category of "quick win." It might be, and then again maybe not, depending on the security design. If your support team has too much access in their everyday roles, it may be a challenge to get those roles winnowed down and transition the support team users to requesting FF IDs for activities they used to do without working about an EAM process.

      Yes, our project probably would have benefitted by time and money spent on a roadmap before jumping in to the migration; as they say, hindsight is 20/20. That is why I posted these blogs, so that other customers can learn from my experiences.

      Thanks for sharing your observations.



      • Thanks Gretchen for your response & its a good topic for discussion to get more insights from experiences

        ARM & EAM are examples I gave to illustrate about module wise implementation or migration. Quick win can be achieved with other modules as well but in most of customers I have known have considered access risk & emergency access as quick wins as they are the heart of GRC implementation & audit requirement as well 🙂

  • Hello Gretchen Lindquist ,

    Thanks for sharing, Currently I am busy with 10.1 implementation.. was suppose o be few months project but struck in security redesign work,  As we planned to go with BRM as well.

    Challenges we faced till now with Resource planning.

    I believe, we should have proper resource available as Its completly driven by Business  ,

    And Migration tool of is also having issue with lower version of JAVA.

    HR trigger in place in 5.3, then that system should be considered later for deployment of plug-in as chances are less for getting dump since it call old function module whihc is overwritten by new one. which eventually got fixed in SP04.

    need to check in HR system if they are using any Z subtype for infotype.

    BRF+ screen is also little confusing in 10.1.

    other changes in Screen level

    But adding Risk owner in Rule upload tab is existing. will be checking system more and update.

    Thanks Gretchen again for sharing good info.



    • Prasant,

      Thanks for sharing the challenges with your current project. I can certainly relate to security redesign projects running longer than expected. I look forward to hearing more from you when you succeed in resolving the issues in 10.1.