06/21/2010 by Dieter Steiger
For over 15 years, I worked on the topic of SAP change and configuration management. Time and again I encounter SAP consolidation projects from SAP R/3 to SAP R/3. The motivation for such projects is familiar to everyone – reduce costs for SAP operations. Unfortunately, we have seen that SAP has scarcely learned from experience. Already after going live with the first corporate subsidiary, the company is facing a dilemma of whether to go live with additional corporate subsidiaries and operate the first live launch as a competitor.
This competitive situation for SAP projects can only be brought under control with SAP Application Lifecycle Management (SAP ALM).
Beteo defines the following guidelines for this:
Due to the competitive situation of several companies, products, etc. for the same SAP client, business process errors are already being identified in the development environment.
Digitalized change processes ensure proactive momentum and link the various support systems that are participating in SAP change processes (control through redundancy).
This permits autonomy of decentralized developments (primarily SAP customizing). Internal developments using component-oriented software engineering. Component-oriented software engineering in development and customizing allows long-lasting, dynamic software systems that can be adapted to changing business environments.
So that each object to be developed (including SAP customizing entries) can be referenced by its logical components.
SAP impact management offers only one benefit when it is dynamically stacked from the logical components to the technical components.
System-supported solution approaches for ensuring vertical and horizontal consistency are an absolute must, ideally directly coupled with component management.
Not everything that SAP communicates also functions in practice. Critical scrutiny of solution approaches from SAP is appropriate or even better – your own opinion, i.e., knowing your own requirements for managing SAP Template.
The dependencies and intersections between several SAP projects must be comprehensively managed.
All of these guidelines together – and really only all of them together – allow consistent SAP Template management. This sounds like a lot of technical complexity. Practice demonstrates that with complex SAP systems, the benefit outweighs the complexity many times over – if not the benefit of sustainable assurance of a corporate-wide SAP system.