Data validation style guide for selected use cases — today: SAP S/4 brownfield (part 1 of 4)

Get your update from your data validation styling expert: what data validation to chose to underline the character of your data transition?

Icons made by Freepik from Flaticon (https://www.flaticon.com/authors/freepik)

In previous articles I talked a bit about technical aspects, general validation patterns, what to do and what not to do. Let’s now look into some use cases and what this means for what kind of data validations will be helpful in those cases. And what kind of data validations you should not touch because they will eat you alive from a cost-benefit-perspective.

Let’s try on some styles and see how they fit.

This is a selection of data transformation use cases and how to set up data validations for them. Real life data transformations usually have some special flavors that come on top of what is described below, but let’s not over-complicate things. Life is already complicated enough.

In this article I’m referring to data validation patterns explained here, if you’re missing an explanation I recommend you have a look at that previous article.

For starters: let’s go through a check list

The answers of this check list will help you determine what path you should take on your data validation journey.

• Does your data transition contain a change of the data model? The data model change we are talking about is not changing one field’s data type from character 10 to character 20 or moving data 1:1 from table Z_SOMETHING to Y_SOMETHING. That’s easy stuff. What “data model changes” mean is (for example): introducing table ACDOCA and filling it with data from multiple now obsolete tables.

Exact 1:1 data flow model of how ACDOCA data is loaded in an SAP S/4 transition

• Is it a selective data transition (SDT)*? That means: out of the whole system’s data do we take everything and convert/migrate? Or do we do that only for a subset? For example: only one company code, only the FI data, only data which was kissed by a unicorn at full moon?

*: the term “SDT” has been used a lot to describe a the transition to SAP S/4, but you can do data transitions selectively also apart from the SAP S/4 context.

• Are data values being changed by your data transition? For example: is company code “1000” renamed to company code “2000”? Does company code “2000” already exist and does it already contain data? Are there document numbers that need to be adjusted following a dedicated rule?
• Is it a data conversion (i.e. source system and target system are the same) or a data migration (i.e. source system and target system are different)?

Use case 1: brownfield SAP S/4 conversion

A brownfield SAP S/4 conversion is a conversion of an existing SAP ECC system into an SAP S/4 system. All data in the system is in scope of the conversion, the transition is not selective. (Potentially there is a preceding archiving project to reduce the data footprint of the system to reduce the conversion runtime as well as the storage costs, but this is something you would consider separately.)

For the above check list this means:

• Is there a change of the data model? YES
• Is it a selective data transition? NO
• Are values being changed during the transition? NO
• Is it a conversion or a migration? CONVERSION

Conclusions for data validations for brownfield SAP S/4 conversion:

1. There is no risk that data gets “lost” because source and target system are identical. Also there is no value change during the conversion, therefore object checks are unnecessary.
2. There is no value change during the conversion (apart from the changes that are related to the change of the data model), therefore there is no need to perform direct data comparisons to prove value mappings, document renumbering, etc.
3. The changes on the data model make an evaluation on table level very effortful. So: not recommended.
4. An exception to what is stated with point 3 is accessing the data which is made available via the compatibility views in SAP S/4. Compatibility views allow accessing the converted data via the old data model. On HANA level the access is re-routed to the new data model but you can still select the data from tables BSIS, BSIK… So this is a pretty easy way to validate the conversion, because selecting the data from the real table in ECC and from the compatibility view in S/4 still has to deliver the same result. This is a no-brainer which is implemented in virtually no time.
5. Comparing the output of your SAP and custom reports are a very elegant way to evaluate the transition. The reports have to adapt to the new data model already and still the numbers they show must be the same.

As a consequence the majority (90%+) of validations done in an SAP S/4 brownfield conversion are based on SAP and custom reports. With the right tooling and methodology this approach can be incorporated into any SAP S/4 brownfield conversion with relatively low effort…

• …saving a lot of effort by making any manual data validation obsolete,
• …eliminating the risk of human error,
• …increasing speed and simultaneously check coverage,
• …making auditors happy by guaranteeing the entire process is reproducible

Next week

Let’s look at a Selective Data Transition (SDT) to SAP S/4 next week.