Common mistakes in Change Management – Part 1 – Three is not a crowd
Three is not a crowd…
but still the three system landscape is most likely the de facto standard when setting up SAP systems.
What is good with this setup is that it really differentiates the testing activities (that should take place) from the development.
The down side is that the customer acceptance test and IT-test are done in the same system.
Normally also IT-tests are executed with too high authorizations leading to many authorization errors when executing customer acceptance tests.
IT is also a conflict of system refresh. Customers want the TST system as up to date as possible, where the IT-department want all their imported transports to not be lost.
Ups and downs about system refreshes.
So when shall a refresh be done and what are the activities.
Some risks when performing system refresh:
- Loosing user identities since the user database is not exactly as the production system
- Outgoing interfaces sent twice (both from test and production)
- Outgoing emails from workflow. Really confuses the users.
- Not scrambling data putting real data in a non-controlled environment
- Background jobs sending files to production places
- Loosing configuration or transports due to bad control of what has been transported
Some benefits of performing system refresh:
- Testing the disaster recovery plan by following the same procedure as if it was a production system that crashed (but with a redirected restore)
- Getting fresh data to test against
However, the risks are so much higher so that it is wise to look at some data copy tool that can move certain data instead of the entire system. So that you don’t have to copy the entire system with all the risks that appear. SAPs TDMS is a tool that could be of good use.
Looking at transport configuration details.
It is quite common when you set your SAP system landscape up that you start with your Development system and then after some time add the test system and shortly before go-live add the production system.
This leads to the fact that the file system of the production systems is not available from beginning, making the file system of the development system to be the TMS-controller and this puts a risk to the production system, since it might stop1 if the /usr/sap/trans directory is not available. So, when you plan to go live make sure that you also move the transport directory to the production system. (and makes the PRD system to the TMS-controller).
See note 28781 for good details on how to configure a central /usr/sap/trans
Another thing why to consider the Production system as the host for transport directory is the support agreement with your HW-provider. Oftenly you classify the Production system to have 24×7 support and dev+test to have 8×5 (office hours). Then if the Dev-system breaks it does not get the same attention as if the production system would have.
The DOs of a three system landscape
- Do have full control of what transports are imported into TST when doing system refreshes
- IT-department test first, then send bug fixes before Customer Acceptance testing begins
- Test with correct authorizations
The DONT’s of a three system landscape
- Don’t mount /usr/sap/trans from dev to prod
- Don’t IT-test with SAP_ALL
1 I have at least have one or two experiences of these issues when the /usr/sap/trans was mounted from DEV and when we restarted the DEV system the PRD froze since the file system was not available. I hope SAP have corrected this bug nowadays.
This blog is a part of my series of good change management within SAP.