Master Data for creating Master Data
This subject is like jumping out of an airplane. If you’re not afraid then maybe you haven’t sufficiently considered the scope, risk, and potential consequences.
The question: If master data is important then how much business importance should you assign to the master data used to create master data?
“Foundation” is an unsatisfying metaphor. Master data used to create master data — I’ll call this Reference Master Data — is more like a super-structure upon which master data is created.
If this critical master data isn’t groomed and cared for, then everything else rests on shaky ground. How can you trust reporting? How many business processes are failing in subtle ways? How many customer disappointments?
Reference Master Data is so consequential that it should affect your organization. Who are the data owners? Hint: “Data Owner” is a business role, and it’s not a committee. Who are the folks dedicated to the daily care and feeding of this most critical data? If not already under way then this is a good place to begin your data governance journey. Reference Master Data touches so many business processes and outcomes that it’s relatively easy to connect it with quantifiable business value.
The scariest answer to all of the above questions is: “I don’t know.”
Let’s make it real. Consider this Master Data map of a typical SAP S/4HANA ERP system (e.g. SAP S/4HANA Retail for Merchandise Management or SAP S/4HANA for Fashion and Vertical Business).
The block labeled “Reference Master Data” captures essential examples of what we’re talking about. But a moment after focusing on the obvious, you realize that additional Reference Master Data lurks under almost every block on the map. Ouch!
If you’re not intentionally controlling all of this — that’s data governance — then it’s out of control.
What are you going to do about it? Get answers to those questions!
Where to start? With the master data used to create master data, connected to business outcomes.
Notice that I haven’t written a word about software. When moving from answers to action, think first about people, processes, and business outcomes. Understand what you’re building and why, then find tools fit for purpose.