Skip to Content

How to open up an SAP System for direct editing when SCC4 doesn’t work

For the great majority of times you open up SAP for editing transaction SCC4 will do the trick.

However if you ever find that someone in your team needs SAP opened up for direct editing and they keep getting a message from the system saying “SAP System has status ‘Not Modifiable’ ” This means you need to open up the system even further.

While this is dangerous because it opens up all sorts of potential issues you can do it in these kinds of circumstances using transaction SE03.

Go into SE03

Go down to the Administration part of the left hand menu system

Double Click on “Set System Change Option”

Change Global setting from “Not Modifiable” to “Modifiable”

Save settings.

Get the person to do their work then change it back immediately. – If auditors find this open in your system expect a chewing out so make sure you follow up on this and check it.

You must be Logged on to comment or reply to a post.
  • Admins everywhere just cringed when they saw this blog post.  Hope people have their auths in line so folks everywhere don't start opening systems for that "quick fix".  🙂

  • Opening up a production system for changes? Why? I'm tempted to say, "If you're doing this you have bigger things to worry about than the auditors..." 🙂

    • Some changes cannot be done any other way - In saying that I rely on BA's with 15 years experience to determine that. Provided changes are Done Dev -> Test -> PRD through a documented and tested procedure risks are basically the same as a transport.


      • I'm curious. Seriously. What changes can't be made any other way? I've been running my SAP system for 13 years and haven't found anything yet that needs this. Everything we do starts in DEV and is moved automatically to PRD - no manual changes.


        You're obviously doing different stuff from me - what changes do you need to make directly in PRD?

        • From memory a contractor had done a transport combination (Rather than putting through seperate ones) that ended up bringing through object changes it should not have with a varient configurator, the BA assessed the situ and found that the path of least risk required a manual change in each system.  I don't know the specifics beyond this, Obviously it all gets signed off by the change manager.



          • My concern would be control and testing. Changes that are transported (or copied some other way) can be tested and verified before they hit PRD, and you know when they go live there'll be no mistakes. Changes made directly in PRD, even if tested elsewhere, can be made incorrectly. Typos happen. If there's a way to make the changes without opening PRD, that has to be plan A, surely?


            I'm not doubting you - just trying to understand your scenario and learn from it!

          • Yes, absolutely, - That does concern me also. However I'm also at the end of a long chain that I have to trust I don't know enough about SAP ABAP or BA Config to question them beyond test procedures and documented approach so I am reliant upon their expertise and the change management process to be rigorous.


            I've certainly seen it before from certain big IT vendors (IB something ) making changes in PRD then ending up having to overwrite Dev Golden with PRD and then push that through to QA with little to no change rigor, which is part of the reason why they got kicked out straight after implementation. (We are still fixing their stuff ups 3 years down the track )

        • Only things I know of are hooking up an ABAP based source system in BW (there is a note about this one) and if you want to open a test system (non-prod) to make current settings changes.  In the latter, changing the test client to Productive will achieve the same result then change it back to Test after the change.