Data validation for selected use cases — today: Selective Data Transition (SDT) to SAP S/4 (part 2 of 4)

You’re selective when it comes to data and that’s a good characteristic. You don’t take just any data. Data validation should take this into account.

Blending greenfield with brownfield can have unexpected results — Icons made by Freepik from Flaticon (https://www.flaticon.com/authors/freepik)

Some explanation upfront: Selective Data Transition (SDT) is the transition path for those customers that for some reason consider an S/4 brownfield conversion as not reasonable or even possible (there are plenty of possible reasons) but don’t want to re-build their whole ERP functionality from scratch in an SAP S/4 greenfield implementation either. SDT is a mixture of greenfield and brownfield and a few additional ingredients or your choice. Resulting in a huge variety of possible flavors. (And while putting brown and green in a blender will result in an ugly green-brownish-mud-color, SDT is will make your system shine bright like a wonderful rainbow.)

There’s a lot of documentation out there, a few consultancies have been picked by SAP as trustworthy SDT delivery partners. Amongst them is cbs, with which we (Capgemini) have a strategic partnership. Their Enterprise Transformer is able to slice, dice and hash any SAP ECC system, add your favorite flavors and prepare a nice SAP S/4 dish out of that.

So if you’d like to get some details on SDT I recommend checking this material out or get in direct contact with Capgemini (= me) or our cbs friends.

But, as this is article is about data validation, let’s assume you are already SDT-minded. One key element of SDT is that it’s selective (surprise!). That means that a subset of the data of the original SAP ECC system will be present in the new SAP S/4 system. What criteria are used to define what data is going to be selected can be very different. Examples: data of a certain company code, data of a certain application component, data not older than x years. But from high level perspective the fact that some data will be taken with and some data will be left behind is all we need to keep in mind.

Another key element is that it’s a transition to SAP S/4. So generally speaking all the reasoning behind an SAP S/4 brownfield conversion are also applicable here (check out my previous article to get the basics) — as long as the selectivity is not relevant.

So, let’s pull out our checklist.

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

• Is there a change of the data model? YES
• Is it a selective data transition? YES
• Are values being changed during the transition? NO (of course there may be use cases where even value changes are necessary but it’s already complicated enough like this)
• Is it a conversion (= data stays on same system) or a migration (= data moves to another system)? MIGRATION

Conclusions for data validations for SAP S/4 SDT:

1. There is the potential risk that data gets “lost” because source and target system are not identical. Everything that is not explicitly included in the scope of the data migration is left behind. This could mean that filter criteria on table level are too strict or entire tables are falsely not included in the scope. This means: object checks are necessary to prove that data objects are not torn apart.
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. Depending on what criteria are used as selection criteria (e.g. company code, etc.) this selection is relevant to be checked on table level. There are different approaches for different cases but most of that can be implemented and executed with low effort.
4. An exception to point 3 are the tables that are subject of the SAP S/4 data model change. The changes on the data model make an evaluation on table level very effortful. So: not recommended for those tables.
5. An exception to what is stated with point 4 (so: the exception of the exception) 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.
6. 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. Of course also here the selectivity has to be considered. That means, if you have only company code “1000” in scope of the SDT, financial balances of this company code should be equal in the source and the target system while for all other company codes the financial balances in the target system should be zero.
7. The concept and implementation for any check must always stay flexible to scope changes. It is almost certain that the scope will change during the course of the project. Never hard-code any list of tables, company code values, etc. These must be stored in a central place where:

• it is possible to use an automatic versioning to track changes
• do necessary updates only once
• check logic that depends on the scope will consume the most recent data automatically

Compared to an SAP S/4 brownfield conversion, SDT is more complex when thinking about the right approach for data validation. Simply speaking, from data validation perspective SDT is like an SAP S/4 brownfield and additionally you have to make sure that no relevant data was accidentally left behind.

There are many valid reasons for doing an SDT and in total the efforts for an SDT project could be less than for a regular SAP S/4 brownfield (or SDT might even be the enabler for the SAP S/4 transition in the first place). But at least coming up with a sound strategy for data validation

• requires a bit more thinking and upfront planning and
• makes the attempt to do manual data validation even more ridiculous.

Next week

SAP S/4 is not what keeps you busy at night? Next week we will have a look at what needs to be considered for data validations if you’re on SAP but not moving to SAP S/4 (either you’re already on SAP S/4 or during your project you will still stay on SAP ECC).