Part 2: What is Data Relevancy and Why is it Important?

Welcome back, dear reader, to the second blog in the Relevancy series! If you missed the first blog on Data Relevancy, you can read that here.

Today, we will dive into what is typically the largest record count we expect in a migration project and that is known by many a name: Product, Article, Material, etc. (in SAP all roads lead to MATNR).

A few reasons as to why we apply relevancy to this domain would be:

1. Adopt usable records into the system by way of rules application as defined by the business
2. Help to ensure environment sizing is accurate
3. Reduce the amount of enrichment required on older objects (typically, you will see older records may lack key data requirements, as the source system has grown, requirements have changed, invariably leading to no longer usable data points existing)
4. Reduce archiving effort in target system

Product

The product is the data object representing what a company produces or sells, and it tends to carry the most variation within its ranks when it comes to determining relevancy and requires input from multiple organizational areas. When we apply relevancy rules, we will begin to understand the number of records applicable for migration into the new target system. The more rules applied, the more accurate, and in some instances, less volume of data expected to be ported to the new environment. It’s helpful to visualize relevancy application to something like the below:

Shipped/Sold within two years:

When we look to determine what should be brought into the new system, we find that forecasting tends to be the first baseline to establish, particularly within corporate entities. Most forecasting applications require two years of data in order to forecast properly. This is our leading point in relevant data in the retail space: Anything sold (T-LOG data) in the last two years must be brought into the new system to support forecasting. For non-retail customers, this would be based on Sales/Shipping orders.

Packaging/Services:

Services (such as gift wrapping, consulting, etc.), packaging (such as plastic containers), etc. may also be subject to forecasting and therefore should also fall into the two-year bucket, however this is not predicated on retail sales, but would be tied to Sales or Procurement orders.

New Products:

These may be products that are in the preparation phase of being created or made ready for sale but have not been offered up to market yet. Here we would need to consider effective or created dates to apply relevancy. It’s important to understand from either the Master Data or Procurement sources what date should be considered, as many clients have partially created data from products never launched that are in their source systems.

Vendor Required Retention:

These products are managed by the Vendor and typically communicated in a publication/subscription method such as GDSN (Global Data Synchronization Network) or Nielsen Brandbank. Some vendors require data be held within their consumer’s system for a period of time before being archived.

Financial Required Retention:

There typically is the possibility of financial department requirements also impacting product relevancy. If a client requires financial documents to be stored for X period and be accessible for updates (retro billing, etc.), then the products supporting these areas should also be deemed relevant.

With these requirements in mind, a typical relevancy logic for product should look something similar to the below:

1. Products that have sold within two years of the projected go live date (Retail products for forecasting)
2. Products that have shipped or sold within the last two years (Services, packaging, etc for non-Retail products)
3. Products created but not transactionally relevant yet (Delta beyond points 1&2 and client stipulated >= creation date in source)
4. Vendor required retention (Delta beyond points 1-3)
5. Financial requirements (Delta beyond points 1-4)

When we apply the relevancy in this fashion, we expect rules such as the forecasting to reduce the number of relevant records significantly. But we can’t pat ourselves on the back just yet!

The other rules mentioned here will be more of an exception in stipulating data needed in target beyond the forecasting line in the sand and, in most instances, increase the number of applicable records for migration into the target system.

One more thing to consider, unless you have severely lucked out and have all major business players in a room fully invested in nailing the relevancy requirements right out of the gate, expect this process to be iterative through your testing cycles! Not only should the data being migrated be subject to the goalposts per test load, the establishing of relevancy rules should be right alongside it!

We hope you have found this blog useful to date and that it helps spurn some thoughts and conversations when engaging with your projects.