12.3    System Consolidation

Many reasons exist to undertake a system consolidation. In general, these advantages can be summarized under the rubric of reducing IT operating costs (Total Cost of Ownership, TCO) and implementing business objectives on the basis of a corporate strategy. In particular, regarding SAP S/4HANA as the central system of the future, consolidation can bring many advantages.

The following list describes some areas that may benefit from cost reduction through system consolidation:

• Hardware
  After a consolidation, a single system imposes lower requirements on the hardware than the combined source systems. Newly certified hardware for SAP HANA, in particular, results in savings.
• Maintenance, patches, and backups
  After consolidation, the costs of maintenance activities, implementing patches, and executing regular backups are drastically reduced depending on the number of systems replaced.
• Updates
  On the one hand, the costs for projects to update multiple systems are reduced, such as the costs for testing, for example. On the other hand, all end users benefit from the updated version of the central system at the same time.
• Transports
  A unified transport landscape simplifies transport logistics and reduces the total number of transports required.
• Custom developments
  Custom developments for the new system must only be created and tested once. After testing, your custom developments are immediately available to all users.
• Support
  Because all users work with a system with the same release status for all users, support for the users is greatly simplified.
• Reporting
  After a consolidation, reports and evaluations can be prepared on the basis of a uniform and central dataset.
• Interfaces
  The number of interfaces can be significantly reduced because, instead of distributed systems, a central system is now available. On the one hand, this centralization reduces the maintenance costs for the interfaces and, on the other hand, simplifies the development of new interfaces.

In parallel to the more technical savings, the process and data harmonization that SAP S/4HANA strives to achieve provides the opportunity to standardize, simplify, and therefore accelerate existing business processes. Among other things, harmonization provides benefits in the following areas:

• Users and authorizations
  Especially for users who log on to various systems for their work in a distributed system landscape, a central system significantly reduces the time required for administrative activities. Authorizations can also be unified now, thus simplifying monitoring.
• Finance
  Various approaches are available for consolidating financial activities. One example is harmonization towards a uniform chart of accounts, which could establish a basis for group-wide reporting.
• Organizational units
  In distributed landscapes, some technical identifiers may be used in preference, for example, “Company Code 1000.” These identifiers must correspond in the various systems but not to the same business organizational unit. A system consolidation gives you the option of separating legal entities and, in this way, of generating clear reporting.
• Master data
  One major advantage of system consolidation is the harmonization of master data. For example, a single representation of a vendor makes clear reporting and controlling possible and thus helps you analyze business relations clearly, in turn resulting in improvements in purchasing conditions.

We’ve mentioned just some of the potential benefits of a complete system consolidation. However, the individual benefits for customers must be determined in detail.

This section looks at the technical aspects of a system consolidation. Consolidating several systems can be carried out in two different ways: by transferring clients or by merging clients. A client transfer is technically easy to implement and results in the creation of a multiclient system, as shown in Figure 12.5.

In contrast, a client merge also consolidates the individual clients as a single-client system, as shown in Figure 12.6.

Figure 12.5    Example of a Client Transfer

Figure 12.6    Example of a Client Merge

From the project perspective, a system consolidation involves three steps:

1. First, you’ll have to define the overall objective, meaning you’ll define whether a client transfer or a client merge will be carried out. How many systems and clients you want to consolidate is also important.
2. Second, you’ll conduct a thorough analysis of all the systems involved to determine the differences between the project requirements in terms of volume and duration.
3. Finally, the actual consolidation is carried out, which consists of several test cycles and is completed with the actual production conversion. During the test phase, the data from the different systems must be harmonized.

To decide between a single-client or a multiclient system, a basic understanding of the client concept within an SAP system is of central importance. Users log in to the system at the client level. One client usually corresponds to one enterprise. Users are isolated within a client and therefore cannot view or change any data from another client. As a result, several enterprises that are logically separated can be technically run within one system.

As a result, a multiclient system is much easier to construct than merging clients. For transferring clients in a multiclient system, only the general settings and Customizing have to be adapted and, if conflicts exist, harmonized. A simple example of such a conflict would be an identical client number used in different systems for different clients.

For a complete merge, on the other hand, all client-dependent data must also be adjusted and, if conflicts exist, harmonized. The merge is easier the more similar the systems and clients to be consolidated are.

However, central areas (for example, various number ranges) have to be adjusted in almost every project. As with our earlier example of client numbers, in this case, the same numbering for organizational units, such as company codes for example, must be harmonized if necessary.

When combining individual systems and clients, other areas are also affected, for example, users and their authorizations.

Because this transformation scenario is complex, a thorough analysis of the systems involved is required to identify conflicts between settings, data, and programs. Table 12.1 provides an overview of the relevant areas you’ll need to analyze for a client transfer or a client merge.

Area to Be Analyzed	Client Transfer	Client Merge
ABAP Dictionary (data type and tables)	X	X
Customer-specific programs (such as programs in the Z namespace)	X	X
Modifications (to the SAP Standard) and user exits	X	X
Client-independent Customizing	X	X
Client-dependent Customizing		X
Application data (master and transaction data)		X
Number ranges		X
Users and authorizations		X
Program variants		X
Archives (created using Transaction SARA)		X

Table 12.1    Analyses Required for Client Transfer and Client Merge

This comparison once again shows the difference in complexity between the two system consolidation options.

Harmonizing these different areas requires various approaches. As shown in Table 12.1, the following areas are relevant for both client transfers and client merges:

• ABAP Dictionary
  The ABAP repository must be mentioned as an object to be consolidated, in addition to the SAP standard programs and data types. The ABAP Dictionary contains all structure information for SAP tables. Possible conflicts must also be identified in the ABAP Dictionary beforehand. By using the simplification list, conflicts are identified regarding the difference between a classic SAP ERP system and SAP S/4HANA. These conflicts are technically addressed by the conversion programs, which are also used for system conversions (see Chapter 10). These conversion programs are currently not integrated into SAP LT and must, for example, be carried out separately after consolidation.
• Custom programs
  If technical conflicts exist, custom programs must also be harmonized during consolidation. Conflicts may exist both in individual customer namespaces as well as in the traditional Z namespace. A simple example of the need to harmonize would be programs with the same name but with different structures or content. If the source texts of these programs differ, harmonization can be implemented quite simply by renaming one of the two programs. However, renaming is only one option. A detailed analysis of custom developments and related harmonization tasks must be scheduled along with the appropriate effort. In its analysis, SAP LT helps you use the appropriate functions, or you can use internal SAP tools such as custom code analysis via Transaction /SDF/CD_CCA.
• Modifications and user exits
  User exits constitute a special case because they are no longer created in current SAP solutions. Where possible, user exits have been replaced by Business Add-Ins (BAdIs). However, user exits continue to be used by many SAP customers and must also be considered before consolidation. The ABAP code of a user exit itself is client-independent. During harmonization, therefore, you must ensure that the extensions are assigned to their correct clients, which also applies for modifications previously made to the SAP standard.
• Client-independent Customizing
  Client-independent Customizing consists mainly of technical settings and thus usually does not require much effort to harmonize. A common example of Customizing settings that may need harmonizing is when your company has several factory calendars, with different validity periods in different systems, that need to be consolidated.. To resolve these conflicts, a uniform period of validity must be determined for the calendar. Technically, such an implementation involves little effort.

On the other hand, the following areas are of relevance, particularly if clients are merged into a single-client system. Harmonization needs can be extensive and complex in the following areas:

• Client-dependent Customizing
  Compared to harmonizing client-independent Customizing, harmonizing client-dependent Customizing is much more complex and costly. Comparing these Customizing settings already presents a challenge due to their high number. Therefore, an early analysis is essential to estimate the necessary steps. We recommend transferring the delta Customizing from the source system(s) to the target system. The target system should ideally be a copy of the existing development system. Thus, differences can be analyzed without restriction, and harmonization can be implemented.
  The effort required for manually processing conflicts also depends on coordinating changes within the company because central Customizing settings are affected, for example:
  • Organizational units
  • Units of measure
  • Currencies
  • Document types
  • Material types
  • Material groups
  • Account groups
  Mapping rules are a simple method for harmonization, for example, if organizational units have the same name. You can assign new values that are not yet used in the target system to various source values. If a simple renaming is not possible, you’ll have to decide how to handle a more complex conversion process.
• Application data and number ranges
  Application data concerns the actual data in a system or a client in the form of master and transaction data. Harmonization thus primarily concerns classic master data, such as materials, accounts receivable, and accounts payable. For numbers previously assigned internally within clients, overlaps in the number ranges may exist or numbers were assigned externally that occur in all systems but not for the same master data.
  Even in these cases, you can execute conversions. However, each data record would need to be converted individually. With high data volumes, however, this individual approach is impractical. Instead, you could use a prefix or an offset.

  [»]  Prefix and Offset

  In the simplest case of prefixing, an entire number range in master data is prefixed by a letter or a letter combination, thus creating a completely new number range.

  In an offset, a fixed number value is added to an existing number. As a result, the whole number range is moved, thus retaining its original intervals and conditions.

  These three methods, put simply, again involve renaming and adding the entire dataset from the source system to the target system. Particularly for accounts receivable and accounts payable, data quality is often critical for merging the content of data records that are numbered differently between the systems but that are perhaps identical in terms of content. Content-related cleansing can provide considerable added value to the organization, but you should not lose sight of the considerable additional costs for such data cleansing within a system consolidation.
• Users and authorizations
  Users and their authorizations are client specific and, depending on the objective, may require a comprehensive or simple harmonization. Often, within the different systems of a company, you may find similarly designed authorization concepts. If role types and authorizations differ significantly, creating new users may make more sense than a complex harmonization. If authorizations need to be adapted, you must ensure that fixed values can be stored within these authorizations that, for example, check the rights for a specific company code. These values must then be adjusted accordingly.
• Program variants
  For harmonizing program variants, the variants themselves are not necessarily the problem; rather, the data that was changed in the course of consolidation needs to be harmonized. Thus, the program variant might no longer work properly or may access incorrect values. If, for example, selection fields were preset with values that have changed or wildcards were used that now access a larger dataset, problems may arise. Although you can use analysis tools (for example, in the ABAP Workbench) to examine variants for this purpose, in most cases, manual work will be required if problems are identified.
• Archives
  Archived data from your SAP ERP system is still relevant for harmonization because these archives contain data relating to information that may be present in another form after a consolidation. Two options are available for adapting archive data in the course of the harmonization:
  • On the one hand, the archives can be uploaded back into the system’s database and thus be converted like other data during the consolidation.
  • Alternatively, you can convert the archives, which requires the archives are read first. The data is then converted as required for the harmonization and written into a new archive file. Different procedures may be used, depending on the storage system that you use for your archives.

If all necessary changes, as identified according to the analysis based on SAP LT or SAP Standard tools, have been addressed, you can define the transformation rules in SAP LT. You can determine, based on the nature of the conflict between the systems involved, how you want to resolve these conflicts, including all areas, for example, in which master data is received or overwritten, if identical numbers exist in the systems, or which Customizing settings are now the leading settings. Based on these rules, SAP LT transforms the individual data records and transfers them from the source system (or from multiple source systems) to the dedicated target system.

[ ! ]  SAP Consulting Required

SAP LT supports system consolidation scenarios, but system consolidations cannot be implemented using SAP LT exclusively. Due to the complexity of system consolidation projects, the necessary expert functions are currently only available through SAP Consulting (from SAP or a third-party provider).