Challenge 1: Local differences require clear boundaries
International organizations benefit from a shared foundation. A consistent product structure, standardized order processes, and comparable reporting make it easier to manage multiple business units and compare performance across locations. At the same time, not every local difference should be eliminated. Tax regulations, delivery requirements, packaging standards, and commercial agreements often vary significantly from one country to another.
The discussion becomes more difficult when every local difference is treated as a system requirement. An exception made for one strategic customer gradually turns into a customization. A different process in a single business unit evolves into a separate workflow. After several years, the ERP environment contains dozens of local variations that few people can still explain.
For that reason, organizations should define before configuration begins which processes are mandatory across the group and where local business units are allowed to deviate. A local exception should always have a clear business justification, whether it is driven by legislation, market requirements, or a measurable commercial advantage.
“We’ve always worked this way” is rarely a sufficient reason.
Without clear boundaries, standardization becomes an endless negotiation, and the ERP environment continues to absorb local differences that were never intended to become part of the global standard.
Challenge 2: Customers notice integration issues before IT does
In international distribution, the ERP system sits at the center of a much broader application landscape. Inventory movements may be managed in a warehouse management system, product information in a PIM platform, customer agreements in a CRM, and online orders in an e-commerce platform. Each individual application can perform exactly as intended while customers still receive inconsistent information.
Inventory availability is a familiar example. The warehouse reserves stock, the webshop continues to display the previous quantity, and sales confirms a delivery date based on information available in the ERP. At that moment, every system contains data that can be considered correct, yet the customer receives three different answers.
The same situation occurs with pricing, product specifications, delivery conditions, and order status.
The quality of the application landscape therefore depends on very practical decisions. Which system owns a specific piece of information? Which system is allowed to modify it? How quickly should that change become available elsewhere?
These questions may sound technical, but they directly affect customer service, margins, and delivery performance. Adding another integration only creates value when there is also a clear understanding of which information should flow through it and who is accountable when something goes wrong.
Challenge 3: Poor master data becomes expensive once it affects multiple countries and channels
A duplicate supplier record or a missing product attribute may seem like a minor issue in isolation. In an international organization, however, the same error can affect purchasing, inventory planning, invoicing, e-commerce, and reporting. The cost is not limited to correcting the data. It also shows up in delayed orders, manual checks, and decisions made on the basis of incomplete information.
Product and supplier data are particularly likely to create problems in distribution. Different countries may use their own item codes, suppliers provide attributes in different formats, and local teams may complete the same fields in different ways. As a result, it becomes difficult to identify a single product consistently across the organization or to compare volumes, terms, and performance accurately.
The first step is not automatically the implementation of an MDM platform. Ownership and minimum data quality standards need to be clear first. Who is allowed to create a new item? Which information must be available before it can be sold? Who determines which supplier information is considered authoritative?
When multiple business units rely on the same core data and local controls are no longer sufficient, a PIM or MDM solution may become necessary. In that case, the technology follows from a concrete data management need rather than from a general ambition to centralize data.
Challenge 4: Bringing an acquisition together does not start with technical migration
Following an acquisition, there is often immediate pressure to consolidate systems. A single platform promises lower maintenance, consistent reporting, and a simpler operating model across the group. The biggest delays, however, rarely come from moving transactions. They usually arise when two organizations use the same terms in different ways.
One business unit may treat a product variant as a separate item, while another does not. Discounts may be calculated locally or agreed centrally. Inventory may be reserved by warehouse, legal entity, or sales organization. Until those decisions have been aligned, a migration can be technically successful and still create new operational discussions.
A sensible integration therefore starts with a limited number of decisions that have a direct impact on day-to-day operations. Which customers, products, and suppliers need to be identifiable across the group? Which processes should be aligned, and which can remain local for the time being? Which management information needs to be comparable from day one?
Making those decisions first helps prevent historical differences from being transferred unnoticed into the new ERP environment.
Challenge 5: Without clear decision makers, every request becomes a requirement
ERP affects almost every department and therefore almost every priority. Sales wants room for customer-specific agreements, operations wants predictable processes, finance wants control, and IT wants an environment that remains manageable. None of those priorities is wrong in itself. Problems arise when there is no forum or owner with the authority to make decisions when those priorities conflict.
Scope then expands gradually. An existing way of working is presented as essential, a local exception receives the same priority as a group-wide process, and a temporary solution becomes a permanent part of the design. The project team continues collecting requirements and configuring the system while fundamental decisions are postponed.
Clear process owners make a real difference. They do not need to decide every detail themselves, but they do need the authority to make decisions about process design, data, and exceptions. That role remains necessary after go-live as well. An ERP environment continues to evolve, and without ongoing ownership, the same fragmentation will return a few years later.
