In theory, you should combine the concept for these two master domains in some degree. The reasons are:
There is always an overlap of the real-world entities that has both a customer and a supplier role to your organization. The overlap is often bigger than you think not at least if you include the overlap of company family trees that have members in one of these roles.
The basic master data for these master data domains are the same: Identification numbers, names, addresses, means of communication and more.
The third-party enrichment opportunities are the same. The most predominant possibilities are integration with business directories (as Dun & Bradstreet and national registries) and address validation (as Loqate and national postal services).
In practice, the problem is that the business case for customer MDM and supplier MDM may not be realized at the same time. So, one domain will typically be implemented before the other depending on your organization’s business model.
Most MDM solutions must coexist with an – or several – ERP solutions. All popular enterprise grade ERP solutions have adapted the business partner view with a common data model for basic supplier and customer data. This is the case with SAP S/4HANA and for example the address book in Microsoft Dynamics AX and Oracle JD Edwards.
MDM solutions themselves does also provide for a common structure. If you model one domain before the other, it is imperative that you consider all business partner roles in that model.
Data Governance Considerations
A data governance framework may typically be rolled out one master data domain at the time or in parallel. It is here essential that the data policies, data standards and business glossary for basic customer master data and basic supplier master data is coordinated.
Business Case Considerations
The business case for customer MDM will be stronger if the joint advantages with supplier MDM is incorporated – and vice versa.
This includes improvement in customer/supplier engagement and the derived supply/value chain effectiveness, cost sharing of third-party data enrichment service expenses and shared gains in risk assessment.
Explaining how data quality improvement will lead to business outcome has always been difficult. The challenge is that there very seldom is a case where you with confidence can say “fix this data and you will earn x money within y days”.
Not that I have not seen such bold statements. However, they very rarely survive a reality check. On the other hand, we all know that data quality problems seriously effect the healthiness of any business.
A reason why the world is not that simple is that there is a long stretch from data quality to business outcome. The stretch goes like this:
First, data quality must be translated into information quality. Raw data must be put into a business context where the impact of duplicates, incomplete records, inaccurate values and so on is quantified, qualified and related within affected business scenarios.
Next, the achieved information quality advancements must be actionable in order to cater for better business decisions. Here it is essential to look beyond the purpose of why the data was gathered in the first place and explore how a given piece of information can serve multiple purpose of actions.
Finally, the decisions must enable positive business outcomes within growth, cost reductions, mitigation of risks and/or time to value. Often these goals are met through multiple chains of bringing data into context, making that information actionable and taking the right decisions based on the achieved and shared knowledge.
Stay tuned – and also look back – on this blog for observations and experiences for proven paths on how to improve data quality leading to positive business outcome.
Any implementation of a Master Data Management (MDM), Product Information Management (PIM) and/or Data Quality Management (DQM) solution will need a business case to tell if the intended solution has a positive business outcome.
Prior to the solution selection you will typically have:
Identified the vision and mission for the intended solution
Nailed the pain points the solution is going to solve
Framed the scope in terms of the organizational coverage and the data domain coverage
Gathered the high-level requirements for a possible solution
Estimated the financial results achieved if the solution removes the pain points within the scope and adhering to the requirements
The solution selection (jump-starting with the Disruptive MDM / PIM / DQM Select Your Solution service) will then inform you about the Total Cost of Ownership (TCO) of the best fit solution(s).
From here you can, put very simple, calculate the Return of Investment (ROI) by withdrawing the TCO from the estimated financial results.