Understanding the flow
Product data across systems
- 1
Source ERPs
Products, prices and stock
- 2
Data quality
Mappings and validation
- 3
PIM and APIs
Shared product views
- 4
Sales channels
Catalogues and partners
Simplified teaching diagram. Steps and technical choices depend on the context; this is not a delivered client architecture.
The problem: several systems, several versions of the same product
In a group with several companies or lines of business, product data rarely lives in one place. One ERP holds prices and commercial conditions, another manages stock, a PIM gathers characteristics and media, while B2B sites and sales teams need current information. Gaps sometimes appear only when the customer places an order.
Choosing a new tool does not resolve this on its own. The first task is to establish which application is authoritative for each field. The same SKU can have several sales units, descriptions, commercial rights or availability rules depending on the company.
What multi-system product-data programmes teach
In professional projects mixing historical ERP data, a PIM and commercial channels, the operational question is concrete: how can the same information be made usable without pretending that every system speaks the same language? Identifiers, business rules, field mappings and anomalies already known to the business teams have to be compared.
A product is not only a row in a database. Pack size, availability, category, tax treatment and customer rights can depend on several systems. A purely technical mapping can therefore look correct while producing a poor business result.
A project approach that does not start with the connector
First, map sources, consumers of the data and business owners. Second, define the reference for each piece of information and identify conflicts; document priority rules rather than arbitrarily keeping the last field updated.
Third, secure the circulation of data. Depending on context, that can mean APIs, ETL/ELT, an event queue or batch exchanges. An analytical warehouse or data lake can help consolidate and control, but it should not become the default transactional source for orders.
Fourth, put quality controls and traceability in place. Unmatched references, duplicates, inconsistent units, missing data or price gaps must be explainable and correctable by the appropriate owners.
Decisions that should not be left only to the integrator
Who may change the information? Which ERP is authoritative for prices and stock? What freshness is required to order without risk? What happens when a flow fails or a company changes its rules? How is a partial synchronisation detected?
These decisions belong to the business as much as to IT. A sound architecture gives them verifiable answers: identified sources, data contracts, controls, logging, possible recovery and responsibilities.
How Mahthildis can intervene
Paulo Castro can frame data flows and governance, design the PIM/ERP/API trajectory, lead publishers and integrators and take on an agreed technical scope. The result sought is a catalogue that commercial channels can use, without hiding dependencies or promising perfect data on day one.
A PIM does not erase the complexity of several ERPs. What makes the whole steerable is the quality of the data model and of the responsibilities between systems.
About these field situations
These situations combine lessons from Paulo Castro's professional experience. Organisations and operational details are not identified. They illustrate issues and possible approaches, not a claim that all suggested solutions were delivered together or that they are Mahthildis client references.
