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."
https://www.youtube.com/watch?v=D0tbfh-Arb8
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.
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.
- SAP Managed Tags:
6 Comments
