Is it time to reconsider your approach to SAP configuration (and reduce project effort as a result)?

I was recently involved in a review of SAP configuration guidelines that we communicate to new consultants joining our company (SAP implementation partner). It seemed to be a pretty straightforward and ‘boring’ topic at first, but it became a source of interesting insights that I think are worth sharing and discussing in a broader forum.

The outcome is our updated approach to SAP configuration in new projects (so called ‘greenfield’ implementations). It is unified across all S/4 flavors (public cloud, private cloud and on-premise). It focuses consultants effort on value-adding activities, instead of copying a lot of standard SAP configuration just for the sake of ‘not touching the standard settings’.

The ‘traditional’ approach

Let’s start with something simple and obvious. Since the beginning of SAP R/3 era in 1990’s we have had very clear guidelines regarding ABAP development:

• name custom development objects starting with Z* or Y* (with an option added later to define own namespaces /…/ )
• avoid changing standard SAP objects, as it will complicate future upgrades of the system.

Do we have similar guidelines for configuration settings? From my observations, SAP consultants have been following a set of similar – although not strictly codified – rules:

• do not modify any standard configuration settings provided by SAP (e.g. do not change attributes of material type ‘FERT’ or sales order type ‘OR’)
• consider predefined organization structures (e.g. company codes DE01, US01) as a reference but always define own structures for your organization (e.g. company code DE10, DE11, etc.)
• when creating own configuration settings, start their names with Z* or Y* because SAP usually (not always) avoids standard settings in this range.

For a sample configuration table (e.g. document types in sales or purchasing) we may illustrate these ‘historical’ rules as follows:

 

Proposal of a modern approach

I think it is time to reconsider and modify some of the rules listed above, based on the evolution of SAP solutions – on both technical level and project methodology level.

I believe we can achieve a noticeable reduction of the project effort, if we follow this approach:

• use standard predefined SAP configuration settings ‘as is’ if possible,
  or modify/adjust these settings according to customer requirements
• re-use standard organization structures (e.g. company code 1010 / plant 1010 for Germany or 1710 for US) and copy them if you need to multiply a given type of unit

 

If you have spent many years working on SAP on-premise implementations (which is my experience and I believe it is similar to the majority of SAP consultants) you probably have this reaction now:

 

In the following sections I am going to present three reasons why this ‘modern’ approach to the configuration of a S/4HANA system is possible and rational:

#1. Increasing role of SAP Best Practices in new implementations

#2. ‘The myth of SAP Best Practices upgrade’

#3. ‘The myth of S/4HANA upgrade’

 

#1 Increasing role of SAP Best Practices in new implementations

For S/4HANA Public Cloud the activation of SAP Best Practices is the only way to begin the configuration of a new tenant. For Private Cloud or on-premise version – it is an optional step (we may still start with a plain ‘client 000 copy’), but a foundation of Best Practices is usually going to shorten the implementation time.

 

Activation of Best Practices is going to create a large number of predefined configuration entries. Our goal is to map customer requirements to this preconfigured functionality. If necessary, we may tweak configuration parameters to better adjust them to customer-specific needs. Let’s say the sales order type ‘OR’ is matching our needs 99%, and we just need to change line item numbering increment from ‘10’ to ‘1’.

Now we have the dilemma: are we allowed to change an attribute in a standard SAP sales document type configuration?

 

In the past a consultant would copy ‘OR’ to a new type ‘ZOR’, to modify even a single field. But this action is not adding any business value. It is easier to change an attribute of ‘OR’ type instead of duplicating it to ‘ZOR’ (and we avoid keeping two order types on the list, where the standard one is never used).

The current SAP guidelines are a little inconsistent on this subject. I expect that the only reason is the vast volume of documentation that needs to be updated – it is hard to update it all consistently in a short time.

For instance, if you look at Implementation Guide (transaction SPRO, in S/4HANA on-premise 2021), description for pricing condition types here:

you are going to find this statement under ‘Recommendation’ heading:

“If you define your own condition types, the key should start with the letter Z as SAP reserves this namespace for this purpose in the system. Do not change the condition types that are contained in the system.”

However, if you take a look at online help for the same settings in S/4HANA 2021 or 2022 (private cloud / on-premise) here , the recommendation is different:

“The standard system includes predefined condition types. In configuration, you can change and maintain predefined condition types, but you can also create new condition types that better suit the needs of your own organization.”

I am confident we should follow the latter statement, as it is more pragmatic (requires less effort during implementation) and represents a more recent approach of SAP.

 

#2 The myth of SAP Best Practices upgrade

After I shared finding #1 with a few people, a colleague pointed to a fragment of SAP Activate training course (S4CP01) for S/4 private cloud version. Under heading „Methods of configuring SAP S/4HANA Cloud, private edition” one of the methods is described as follows:

„Use SAP Activate Methodology and SAP Best Practices content as templates for your system configuration, then make  changes using the Implementation Guide (IMG).

• This allows you to adapt SAP-delivered configuration settings to your specific requirements.
• If you choose this option, the automatic content upgrade to the next release will not be possible with Solution Builder”.

OK, so the approach of modifying SAP-delivered configuration settings is allowed, but the last sentence sounds a little scary… If I am going to follow this approach, the customer may complain later that I did something wrong, because they are not able to upgrade to the next BP release?

 

After more research I came to a conclusion that this is not a real issue. Because there is no option of automatically upgrading Best Practices content in an existing system.

Let’s say you installed S/4HANA 2021 with BP 2021 and next year you would like to import BP 2022 to your private cloud or on-premise installation. On-line help for the latest available BP release 2022 here , in section Upgrade -> Content changes in a new release states:

“The following is generally NOT SUPPORTED: Activating the next content version of SAP Best Practices content in a system where you have the content of the previous release already activated.”

and continues:

“You may activate the next version of SAP Best Practices content in a separate client in a technically upgraded system for reference purposes only. In this client, you check the configuration information for the required building blocks that belong to the scope items you want to update so you can identify the changes made in the next version”

In other words, Best Practices are currently a great implementation accelerator for a new implementation, but they are NOT a solution for automatic continuous delivery of new functionality. Enhancing functionality of an existing system (by adding new configuration settings, e.g. to utilize new features provided in the latest S/4 release) still requires careful planning and execution of manual configuration settings and regression testing.

 

#3 The myth of S/4HANA release upgrade

OK, based on the previous section we may accept that Best Practices version update is not going to be performed automatically in our SAP installation. But what about the release upgrade of the entire S/4HANA system? Wasn’t it the main reason we refrained from modifying standard SAP customizing settings in the first place?

Let’s revisit the example mentioned earlier. What if I modify the setting ‘item number increment’ of a standard sales order type ‘OR’ in S/4 release 2021 and later perform the upgrade to S/4 2022. Maybe SAP is going to overwrite my ‘OR’ record (entry in maintenance view V_TVAK) with a new standard configuration of ‘OR’?

This is where the ‘delivery class’ attribute of tables in SAP data dictionary becomes relevant. You may display this attribute using SE11 transaction:

 

There are several classes that describe various roles of tables in S/4HANA data model, and different rules what SAP can – or cannot – do with their contents during an upgrade. All configuration tables (or configuration maintenance views) in S/4 system have delivery class ‘C’ (or class ‘G’ that works almost identically, but is marked ‘legacy/obsolete’ by SAP).

The documentation of delivery classes which you may find here states:

“Delivery class C

Customer table for data entered only by the customer. […] In installations, updates, and language imports, the data in client-specific tables is only imported into the system client with the client ID “000”, overwriting any existing data. ”

In other words: the contents of configuration tables is going to be overwritten, but only in client 000. Configuration in our customizing client (or a test client, or a production client) is not updated automatically by SAP upgrade process. Therefore, our modification of ‘OR’ document type – or any other configuration setting – would not be lost as a result of upgrade.

Conclusion

I believe we should abandon now the long-standing rule ‘do not touch SAP standard configuration settings’ in both S/4HANA public cloud and also private cloud/on-premise implementations.

Of course there is no need to rush and modify configuration settings in an existing production system just for the sake of aligning them with some updated guidelines. This would require a lot of regression testing and updating documentation, without any noticeable benefit for the organization.

But for a new ‘greenfield’ implementation starting in 2023 or later you are going to achieve significant time savings if you initiate the project with activation of Best Practices scenarios and then re-use configuration settings included in BP. If existing standard settings (such as order type ‘OR’, or material type ‘FERT’) are a good match for customer requirements and only need a little adjustment – just modify these settings, instead of creating a copy of the entire record (to ZOR, or ZFER).

There are three reasons why it is possible:

• first of all, SAP documentation explicitly allows this approach (although it has not been consistently updated in all places yet)
• secondly, these settings are not going to be overwritten by a Best Practices update in your system
• finally, SAP is not overwriting records in tables with delivery class ‘C’ (or ‘G’) in clients other than 000 during S/4 release upgrade

I am looking forward to hearing your opinion on the approach described here, via comments on this post.