on 03-30-2009 1:18 PM
Hello All,
can you elaborate on the deference between the available values of the control relevance field in the system (Control Activities, Control Env. , Info. and Comm. , Monitoring and etc..).
In addition, what is the deference between the "Test Automation" Field and "Control Automation Field".
Thanks
Yudit
Yudit,
Sure you can have different combinations.
You can have a manual control to verify data in the system and the testing of that control could be automated, for example, running a report or query from PC 2.5.
You can also have an automated control (a piece of config in an ECC system that prevents something from happening) and the testing of that control could be manual (manual test of effectiveness performed by a tester) or automated (an automated control configured in PC 2.5 to monitor the config settings in ECC according to specific thresholds configured in the PC 2.5 rule).
Matt
Edited by: Matt Hartnett on Mar 31, 2009 7:35 AM
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yudit,
Any one of the following will cause that problem. Make sure to do the following and it should resolve the issue:
1) Testing automation should be automated or semi-auotmated on the control being tested. (centrally if it is assigned with "reference", locally if it is assigned with "Copy" or "Assign without controls" methods.
2) The Org with the control assigned that is being tested or monitored needs an OLSP assigned to it with the appropriate "org level" that matches the rule. For example, if the rule has BUKRS, the org being tested needs an OLSP with BUKRS as well. Normally we maintain all OLSP field values for each org. We maintain the org values in the OLSP and NOT directly in the rule if possible.
3) Make sure you maintian "control rule frequencies" on the "Control Rule Assignment" screen.
Any one of these issues will cause the control to not show up when performing the search.
You can also maintain additional rule criteria if you wish.
Please let me know if this fixes your problem. It should work.
Matt
Hi Matt,
As always, thanks for the answer...
Do we have to maintain OLSP before we do the assignment ? Is it mandatory to use them ?
In addition, please see relevant screen shots.
http://www.yousendit.com/download/UmNJZHlsaTFvQnZIRGc9PQ
Thanks
Yudit
Yudit,
I'm not sure I'd say OLSP's are mandatory, but I think using them is good practice so you don't have these little "surprises" from time to time. Defining and assigning them can't hurt, only help......in my opinion. Please do the following:
1) Make sure the control is assigned to an Org (via a subprocess)
2) Make sure the control has automated or semi-automated "test automation"
3) Assign an OLSP to the org being tested
4) Maintain your monitoring and compliance frequencies on the "control rule assignment" screen for the rule
Do ALL of those steps and it should work.
Your description names look strange; the technical names are displayed where the description should be displayed. These are default values so I'm surprised to see them displayed the way they are.
To fix Test automation go: SPRO: => GRC Process Control => Attributes => Edit Attribute Values =>
1) Double click the folder on the left hand side "Attributes with fixed values"
2) Select the individual record on the right hand side "PR-TEST_AUTOM"
3) Go back to the left hand side and double click the "names" folder under Attributes with fixed values" folder
4) The screen should pop open where you can maintain the "text" description of the technical values:
Value - Text
0AUT - Automated
0MAN - Manual
0SEM - Semi-Automated
You'll have to do the same for the others as well. Let me know how all of this goes
Matt
Hi,
If you dont maintain the olsps you will not be ablr to proceed with.It is a must,otherwise the system will not be able to pick up the data from the C/Code to which RFCs has been given
OLSP is applicable to only SAP and not if you try to analyse the data from other ERPs like oracle etc
My2 cents...
Regards
Ramesh
Thanks Matt,
the problem was that the assignment method of the sub-process to the organization was "without controls". when i re-did the assignment of the sub-process to the organization with "reference" method the problem was solved and i'm now able to do the control-rule assignment.
In parallel, i tried to create the OLSP. when trying to choose the target connector i see i have no available entries.
this should be part of post-installation, no ?
Thanks
Yudit
Thanks Guys,
the problem was that the assignment method of the sub-process to the organization was "without controls". when i re-did the assignment of the sub-process to the organization with "reference" method the problem was solved and i'm now able to do the control-rule assignment.
In parallel, i tried to create the OLSP. when trying to choose the target connector i see i have no available entries.
this should be part of post-installation, no ?
Thanks
Yudit
Yudit,
The last thing you have to do is set up the connector. This can be done under the automated controls section in the IMG (TCode SPRO) and you can follow that documentation.
GRC Process Control => Assessment and Test => Automated Testing and Monitoring => Configure RFC Connectors
You also need the RTA installed on the target backend system.
That should do it.
Matt
Hi Yudit:
The only thing I would add is that the "control automation" field refers to the attribute of the control itself. You can have a manual, semi-automated or automated control.
"Test automation" refers to how the control is tested. If test automation is manual, you are able to assign a test plan for a manual test of effectiveness to the control. If the control is semi-automated or automated you can then assign "rules" to the control to enable automation.
I hope this helps.
Matt
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Yudit
Here are the details:
Generally Control Relevance field designates relevance of the control. The BC set includes choices in alignment with the elements of the COSO framework and indicators of fraud prevention/detection.
Test Automation
Select test automation as Automated, Manual or Semi-Automated. Use of this field is strongly suggested, as it has an impact on how controls will be tested within Process Control
Control Automation Field
This characteristic designates a control as whether it is a automatic,semi automatic or a manual control.
Thanks
Debraj Roy
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.