06/11/2008 by Dieter Steiger
Nothing is more constant than change – this is also true for SAP systems. At least once a week, numerous changes of support or project organizations are moved into system landscapes and more or less automatically transported to production servers. And the more complex the solution landscape is, the higher the risk that something goes wrong.
Consistent, tool-supported SAP Change Control helps to implement, control and largely automate the SAP change process. To every SAP customer, a secure way of executing auto-deployment of SAP transports, for ABAP as well as non-ABAP changes, across the SAP landscape is available, but hardly ever it is consistently made use of. Instead, thousands of system components break down every week, and the resulting problems must ex post be analyzed and solved by system specialists.
It is true that compared to other commercial software systems, SAP systems offer quite convenient possibilities to implement changes across system landscapes. Unless there are parallel changes implemented from support and projects and the system landscape is very complex, SAP tools supporting change transport will do a good job. They allow transport routes to be defined across the system, transport requests to be released and change packages to be distributed and installed across the system, including defined steps of validation. So far, so good.
But this rather sophisticated system has its limits. First, the process of rolling out changes is quite error-prone. Second, the compliance rules are not completely met. And third, the system is susceptible to inconsistencies.
- Changes are more or less simultaneously distributed across the solution landscape via transport processes. Differences in runtime speed in the various phases of distribution and verification can cause time-dependent changes to be implemented in the wrong order.
- There might be conflicting changes from different projects.
- Manual changes might be executed at the wrong time.
- Customizing changes are not versioned and have no lock mechanism. It happens easily that they are unintentionally overwritten.
- Once changes and change sequences have been executed, they cannot easily be executed for a second time.
There are ways to proactively handle these problems with a reasonable effort. Using SAP Change Control with suitable tools and techniques implies the following:
- For all changes to the solution landscape, there is a change request and an approval. There is no transport request (technical change) without change request (organizational change). All changes are documented.
- Changes are grouped in packages according to projects and areas of use so that the transport is unlikely to cause conflicts with the system environment. The projects have more autonomy concerning transport.
- Transport and routine tasks are automatically executed in the correct order, including comprehensive measures to ensure consistency.
- Potential errors caused by changes that are transported faster than others or by unintentional overwriting are recognized in time and remedied proactively. This also applies to packages transporting different changes from all kinds of SAP or non-SAP systems, such as changes SAP CRM, ERP, or BW objects, customizing, Java packages, portal configurations – and to many interdependent components that must be changed.
- Entries into the Change Control documentation are made automatically.
- Change processes are strictly followed.
- All changes are executed in a secure way, rollback functions are available wherever possible. Changes can be run repeatedly.
- There is a complete audit trail for all changes.
SAP Change Management cannot automatically be scaled when the system landscape changes. But applying SAP Change Control techniques and tools most stringently will help SAP customers to massively reduce the risks and to largely avoid extra work and stress when distributing changes in complex system landscapes.