SAP Change Management

After SAP go-live, it is generally thought that software development and customization is over. In fact, the real process begins after that. Because sub-projects that are not within the scope of the main SAP project or that are planned in additional phases  are generally desired to be implemented. Moreover, the process changes made in the project sometimes do not bring efficiency to the company as desired in practice, and these processes may need to be redesigned. In the most common situation, if the desired process and additional developments are not adequately tested, it is realized that it does not work as desired after it goes live and the errors need to be fixed. On the other hand, new functionalities or new legal requirements may be required. All these cases mean new changes to be made in the production system.

There are generally certain rules while the project is being carried out, but since there is no live use, changing the processes and screens is not a big problem. Post-live, there should be an appropriate change management procedure for such changes and these rules should be applied clearly without stretching. It should be noted that documents and transactions registered or open in the live system may be adversely affected by these changes.

To list the most frequently applied change management rules:

Three system Landscape ( DEV QA PROD): Establishing a triple structure for development, testing and live system, and enabling users to test with efficient and realistic datasets with the test system copied from live.

User Acceptance Tests: As stated in the above article, users must give their approval of the changes they request by testing. Otherwise, uncontrolled changes taken into the live system may cause systemic problems.

Impact Analysis: Perhaps the most frequently skipped rule, sometimes a requested change can negatively impact a process in the same department or another department. Time should be devoted to this detail during analysis and processes should be tested end-to-end, not just the part that has changed.

Change/Problem Tracking: Change requests and errors/incidents on a system should be tracked, if possible, requests received in SAP should be matched with the numbers in this system. When a search is made in this system, requested changes and incidents in a screen or process should be listed in ITSM or some other corporate memory software.

Documentation:  We talked about a system for tracking changes and incidents. In addition to this system, the requested changes must be documented in a standard format and stored in this system.

Segregation of Duties: The person who makes the development or customizations and the people who transports these change requests  to production system should be different. This process can be seen as a control mechanism for changes made.

Go-Live Plan: A development that goes live may cause a problem in production system, the system may not respond as in the test system. In order to overcome this problem, certain days and hours should be determined for change request transportation, and in special cases (such as appending a table) the change should be implemented at a time when the users will not be affected.

The above items can be relative, different combinations can be applied according to the company size and SAP team competence. But the more correctly managed, the less problems are encountered in the change management, . It should not be forgotten that long-term interruptions or systemic problems cause loss of reputation for the company and its employees, as well as financial losses.