Bad Advice #1: Don’t Care About Master Data

Imagine you’re building a house. A big one. And it’s not only you – there are a lot of other people and teams involved. Some are responsible for building a living room, some – bedroom, some – kitchen, etc. Some of you started earlier, some have only joined. The goal is clear for everybody – there should be a finished building that will be suitable for living. And as expected the main common material you’ll need are bricks.

So, just imagine if each of the teams involved in this complex construction will use bricks of different shapes or sizes? Or i.e. one team decides that none of the standard bricks corresponds to their vision and they adjust the shape according to their requirements, let’s say left upper corner will be combed. What building you would get at the end?

The same when you’re implementing SAP. You have different teams, sometimes even running in different projects and in different project phases. And each of the team is dealing with Master Data. It’s crucial topic to have them unique and without duplicates but at the same time reusable and suitable for all the processes that are set up in the system.

Now imagine like with the bricks, different SAP project teams without alignment and supervision start to set up and adjust master data objects according to their own requirements, including validations and checks. Or in addition, if there are interfaces with other systems to get/update master data and there is no unique and clear approach agreed what is the main source of true data.

What are the consequences of such misalignment?

1.????? Duplicates: i.e. different business partner numbers are created for the same customer or vendor

2.????? Fields’ misuse: the same field is used by different teams for different purposes or custom fields can be created without control and some of them actually are duplicating others.

3.????? No alignment on the NRs and/or grouping

4.????? No common approach of who, when and how is allowed to create, change or delete a master data entry.

Is it possible to avoid these issues? Yes. By planning to have a master data governance team (or name it as you wish) from the very beginning of the transformation program can save the team from some most critical issues. If it’s not possible to have a separate team, then from each of other functional teams there can be a responsible person who will be a representative in a cross-modules master data board.

What about practicalities?

-??????? To involve MD governance team already from analyses phase into the workshops with business

-??????? To have separate solution design for each Master data object that will consolidate requirements/inputs from all the involved processes/modules/teams/systems (the best – with a clear view of the process for maintenance each of the object and responsible units/people for each field/part)

-??????? To inform MD team about all the updates and changes that influence/can influence a MD object

-??????? To define and align business processes, roles and responsible for creation, update, validation and deletion of MD objects

?

As we’re in AI era, after I’ve written the text above, I thought it would be interesting what chat GPT would recommend regarding SAP master data for greenfield implementation. And seems that in our case practice and experience fully proves the theory ??)

Here are some notes from ChatGPT ))) Master data is crucial for the smooth functioning of SAP systems, and addressing these challenges is vital for a successful implementation. Here are some of the significant issues:

- Data Quality and Accuracy (inaccurate or incomplete master data can lead to errors in business processes and reporting)

- Data Governance (incl. defining ownership, responsibilities, and processes for data maintenance and updates)

- Customization, Configuration and Standardization (need to strike a balance between customization and standardization; establishing and enforcing data standards across the organization)

- Master Data Maintenance Processes (workflows for data creation, modification, and validation).