6\VWHP $GPLQLVWUDWLRQ 0DGH (DV\

Chapter 8: Scheduled Annual TasksNotesThe purpose of setting the production system to Not modifiable is to make sure that changesare made using the development pipeline.In the development pipeline, changes are:1. Created in the development system2. Tested in the development system3. Transported from the development system to the test system4. Tested in the test system5. Transported from the test system to the production systemUsing this procedure, changes are properly tested and applied to the systems in thepipeline.Objects should not be modifiable in the quality assurance or production systems. This rule isto protect the production system from object and configuration changes being made,without first being tested. By setting the production system to Not modifiable, the integrity ofthe pipeline is preserved.“Dangerous transactions” are transactions that could do the following: Damage or corrupt the system Present a security risk Adversely impact performance If a user accidentally accesses these transactions, they could corrupt or destroy the R/3System.Access to dangerous transactions is more critical in the production system than thedevelopment or test systems. This is because of live data and the fact that the company’soperations are dependent on the R/3 System. Certain transactions should be locked in the production system, but not in thedevelopment, test, or training systems.Standard security normally prevents access to these transactions. However, someadministrators, programmers, consultants, and functional key users could have access tothe transactions depending on the system they are on. In these cases, the transaction lockprovides a second line of defense.There are over 48,000 English transaction codes in the R/3 System. To make it manageable,only the critical ones need to be locked. Your functional consultants should supply you withany additional critical transactions in their modules.System Administration Made Easy8–5