IT activities in most enterprises fall under internal rules and regulations. Transferring objects to the production environment or creating them – is no different. Companies usually have a process for transferring T-Codes into the production environment or creating new user queries in the global queries area. Such a process begins with creating the object in the development system according to a design case; followed by testing it in the development system, transferring it to QA, running tests, getting approval from the user and finally transferring it to production. Quite a straightforward process, and in most cases works well.
Why only in most cases?
Because there are always exceptions. For example, a programmer decides to test a new functionality for reading data more efficiently from large tables. So the programmer creates a new T-Code and program in development (called Z_TEST). Unfortunately there isn’t enough data in any table in development, so the programmer transfers it to QA, only to discover that it was refreshed yesterday and there isn’t enough data there either. If you’re guessing that by now the T-Code is on its way to production, you are correct. Since the test is not documented or related to an actual task, the programmer can’t (or won’t) request a transfer “by the book” and instead just transfers the T-Code to production without any help.
The sad truth about temporary programs in production
If you’re thinking to yourself that you don’t have these types of objects in production, then think again. Even in a standard SAP® system there are temporary objects that were passed to production accidently. I’m sure your company has some too. Objects like T-Codes, programs, functions, queries and even temporary user accounts, which are created just for the purpose of testing something, end up staying forever in the production environment and exposing organizations to risk of misuse. A random search at some of our clients showed that these objects can really be dangerous (examples: directly delete rows in standard SAP tables, get all invoice amounts, backup user for the administrator with full authorizations, etc.).
So what can you do other than hope everyone obeys regulations and follows rules? You should implement an alerting system that notifies you about new objects “appearing” in production: new T-Codes, new programs, new user accounts, etc. A truly sophisticated alerting system will know when to avoid sending alerts, such as in the case where objects passed through the normal workflow process of development-to-production.
In addition to immediate alerts, a weekly report sent directly to your mailbox with a summary of all new objects in production this week is highly recommended. Such a summary should be crystal clear – also to managers – so that the development department can approve it and the security department can verify that regulations have been kept.
Don’t get me wrong, setting good workflow procedures and thus having to deal with less surprises, is the right thing to do, however controlling surprises in the production environment must be done too.