I recently moderated a Q&A on SAP Access Control 10.0 workflow with Turnkey Consulting’s Simon Persin.
There was a lot of discussion on changes to approvals with 10.0 and MSMP and, not surprisingly, a lot of questions about BRF+, an area where we know our GRC 2013 conference attendees have lots of questions.
Specifically, Simon took questions on big changes to CAD, access request standard rules, Firefighter ID access, status requests for end users, the challenges of configuring alternate approvers, and skills you’ll need with BRF+.
If you missed the one-hour Q&A, you can review all the posts in this Q&A, visit Insider Learning Network’s Compliance Forum, or read the transcript below. Watch for more in this series of GRC Forums, webinars and podcast in the weeks to come!
Matt Moore, conference producer, GRC 2013: Welcome to today's forum on Access Control 10.0 workflow & automation. I’m pleased that we have Simon Persin from Turnkey Consulting here to take your questions.
Simon is senior manager & solution lead, GRC Access Controls with Turnkey Consulting and a speaker at SAPinsider’s GRC 2012 conference. Today’s Q&A is the first in a series of GRC Q&As, podcasts, and webinars we’ll be doing with Turnkey consultants.
Simon is here for the hour to answer your questions on Access Control 10.0 functionality, especially questions about Access Request Management (ARM – formerly CUP), access request automation and configuration, and using BRF+ and MSMP workflow in 10.0.
Welcome, Simon! It’s great to have you here!
Simon Persin, Turnkey Consulting: Thanks Matt!
Matt Moore: Simon, we’re happy to have your expertise to clear up some uncertainty in this area, especially since it’s a popular topic among our GRC customers.
I’d like to quickly start with a basic question, addressing some confusion about when to use BRF+ and the new MSMP templates.
Do you want to start with a quick overview of a couple of the most significant changes in workflow and automation with AC 10.0?
Simon Persin: Ok, to start with, perhaps we should look at what MSMP and BRF+ are:
MSMP is the new workflow engine used within GRC Access Controls 10.0. It stands for Multi-stage, multi-path meaning that the engine is capable of directing requests down multiple approval routes simultaneously. It is used for the management of automated approval workflows for the purposes of access request management but can also be triggered for the other access control modules including Access Risk Analysis master data updates or role build approval workflows. The big change is that it works off a multitude of different rules to govern what should happen to the requests. All of these rules need to be defined up front before they can be assigned in to the configuration and used in the workflow processes.
BRF+ is the Business Rules Framework Plus applicatioin which supports the definition of business rules. It can be the authoring environment for the rules which can then be plugged into MSMP workflow configuration. However, it is much more powerful than that. In advanced cases, it can actually be like writing code but for access controls functionality, the uses are often more simple to derive agents or specific results which can be linked to workflow route decision points.
The biggest change is definitely the terminology. The existing capabilities are still there within MSMP but they are called different things:
- There is still an initiator although this is now a central and global initiator for each workflow process (type). Rather than specifying an initiator for each workflow path, you now only have one which contains all of the different variations that you can have.
- Paths are still the same as are stages but Approvers are found through Agent Rules rather than CADs.
- Agent rules are also the source for defining recipients of notifications.
- Further changes are to be found in the architectural changes. Being on ABAP, the solution now requires more SAP standard setup. For example, you have to activate the tasks for SAP business workflow and configure SAPConnect to be able to send email notifications.
- Also, the content is transportable to enable you to migrate through the landscape. This also requires attention as although the configuration is transported, you’ll still need to check the master data (user IDs) and activate the workflow locally in each system.
rajeshnanda1982: How is it different from 5.3 when creating CAD?
Simon Persin: Hi,
The CAD is substantially different in 10.0 vs 5.3. In fact a CAD (Custom Approver Determinator) does not actually exist in GRC 10.0. It has been superceded by the concept of Agent Rules.
You can define agents through multiple different mechanisms - either directly mapped or via a PFCG user group or Role assignment. Alternatively, you can use BRF+ (Business Rules Framework Plus) to build a rule which will result in specific agent(s) based upon fields populated in the access request.
Cheers, Simon
KenLauver: This is one of the major reasons that we haven't upgraded to V10. We have a lot of faily complicated CAD's and although it seems like the appovers and agents would be the same people there is no way to easily convert the 5.3 CAD's to agent rules. Have you heard of a conversion tool? I know that SAP doesn't provide one.
Simon Persin: Hi Ken,
If you are on version 5.3 there is in fact a migration tool which will also work with your workflow configuration. I believe that CADs are indeed covered by this migration tool but to be honest with you, I have tended to recommend that when upgrading, customers should re-implement the workflow.
If you know what you want to achieve, and it is not reasonable to re-assess the design of the CADs, then it isn't too much of a technical challenge to re-configure the workflows to GRC 10.0. As with most of the tools, it is the thinking and design discussions that take the time rather than the technical build.
I don't know of any automated conversion tool other than SAP's migration tool but within BRF+ you can upload directly from excel so its quite quick once the design is finalised.
Simon
Matt Moore: A question about troubleshooting MSMP: There are a number of settings that must be in place before you can even begin working with MSMP. Are there steps here where errors are commonly made?
Simon Persin: In addition to my previous post, in terms of troubleshooting the MSMP setup, there is a specific issue if you have the GRC plug in installed on the GRC system. If that is the case, you cannot automatically activate the workflow tasks and assign agents correctly you’ll need to activate manually.
Bette Ferris: Simon, what are best practices or workarounds to simplify building business rules, to avoid some of the most common errors when setting up workflow in 10.0?
Simon Persin: Best practice for simplifying the workflow is to really challenging the validity of the approvers at each stage.
- Are they really required to make a decision or just there because historically thy want to know what's going on?
- If they only need to know, then how about making them a recipient of a notification rather than a specific approver?
I would also try to rationalise as much master data as possible. If you can have a rule in place that caters for changes in organisations then do that rather than leave yourself with a legacy of continually having to update users in the workflow definition.
Abdul Hakim Khan: Could anybody please tell us the best practice/approach for leveraging the pre delivered rules SAP_GRAC_ACCESS_REQUEST
A small business scenario would be helpful.
Simon Persin: Hi,
The pre-delivered rules are there mainly as accelerators. Whilst they are useful, they rarely match your requirements.
As standard, the access request goes to Manager then Role owner for every case. That's fine if you want that, but what if the request is for a system, not a role? Role owner won't work for that.
Also, what about Firefighter ID access? If you want a firefighter ID, why call a role owner? Wouldn't it be better to have an additional path to go to the Owner of the ID?
In that case, you'll already need to augment the standard default configuration to produce your own initiator to cater to your own use cases.
Simon
malinirao: What are the kind of workflows required for Emergency Access Management and Access Risk Analysis?
Simon Persin: Hi Malini,
Long time no speak!
For Emergency access Management, you don't need to use workflow but if you choose to, the main ones are the provisioning / removal of access via the SAP_GRC_ACCESS_REQUEST process and then the log review process SAP_GRC_FIREFIGHTER_LOG_REVIEW.
For ARA, the main workflows are for Master data updates including changes to Risks, Functions and Mitigating Control masters / assignment.
All of these workflows can be configured to direct to appropriate approvers and linked together for an integrated approach to access management.
Simon
malinirao: Hi Simon,
Good to hear from you after long time :)
I have another question, could you please site 1 or 2 examples of BRF+ Rules for the benefit of the audience to get better clarify of BRF+ rules.
Also what kind of skills/experience required to work on BRF+ Workflow. Is prior knowledge of BRF useful?
Simon Persin: Sure,
BRF+ rules are the basis of workflow process definition on the MSMP side of things.
The most common one that nearly everyone will need is an Initiator.
Here you define the routes which should be taken given a certain set of criteria.
For example:
You have a requirement that for access provisioning that workflow directs to a manager then a role owner but for access removal, it only goes to manager. Also if the user wants Firefighter access, it should go to the Firefighter owner.
In this case, you can use BRF+ to define the inputs and results for the workflow engine to process.
Solution:
Use Request Type to govern the result in a decision table within BRF+. Request type will be the inpur value and use the standard results of LINE ITEM and Trigger Value.
For Request types "New" and "Change" result in a value of "Addition"
For Request type "Delete" result in a value of "Remove"
For a request type of "Super User Access" result in a value of "Super".
You should also setup a path to match each of your approval requirements. You can then match the trigger values to the path when configuring the route mapping to direct the process down a chosen path which has the correct approvers
PatrickWeyersBE: Hi Simon,
Two questions from my side:
In 5.3, escalating during the manager approval stage was a common problem (There wasn't any way to configure alternate approvers. Only option was to forward to Administrator centrally). With 10.0, the escalation capabilities in MSMP appear to be more flexible. What is a good practice for escalating requests that are stalling in the manager approval stage?
Also, in 10.0, the request status overview for end users who want to check back on their access requests seems to have lost some functionality. Vs. the graphical overview from 5.3, there is now no way to deduce who will still have to approve (i.e. to receive an estimate of the how long the request will yet take to complete).
Any recommendations here?
Simon Persin: Hi Patrick,
Escalation is a common issue.
You can configure escalation independently at each approval stage and you have options to escalate to an alternative approver (a different agent) or to escalate directly to the next stage.
I don't tend to like escalation much as it can serve to encourage approvers not to make a decision and simply wait for the system to move it to someone else. But it is possible to be flexible with it with the technology.
Request status has been enhanced in 10.0. There is still an end user application which allows users to see their own requests but there is also an improved Instance Status available for users who have a GRC account. Here you can see the full status and history of the request as well as the current approvers. However, if there are multiple approvers (like Role owners) it does not dynamically update to show you which of the current approvers have already approved and who its waiting for. I submitted an Idea in the
KenLauver: Attendees, please remember to submit ideas for upgrades to the Idea Place cw.sdn.sap.com/cw/community/ideas Thanks Simon for the time and suggestions!
Matt Moore: Thanks to all who posted questions and followed the discussion! We’ve reached the end of the hour, and Simon is wrapping up his final responses to the posted questions.
Thank you, again, to Turnkey Consulting’s Simon Persin for taking the time to respond to these questions.
A full summary of all the questions will be available on Insider Learning Network.
Watch for our fall and spring calendar of GRC events – including live events, online forums, plus webinars, podcasts and more. Follow us on Twitter @iln4sap or check back on the Forum calendar for updates on the full GRC Q&A series:
- The next in this GRC series with Turnkey consultants is coming up soon – this Thursday, September 20: A webinar on Role- and ID-Based Firefighting with Simon’s colleague Kehinde Eseyin, exclusively for SAPexperts subscribers!
- For updates about this spring’s GRC 2013 conference in the US, visit our site. I hope to see you in
Thanks again for participating in today’s forum, and a special thanks to Simon Persin of Turnkey Consulting.
For additional GRC information, the GRC Forum archives past Q&As with Simon and other GRC experts. You can also post your questions for the entire community by selecting "New Thread" in the GRC Forum.
Thanks for joining us, and I look forward to seeing you all at GRC 2013 in the US. Thanks again for a great discussion!
