The challenges of GRC 10 Access Control “ownership”
I have sat on both sides of the table: I have been the consultant working with clients to implement SAP GRC Access Control components, and I have been a customer member of the project teams. In today’s tight budgetary climate, exploitation projects are sometimes the best way to get project funding: configuring and implementing some additional component of a solution already bought, installed, and licenses paid. Thus, on the one hand, such exploitation projects can be huge wins: the customer gets more value from a solution already live, for better ROI. So what’s not to like?
Here is the part that can be overlooked in those rosy, halcyon early days post go-live of the additional component. Chances are good that your project scope went to go-live, with the consultancy providing some limited time of “hypercare.” Hurrah, it works! They are using it! The process works as designed and documented. The project sponsors are happy. Bye bye, good luck, it’s been great, let us know when you are ready for the next step in the roadmap. And on down the road they go to their next engagement.
Now you have to support this thing, possibly with just a few tweaks to your previous support processes, but other times the new solution requires processes that are brand new, with new risks and opportunities.
That’s no biggie, there are bound to be lots of blogs, wikis, and presentations online covering leading practices for production support for all of the Access Control components. Mmm, noooo, not really. SCN has a treasure trove of resources for going from installation to the go-live, like those listed in this compendium,
SAP Access Control – Useful Documents, Blogs, Resources, etc.
and discussions with tips for dealing with all kinds of issues and the “undocumented features” of some support packs, but production support? Welcome to “ownership:” you are on your own.
To be honest, it is not so surprising; the majority of the people who post on SCN do not work in production support, maybe never have, or are only called in when something is broken. Yes, there are some SAP customers who post here, but we seem to be rather in the minority. And who among the customers is going to boldly proclaim that they can advise on leading practices? Perhaps some of us just need a bit of encouragement.
Presentations at TechEd? If only; something process oriented would be considered “not technical enough.” The SAPInsider GRC Conference? No, not there either. The SAP user groups? On ASUG.com I found some great presentations on new features and roadmaps, use cases and implementation case studies, and one excellent presentation on administering your GRC system, but even that one was focused on best practices for dealing with problems. It seems that production support processes are not glamorous or exciting enough for presentations.
I plan to post a few specific questions but this is my ask to followers of this space: anyone who has any great ideas for production support processes for the GRC Access Control components- the field is wide open! You are cordially invited to step right up and share your experiences, especially those who have been doing it for years. Once we get this new process sorted out, I will publish a post, but don’t wait for me. You don’t have to claim that you have all the answers, or that your processes are one size fits all. Just sharing what works for you might help the next poor sod who implements that component and then says to herself. OK, now what?
Last time I saw SAP GRC was 3-4 years ago. Every month I would receive an oddly looking email and it was my cue to go into GRC, click through some screens that made no sense whatsoever and copy-paste the text that my predecessor was copy-pasting before me.
When the company went private and we didn't need GRC anymore I believe there was a celebration in the office. We dismantled GRC with the same glee as people would take down the statues of a former dictator. We danced on the virtual GRC bones. 🙂
I don't have any specific suggestions, but I guess something that would make GRC users not feel like that would be an improvement.
Jelena,
That process you describe is well known in GRC circles, the "rubber stamp" signoff on whatever control it was you were supposedly performing. Concerns about rubber stamping on our Firefighter Log reviews may be what is behind the questions I am getting from management. I suppose it *was* a happy day when the GRC system was decommissioned there; just hope that the day doesn't come when a phalanx of grim-faced auditors and bankers shows up on the doorstep looking for all of those records due to a pending acquisition or legal matter.
Thanks for commenting!
Gretchen
Hi Gretchen
Coming from a techie... if it helps I'm currently putting together ideas for a presentation titles "Why you should not implement GRC" and part of that is that GRC is only seen as a technical tool that you switch on.
I'm a huge fan on this product (even with some short comings) but I'm tired of it being seen as a technical product that will appease the auditors. Too many clients invest in it, aim for this big get clean and stay clean but they only have the tools and not the business ownership, ongoing support and change management behind it.
Production Support roles are continually perceived as inferior to project work (I wrote a blog/rant over in Careers called Give Support a Chance). Project teams end up with deadlines to get items over the line and pack up their kit bags and leave. They don't stick around long enough to see if their designs are maintainable. I know I'm guilty of this but unfortunately I haven't been on a project/client where I've had opportunity to perform continual health checks.
When it comes to GRC, is this really production support or more like business end users who are executing activities on the GRC system? I try to differentiate the two as GRC should have its own blueprint and set of business processes no different to Finance, Procurement, HR, etc.
Good discussion to open up 🙂
Cheers
Colleen
Colleen,
In this case it really is the GRC/security production support/ projects support/ Jack and Janes of all trades that we are talking about. It would be nice if we could get someone in the business to show some interest in running GRC reports and monitoring what is going on with it, but we will be fortunate if the Logs are reviewed reasonably timely, which is why the question came up.
I am still trying to figure out how we can tell if the logs have been reviewed. Perhaps we need to modify our workflow to make that happen.
Cheers,
Gretchen
Hi Gretchen
Are you sending logs to email or keeping as workflow? Challenge is even if you make them go into the system and press approve/reject the system cannot tell you if they have actually analysed and considered the risk.
Support People - documentation is always scarce and ultimately support procedures need to be written and enforced. Challenge is you don't end up back to managing all of it in a spreadsheet or spend unnecessary time and effort to manage additional process overhead.
Maybe GRC needs to get back to basics and look at why support and end users don't like the system; won't use it; etc. Transition to Operate and Maintain (i.e. Go Live) needs to include a support readiness step with. Support teams need to have the authority to reject project go live if training and process handover is not met. No point implementing a system if noone knows how to support it or use it properly.
Over time a knowledge base should be built up for the support team to manage the product - again no different to any other business process.
Regards
Colleen
We can't even get some of our business units to take ownership of their own processes or be good stewards of their own master data, so asking them to take an interest in anything like this would be truly a moonshot, I'm afraid.
As for SCN blogs tending to be consultant-oriented rather than support- or customer-oriented, yes, that's unfortunately true. There seems to be a persistent attitude among some that consulting is the only worthwhile career related to SAP. It is a worthwhile career -- but it's hardly the only one.
Matt,
I think you may have hit on the crux of the matter with your comment about being challenged to get some in the business to own even their own master data, let alone something like a GRC process. It may be that the silence from customers on their production support processes is the sound of a lot of people not wanting to admit that their processes are of dubious value, and they are just doing the best they can to keep the lights on. It's kind of sad when you think about all the money these organizations are spending implementing state of the art GRC tools, but without solid governance and support processes in place, they are not much better off, other than having something to trot out for the auditors. See, we're SOD exception free, the report says so!
Thanks for chiming in!
Gretchen
Gretchen:
This is always a big topic on every implementation that I do. I always make sure that this gets addressed (or at least started to), as I know that I will not be the one taking care of it in the long run. I started out as a customer back in the old VIRSA days, and was part of our internal implementation team. What we did was to have ownership at different levels. Finance had the ownership of the risk and mitigation data, while IT had ownership of the EAM data, security had ownership of the user provisioning data, and IT had ownership of the technical part of the solution. With that being said, we also had an Administrator that truly had a view of all of the working parts so as not to lose sight of the bigger picture. The customers that I find most successful have more of team oriented ownership of this solution as I have described as this touches many different parts of the organization. At the end of the day, I personally recommend that if you have to choose only 1 area to be the owner, that would neeed to be FINANCE. The final intent of the solution is to make sure that system access is remaining compliant and when conflicts arise, they can be seen proactively and dealt with BEFORE being introduced in to a production system.
It is nearly impossible to expect that any one of the areas that I mentioned above would be sufficient to own ALL of what GRC can entail. Above I have only referred to SAP Access Control, when you add additional GRC products, this definately becomes more evident.
With that being said, and looking more outside the SAP Access Control box, you also need to have a policy in place that is supported by company leadership where if you are an approver for a particular piece of SAP Access Control, 'rubber stamping' is out of policy and that the ownership of a particular approval is a personal responsibiltiy of the approver. It is however, nearly, if not totally, impossible to control that piece by a software solution.
I hope that I have helped here a bit.
Kevin
The trick is to isolate the sensible entries in the log which the data owner and the line manager can approve access to (before hand) or approve logs for (retro fitted).
If you overload them with data then don't be surprised that they and also you don't process it or just click it away...
Once you have isolated events and authorizations which needed the additional access and not the normal daily operations access, then you can reduce the noise and introduce a workflow for the logs to be added to the daily operations authorizations or exception logs for approvals.
You first need to implement GRC in such a way to reduce the noise and the "GRC team" is the correct instance to inform the business what belongs in their operational roles and what is exception or periodic or emergency handling.
Yes, for this the GRC team have to be able to read the log of course... but are not responsible for it per se. But you are responsible for finding owners of the approvers of the logs and not judging them.
That is my approach and my 2 cents to the topic 🙂
Cheers,
Juluis