Dieter Steiger SAP Template – basic rules for successful rollout

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:

SAP single-client architecture

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

Digitalized change processes ensure proactive momentum and link the various support systems that are participating in SAP change processes (control through redundancy).

Consistency assurance through SAP Solution Manager with SAP customizing synchronization

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.

Strict naming conventions for all development objects (SAP and non-SAP), including SAP customizing

So that each object to be developed (including SAP customizing entries) can be referenced by its logical components.

Software-supported SAP impact management

SAP impact management offers only one benefit when it is dynamically stacked from the logical components to the technical components.

Consistent SAP transport management

System-supported solution approaches for ensuring vertical and horizontal consistency are an absolute must, ideally directly coupled with component management.

SAP architecture 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.

Multi-program-capable project management.

The dependencies and intersections between several SAP projects must be comprehensively managed.

Conclusion

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.