Logging customizing activities

Question: Hello to everybody. I want to know if is there any way to logging all customizing activities. I want to know all information of any customization activity by SPRO.

Answer:
What's wrong with just giving the access to trusted, responsible individuals only?

Answer:
What's wrong with just giving the access to trusted, responsible individuals only?

Trust is good, control is better...

Activate the tables for table change logging in RZ11 param REC/CLIENT = ALL

For the changes from transaports (i.e. table was maintained in a different system), you need to activate the same param in the transport profile RECCLIENT = ALL.

You can then use the change log option in SPRO or SCU3.

Regards,
Ned

Answer:
What's wrong with just giving the access to trusted, responsible individuals only?

Trust is good, control is better...

Activate the tables for table change logging in RZ11 param REC/CLIENT = ALL

For the changes from transaports (i.e. table was maintained in a different system), you need to activate the same param in the transport profile RECCLIENT = ALL.

You can then use the change log option in SPRO or SCU3.

Regards,
Ned

I think we are agreeing on the same principle. Only giving access to those individuals who are responsible for the tasks.
When you have a large number of individuals who can make these changes, then I agree with the requirements for recording their actions, however imo the best solution is to strictly control access to customising to appropriate individuals. In my experience, this approach greatly reduces the necessity to have to go back and see who has made certain changes

Cheers
Al.

Answer:
Dear Al,

Your knowledge of SAP appears to have breakpoint set somewhere in the Cerebellum and stops before reaching application

I agree that there are generally not enough monitoring activities used (or even required periodically), but in many countries it is a legal requirement to have the information in the system, protect it and it is good practice to control critical changes.

Have a nice weekend,
Ned

Answer:
Dear Al,

Your knowledge of SAP appears to have breakpoint set somewhere in the Cerebellum and stops before reaching application

I agree that there are generally not enough monitoring activities used (or even required periodically), but in many countries it is a legal requirement to have the information in the system, protect it and it is good practice to control critical changes.

Have a nice weekend,
Ned
Hi Ned, I think we will have to agree to disagree. Control can be achieved in a number of ways, logging actions on the system being one. From previous experience, reliance on logging to provide control is usually at the detriment of an end to end robust change control process over customising. The typical attitude being "we have logging so it's ok". Surely you would agree that generally a preventative control is better than a detection post event?

Have a good weekend yourself while I try to get my grey matter -> SAP interface working

Cheers,
Al.

Answer:
Sorry for jumping on this discussion but, this has been an old area of conflict in SAP.

The issue is with authorization you can control who has access to configuration but does not control/log what is being done automatically, except for the transport requests. And it is very easy to not understand what is in an specific transport request.

What some companiea are doing is to install other softwares that help them to at least control the approval process of any changes made by these trusted resources (Aprova, Versa, Rev-trac, etc) but, still there are no way to actually log the changes made in configuration.

This not only would help in control, but also in documentation. Let us know if any of you find something that does that.
_________________
ZZ

Answer:
Sorry for jumping on this discussion but, this has been an old area of conflict in SAP.

The issue is with authorization you can control who has access to configuration but does not control/log what is being done automatically, except for the transport requests. And it is very easy to not understand what is in an specific transport request.

What some companiea are doing is to install other softwares that help them to at least control the approval process of any changes made by these trusted resources (Aprova, Versa, Rev-trac, etc) but, still there are no way to actually log the changes made in configuration.

This not only would help in control, but also in documentation. Let us know if any of you find something that does that.
When I find something that works well I'll definately let you know
Until then soem decent change control would be nice

Answer:
"but, still there are no way to actually log the changes made in configuration. "

What are you talking about?

Of course change controls are important, but they are not a trade off between controls and logs.

Customizing and much of config has a back-end table to it. Log the table for changes (DD09L-PROTOKOLL = X).

For transports, have the table change log activated in the transport profile

I.e. REC/CLIENT (param) = RECCLIENT (STMS) = ALL (clients).

Ned

Answer:
Great topic,
Ned does this method meet your needs for logging who made a config change in Production, or Dev?

This sounds good, any other tips you have on logging config changes, and tips on controls and logs for checking syncronization between the Dev customizing client and prd would be greatly appreciated. If you can point me to a favorite white paper I would really appreciate it. I want more methods for making sure changes do not get out of sync and / or get by my security controls.
_________________
Gary Morris
SAP Security Analyst/Developer
garymorris@sapsecurity.net

Answer:
Great topic,
Ned does this method meet your needs for logging who made a config change in Production, or Dev?

Hallo Gary,

Yes. Directly changed and changes from transports are logged this way in PROD. For the transported changes, the USER is the Task/Request number, which gives infos (log) of where the change came from. Looking in the dev system (it is advisable to have the log on there as well), you can see who changed what on which day.

The trickiest part of this, is deciding what to check... T000 is a good start.