Fragmented Data Across Countries, Systems & Languages
The organization is a global agribusiness specializing in the cultivation, production, and trading of animal feed and essential food commodities.
Operating across more than 20 countries creates a complex data environment. Customers, suppliers, and products need to be understood consistently even when they originate in different systems, regions, and languages.
That complexity made trusted master data important not only for analytics, but also for day-to-day purchasing, supplier management, customer onboarding, and product operations.
A part purchased in one region, for example, could appear under a different part number, description, and language from the same item purchased elsewhere. Customer and supplier records faced similar fragmentation.
Customer, supplier, and product data was distributed across Sage X3, SAP Ariba, and other SAP modules.
Operating internationally added another layer of complexity. Records representing the same real-world entity could use different names, identifiers, descriptions, or languages depending on the country and source application.
The enterprise needed a way to understand those records globally rather than treating every local representation as a separate entity.
Duplicate Customer and Supplier Records
A customer or supplier already known in one region could appear differently in another system or country.
Without a consolidated master, teams could not easily determine whether the organization had already worked with a particular party before creating another record.
Different Names for the Same Product
Product information created an especially visible operational challenge.
The same part could be purchased in different countries under a different:
- part number,
- description,
- language,
- local source-system record.
That made identical items appear to be separate products.
The issue was particularly relevant for indirect products, where unnecessary duplication increased the number of products the supply-chain team had to manage.
No Global View Across Three Domains
Fragmentation also prevented the enterprise from creating one consistent view of customers, suppliers, and products across the organization.
Instead of seeing the business globally, teams were working through local system representations.
Business Knowledge Was Essential
Mastering these records could not be treated as a purely technical exercise.
Business data stewards understood how customers, suppliers, and products should be interpreted across markets. Their involvement was essential to defining matching rules, reviewing results, and validating mastered records.
Multidomain MDM in Databricks
LakeFusion helped the enterprise establish a multidomain mastering foundation in Databricks across customer, supplier, and product data.
The data comes from Sage X3, SAP Ariba, and other SAP modules across multiple countries and languages.
Rather than treating each domain as an isolated implementation, the program was designed so the experience and stewardship patterns developed in one domain could inform the next.
The solution supports two connected goals: creating a global enterprise view and improving operational processes around new record creation and product rationalization.
A Global 360-Degree View
For customers and suppliers, LakeFusion creates a more accurate and consolidated view across systems and regions.
The enterprise can understand when differently represented records refer to the same party instead of relying only on local source-system identities.
The same mastering principle extends to products, creating a more consistent view across all three domains.
Search Before Create
With trusted customer and supplier identities available, teams can check whether a party already exists before creating another record.
A customer or supplier known in one region can therefore be recognized even when another team encounters the organization through a different country or source system.
This supports search-before-create and helps prevent unnecessary duplicates from entering the environment.
Product Rationalization
LakeFusion also helps identify when products purchased under different local descriptions or identifiers represent the same underlying item.
This supports product rationalization, particularly for indirect products.
Instead of managing multiple product records for what may be the same item, supply-chain teams can work toward a more consistent product foundation across countries.
How LakeFusion Implemented the Multidomain Master
The implementation combined data assessment, business-led design, iterative matching refinement, and steward validation.
Rather than implementing all three domains in parallel, the enterprise moved through them sequentially so each phase could improve the next.
Data Profiling and Assessment
LakeFusion first assessed the data across Sage X3, SAP Ariba, and other SAP modules.
The team documented:
- duplicate records,
- inconsistent naming,
- language differences,
- regional variations,
- product-description inconsistencies.
This provided a clearer understanding of what had to be resolved within each domain.
Design and Discovery
Business stewards and other stakeholders were involved early in the process to help define:
- matching rules,
- stewardship requirements,
- cross-system considerations,
- multilingual variations,
- domain-specific business logic.
This ensured mastering decisions were based on business context as well as technical logic.
Implement, Test, and Tune
LakeFusion configured the mastering rules in Databricks and then ran iterative test-and-tune cycles across matching and survivorship.
These cycles happened before results were formally handed to business stewards.
That allowed technical issues to be refined first so stewards could focus on validating business accuracy rather than debugging the implementation.
UAT with Business Stewards
Once the mastered results were ready, business stewards validated the records during user acceptance testing.
They reviewed the outcomes and signed off before each domain moved into rollout.
Sequential Domain Rollout
The implementation followed a deliberate sequence:
Customer → Supplier → Product
This allowed matching lessons, stewardship practices, and implementation patterns from the customer domain to influence supplier mastering and then carry forward again into product.
All three domains were addressed within a six-month window.
Business Value Delivered
The primary result is a global, consolidated view of customers, suppliers, and products across systems and languages.
That shared master-data foundation also supports practical operational improvements.
A Global 360-Degree View
The enterprise can now work from a more accurate view across customer, supplier, and product domains.
Records previously separated by geography, source application, naming, or language can be mastered within one broader framework.
Search Before Creating Customers and Suppliers
When onboarding or evaluating a new customer or supplier, teams can check whether the organization has already worked with that party elsewhere in the business.
That reduces the likelihood of creating another duplicate simply because the existing relationship appears under a different system or regional representation.
Fewer Duplicate Product Identities
Product rationalization helps identify items being purchased under different names, numbers, or descriptions across countries.
This is especially important for indirect products, where unnecessary product proliferation creates additional inventory and spend-management work.
The goal is straightforward: reduce the time spent managing duplicate product identities and give supply-chain teams a more consistent product foundation.
Shared Learning Across Customer, Supplier & Product
Mastering all three domains as part of one program created a compounding benefit.
The enterprise did not need to approach every domain as an entirely new implementation.
Lessons and stewardship patterns from customer and supplier mastering could carry forward into product, improving the next phase of delivery.
What Made the Initiative Successful
Several factors were central to executing multidomain MDM across a global, multilingual organization.
Early Business Steward Engagement
Bringing business-side data stewards into the project early was one of the most important factors.
Rather than asking IT alone to determine whether records should match, the people closest to the business helped establish how customers, suppliers, and products should actually be mastered.
Business-Bookended Delivery
Business stakeholders were involved at both ends of the implementation.
They helped define requirements during design and discovery, while business stewards returned during UAT to validate the final results.
This kept the technical implementation anchored to the business problem throughout the project.
Iterative Matching Refinement
LakeFusion used repeated implement, test, and tune cycles before placing results in front of stewards.
That kept UAT focused on business validation rather than asking business users to troubleshoot immature matching logic.
Sequential Domain Delivery
Rolling out customer, supplier, and product sequentially allowed the implementation to compound learning.
Each domain informed the next rather than three independent projects attempting to solve similar mastering challenges at the same time.
Multi-Country and Multi-Language Handling
The solution also had to account for the fact that the same customer, supplier, or product could appear differently based on country and language.
Supporting this variation was essential to creating a genuinely global master instead of simply consolidating records within individual regions.
From Fragmented Regional Data to a Global Master-Data Foundation
The enterprise started with customer, supplier, and product information distributed across multiple enterprise systems, countries, and languages.
A supplier already known in one region could look new in another. The same product could carry a different identity across regional purchasing systems. Customer records faced similar inconsistencies across source applications.
LakeFusion brought all three domains together in Databricks through a business-led mastering process that combined profiling, matching, survivorship, stewardship, tuning, and UAT.
Within six months, the enterprise established a global 360-degree view across customer, supplier, and product data.
Teams can now check for existing customers and suppliers before creating new records, while product rationalization helps reduce the proliferation of duplicate product identities across countries.
Just as importantly, the organization now has a multidomain MDM foundation designed around the way its global business operates—not simply around the structure of individual source systems.
.webp)
.webp)
