3/Nov/2016 blog updated for re-tagging due to SCN migration
On one of my first projects as the lead architect I needed to prototype GRC. I had supported GRC components before (albeit 5.3 version), attended the GRC300 training course and passed my certification. I was excited: finally a GRC 10.0 implementation. I was at a client and they had a need for it. I had the skill and enthusiasm to see it implemented. The client accepted my business case of lowering user administration and support cost, and I had the confidence to see this project through. Fantastic!! Woo-hoo GRC implementation here I come!!!!!!!!
Before I got my hands on the system, the business-process minded part of me had mapped out the strategy and approach. I put pen to paper and drew up my view of the access control processes: who would approve and what would they approve. My design integrated as much of Access Controls as possible. I found my Internal Controls buddy to assist me in keeping this business orientated: yes I found my first friend. I realised at the beginning, this implementation would not be possible if my team did not include a business stakeholder who could define business requirements and help design what an unacceptable risk to the business is and what the business was prepared to do about it. This friend of mine came from an Audit background (yes, auditors are friends too!) and could provide valuable input on compliance requirements we needed to adhere to.
We were able to work together to not only define the process but identify the roles and responsibility (in the form of a RACI model). In doing this, we identified organisational changes which then led me to another group of friends known as the Change Managers. We have not even got the system built and I am now spending more time with an ex-Auditor/Internal Controls expert and a Change Manager to properly define how the business would use GRC. The Change Manager then asks ‘Will end users be impacted’? Well, of course they will be as we are trying to automate user access provisioning and we have segregation of duties and risk and so on. My next group of friends became the Trainers. Internal Controls, Change Managers and Trainers oh my! And still no system!
It came time to submit the high level design for approval. My awesome pretty crap process designs were too high level. What I thought was three or four business processes were rebuilt by my next friend: The Business Analyst. This friend knew how to model business processes and took my diagrams (really PowerPoint slides) and broke them down to a much lower level. The business analyst identified logical gaps and incorrect assumptions without even knowing what GRC is (that soon changed). Had this friend not stepped in at the beginning I would have been in a world of pain with the workflow configuration and ultimately resulted in rework, project delay and additional cost.
Finally my system was built by my friend Basis. This team became my first-and-best-techy-friend (hey they always are). Until I started GRC, I had never raised a SAP message incident (I did not even know how to). SAP Marketplace and SCN contained my answers so it was never necessary. However, solution to most of SAP incidents I raised was in the form of a heap of notes and support stacks to apply and Basis were there for every step of the way. In addition, I had them assist me with appropriate system settings: system parameter; RFC connections; trusted systems; LDAP connections and NWBC. Yes, I could go configure them myself but if this was an ERP system would a Functional Consultant be allowed to do the same?
As I started to prototype the solution and came across the business workflow I learned more about the flexibility and powerfulness of GRC. I was able to configure MSMP (I’m quite a fan of it) but then I realised, it would be great to make friends with the Workflow and ABAP Developers, especially if they have the BRF+ skills and pick their brains. These developers would know how best to configure the workflow rules (do I use a decision table or a case statement?); build new launch pads and customise screen layouts. They would have a great naming convention for custom objects. They would also allow me to sit and help debug to find why I am getting that short dump (i.e. confirm I need to raise a SAP incident).
I continued to prototype and refine some of the design as we all discovered what the system would be capable of. It then dawned on me how best to document the configuration and build. I reached out to a new group of friends and they were Functional Consultants who worked on the ERP system. My view was: we might be configuring different systems but we’re both doing configuration via IMG and maybe there is something I can leverage from them (via our Solution Architect).
So before I even go to the development system, I became friends with Internal Controls; Change Managers; Trainers; Basis; Workflow and ABAP developers; and Functional Consultants. Most of my friends were included on my project plan so that management knew up front the true effort and people necessary for a GRC implementation to be successful. Management knew that GRC was not a support tool but enabled business process. Internal Controls was my key business representative who had their own set of friends to determine business requirements that I could translate to technical deliverables.
My motivation in finding friends was a concern I had: if I relied only on my own skills we may deliver a workable solution but it may not be the most effective and efficient solution. Without calling on all friends here, I might have a solution that works for day one but what happens next year or the year after? What happens when business requirements change? What happens when support stack and enhancement packs are necessary?
I’m sure there are more friends. Had I continued on this project I would have met up with Change and Release Managers to migrate changes and thinking through planning for enhancement packs, system refreshes and overall landscape design in conjunction with Basis. Oh, and if you’re wondering why no security - I did not forget them as that was me.
My advice – depending on the size of your project you may not need all these friends. Consider them in your planning based on your own strengths and weaknesses. Leverage where you can as it will benefit your solution in the long term.
Do you have any recommendations for who’d you make friends with and leverage for a successful GRC implementation? I would love to hear your thoughts in the comments below.
Regards
Colleen
P.S. I would like to make a special thank you to gretchen.lindquist for all your valuable feedback and encouragement to me for this blog.
