8 features that should be added to SAP Process Control...and not Idea Place!

SAP Process Control solution delivers great out-of-the-box features...But it should offer a little bit more. Some of the features highlighted in this post are probably the fruit of my twisted imagination! Others are just fixes to correct some minor limitations.

Enjoy the reading and please don’t hesitate to share your wish list.

1. Limit unauthorised modifications to master data once change requests have been approved

It is possible to enable a workflow for master data changes in order to enforce a review and approval process. The objective of this preventative mechanism is to obviously increase governance and ultimately ensure that data integrity is preserved at all times.

This is a great functionality and a good way to stay in control of your master data. However, it doesn’t quite do what it is supposed to do...and this is going on since version 3.0 (as far as I know).

The current standard functionality allows users to request changes to master data by manually typing which fields need to be changed (e.g. at the control level: control automation) and what are the new field values (e.g. change from field value “manual” to “automation”). The designated approver can then review all proposed changes before approving or rejecting the request.

You should expect that, once approved, the requestor can only change the list of fields mentioned in the request (all the rest should be greyed out) but unfortunately she/he can change any other local field that has been configured to allow local changes. The risk here is quite clear: the requestor can perform unauthorised changes to master data!

The approver can still perform a detective review of master data changes through the standard pre-delivered “Audit Log” report but what is the point in that case of enabling a preventative workflow for master data changes if you can’t place full reliance on it!

2. Define rules to enforce process discipline and increase level of automation

Let’s be honest here, each and every organisation has its own set of standards, policies and procedures. Corporate rules "on paper" should be easily transferred and enforced though any technological platform. Calibration mechanisms should be performed in a flexible and user-friendly way by functional users and more importantly without complex back-end customisation!

SAP Process Control should have an embedded console where authorised roles and users can actually define validation rules, aggregation and consolidation rules, user-exits, error/warning messages and notification thresholds. These elements can then be assigned to specific objects to tailor the behaviour of the different evaluation and reporting processes.

What does it mean in practice? Well, that means that each organisation can enforce system-driven checks and routines based on existing policies/ procedures.

For example, an organisation wants to define the following:

• A validation rule to prevent users from providing an adequate rating if issues raised during previous evaluation cycles have not been closed.
• A validation rule to prevent the sign-off at the organisation level if control self-assessment activities have not been completed.
• An aggregation rule to automatically set the rating of a control (during a control self-assessment or a control operating effectiveness rating) based on answers provided in the survey or manual test plan (e.g. if response for question 1 and question 4 is “No”, automatically set the control self-assessment rating as “Deficient” and enforce users to raise an issue).
• A consolidation rule to automatically define the overall rating of a unique central control based on evaluation results from all derived local controls (e.g. a central control A is operating in 15 markets by different control operators/ owners. The overall consolidated result of the control self-assessment should be marked as “Deficient” if local controls have been rated as “Deficient” in more than 2 markets).

3. Improve integration and processing capabilities of the continuous monitoring platform

Don't get me wrong here. The continuous monitoring platform is one of the most robust and powerful one compared to other solutions in the market.

However, I think that the platform can be more intelligent and can provide additional capabilities to perform advanced continuous monitoring and data analytics.

From a processing perspective, the solution should be able to allow users to link individual business rules (via influence factors) and define a processing logic between them to ultimately generate an aggregated output. The final value of a "parent" business rule (that trigger an alert) should be calculated based on the computation of the output from other "child" rules.

From an integration perspective, the solution should enable more integration capabilities between the continuous monitoring platform and the BRFplus workbench. Unfortunately not all the expressions, actions and rules can be used which is quite frustrating given the amazing power of the BRFplus engine. It is like if your Mercedes is connected to a Ferrari engine but you can't push the accelerator pedal to the max !

4. Intervene in transactional systems

SAP Process Control should be able to intervene in a more preventative and proactive manner by actually stopping activities or pushing corrective actions in targeted transactional systems, when and if possible.

From a "prevention" perspective, the solution should be able to block the execution of actions in the source systems, when such actions are deemed non-compliant with compliance rules. Similar to the "Risk Terminator" service in SAP Access Control (that runs and triggers automated risk analysis checks when access risks are detected during user or role maintenance activities), certain policies and controls should just be defined and calibrated in SAP Process Control and then enforced in selected transactional systems (no need to configure anything in back-end systems!). Oracle GRC for example, via the solution called Fusion GRC Advanced Controls, allows organisation to actually determine the level of control that they want to enforce over specific configuration settings, master data and transactions.

From a "push" perspective, I will just illustrate that with an example. Imagine a case where an automated business rule in SAP Process Control has detected that the message control for the duplicate invoice check has been changed from "Error" to "Warning" (allowing users to go ahead and post a duplicate invoice). This exception should simply be considered as unacceptable (significant deviation against the global template) and SAP Process Control should be able in that case to automatically push a corrective action towards the back-end transactional system in the form of a pre-approved change request ready to be released via the existing change management process.

No need to trigger an alert to a designated reviewer to assess the exception! Because this particular situation has been defined as "inadmissible", the remediation action should be fully automated and no human intervention is required to perform any kind of analysis (the exception is just wrong!).

5. Aggregate issues at each entity level during the sign-off process

The sign-off process enables organisations to provide a formal attestation of the effectiveness of internal controls. SAP Process Control offers a standard workflow to perform to sign off on control evaluation results for a specific period but this feature requires some minor technical fine tuning.

When reaching the “Review “stage in the standard workflow item “Perform Sign-Off”, the organisation hierarchy is automatically expanded showing all open issues of subordinated organisation units. However, the standard sign-off process does not automatically aggregate the total number of open issues at the next highest organisational level.

For example, if the organisation structure has been designed based on 3 hierarchical levels (Corporate / Division / Business Area) and all controls have been directly assigned at the lowest organisational level (business area level where controls are actually operating), the organisation owner in charge of signing-off control evaluations at the divisional level will not be able to see the total aggregated number of open issues from all underlying business areas.

Organisation units with no direct assignment of controls will simply report “0” open issues. If I am the ultimate person responsible of signing-off control evaluations at the corporate level (which you can imagine is quite a senior person with no time to go through all the organisation hierarchy to count open issues), I will always be pleasantly surprised to have no open issues!

6. Extend MDUG tool upload capabilities

As mentioned in my previous posts, SAP Process Control comes pre-delivered with a project tool called Master Data Upload Generator (MDUG). The tool is very useful (if used carefully) but unfortunately is not complete and optimised.

The MDUG tool should allow to perform 2 key additional operations:

• Assign users to front-end localised roles, allowing mass upload of user to role mapping. Currently, users need to manually perform that assignment via the front-end.
• Assign individual central controls to organisation units via the upload program GRFN_MASS_ASGN. Currently the tool only allows to assign the subprocess with all underlying controls. Currently local controls that are not applicable to a specific organisation unit need to be removed manually from the front-end.

Extending the capabilities of the MDUG tool will allow organisations to accelerate the data upload process during the implementation project.

7. Ability to design tailored manual test plans aligned with existing requirements

Here again, one size does not fit all. Why organisations should be constrained to use one predefined format to design their manual test plans? The inability to define a range of manual test templates based on specific testing format and requirement is a problem that has been reported by many organisations. Some pre-defined columns just don't make any sense and should be easily removed from the test plan structure. In addition to that, some columns should also be easily added to the pre-delivered structure.

I have seen many implementations where the inability to design tailored test plans has led to the selection and implementation of a very inefficient workaround: just add one standard test step into every manual test plan that makes reference to a Word or Excel document in the attachment tab ! This basically means that users will go back to off-line activities and the solution will be mainly used as a document repository system. Also the ability to track test steps completion and results via standard reports will simply be lost.

I am conscious that this development will involve some technical complexity (specifically on determining how pre-delivered Adobe Interactive Forms for off-line analysis will be adjusted and updated) but I still think that this feature is relevant from a functional perspective.

8. Ability to display an overall control matrix showing the assignment of unique central controls across all existing organisation units

The matrix should have n rows and m columns where n = unique central control and m = organisation unit. End-users should be able to display from one hand the total number of derived local controls per unique central control and from another hand the total number of derived local controls per organisation unit.

This matrix should just be able to answer the following questions at the click of a button: How many controls are actually operating across the organisation (corporate node and below)? No need to extract Excel files and manipulate data off-line to get that information, just one standard and pre-delivered matrix in order to get a quick snapshot !

Thank you for reading my post. If you would like to receive my future posts then please follow me.

If you want to know more about the most common mistakes or omissions that can derail your SAP Process Control implementation project, please check my post 10 common mistakes to avoid when implementing SAP Process Control.

If you want to learn more about 12 functionalities in SAP Process Control that in my view can make a real difference, please check my post SAP Process Control: 12 little things that can make a big difference.

If you are already using SAP Access Control solution and have the intention of deploying (or have already deployed) SAP Process Control, please check my post 5 ways to boost SAP Access Control by using the full power of SAP Process Control.

If you have enabled automating monitoring in SAP Process Control (or have the intention to do so) and would like to know more about 18 must-do's to get the buy-in from your auditors, please read my post Automated monitoring in SAP Process Control: what you must do to get the buy-in from your auditors (and you can't hide from them!).

If you want to know how SAP Process Control can be leveraged to continuously monitor and measure process adherence, please read my post How SAP Process Control can help you measure process adherence.

Opinions expressed are solely my own and do not necessarily express the views or opinions of my employer.