Challenges and Solutions from a Global SAP Master Data Governance Implementation

Sometimes implementing MDG implies a data governance organisation redesign. While local business readiness is typically ensured through communication and trainings, readiness of centralised roles is often underestimated. Making sure central teams are properly sized and trained is key to allowing the prompt processing of change requests, smooth testing and hypercare activities.

It’s good practice to prepare a detailed handbook to be shared with all teams responsible for the systems connected to MDG. The handbook will help them understand the minimum system requirements and properly configure such systems before MDG SIT (System Integration Testing) starts.

Once the global design is finalised, in case of multiple countries/systems involved in the deployment, fit-to-standard design can start. It’s important to include a comprehensive list of local ERP validations/customisations in the fit-to-standard document for the build team to be able to configure MDG accordingly and allow smooth data replication.

For example, validating the data loaded for UAT will increase the experience of the data migration team and reduce the number of errors during production load. Additionally, it will make the business more confident with the MDG solution and more familiar with upcoming production load validation activities.

Reporting at test script level or at change request level? This is a common dilemma before UAT starts. Often the same scenario needs to be executed multiple times for specific divisions, sales organisations and purchase organisations. Each execution generates a new CR in MDG. This should be one of the key drivers when planning testing.

Based on our experience, full MDG workflows can be tested independently from replication to connected systems (e.g. local ERPs). This split can also be reflected in test scripts by creating two separate sections and in the testing tool by adding a dedicated status (e.g. ‘pending replication’). As a result, business and centralised roles can start UAT even if some replication defects identified in SIT are still being resolved by the support team.​

Before going live, it’s a good practice to train some superusers to make sure they can autonomously monitor replication to local systems (IDocs) and the status of CRs. Circulating dedicated reports on a regular basis may allow early identification of issues and speed up the client’s end-to-end ownership of the new application.

Existing CRs for shared customers/suppliers should be either rejected or approved, before starting data migration activities. Another option is to run a ‘snapshot refresh’ on all open CRs to incorporate the migrated data into the existing CRs.

Having local teams performing regression validation is a good practice to ensure the stability of the live solution and high data quality, especially in case business partners are shared across multiple countries/systems.