Integrating WMS, ERP, e-commerce and physical retail does not begin with simply connecting systems. It begins much earlier: with understanding the process, defining sources of truth, describing data flows and establishing the responsibilities of each application.
In many trading companies, the problem is not a lack of systems. Quite the opposite — there are often many of them. An online store, ERP, WMS, physical retail systems, a sales integration platform, courier modules, supporting spreadsheets and additional tools used by individual departments.
It is the way these systems work together that determines whether the company actually has an efficient sales and order fulfilment process.
In one project, I had the opportunity to analyse a similar scenario for a trading company operating in the building and technical materials sector. The organisation had more than a dozen branches, its own warehouses, physical retail operations and an e-commerce channel. It used an ERP system responsible for invoicing and accounting, a separate WMS supporting warehouse operations and a sales integration platform used to process orders from online channels.
At first glance, the company had all the tools it needed. The problem was that they did not form one coherent ecosystem.
The problem: the systems worked, but they did not work together
In projects like this, the main source of difficulty is often not a single technical defect. The underlying problem is that the business process was never designed precisely enough.
In the case analysed, the problems included:
- manual re-entry of orders between systems,
- inconsistent inventory levels, particularly across multiple warehouses and branches,
- no single source of truth for products, inventory and order statuses,
- no complete integration between the sales integration platform and the WMS,
- the need to create invoices manually in advance and remove goods from inventory,
- manual handling of warehouse issue documents and warehouse labels,
- too many supporting Excel spreadsheets,
- picking errors,
- problems with sales documents,
- limited visibility of order statuses,
- difficulties handling returns at physical locations because warehouses and sales channels were not synchronised.
Systems added gradually over time often reflect the history of a company’s growth rather than its target operating model.
The situation before the process was structured
In simplified terms, the situation before the analysis can be described as an environment in which some data moves between systems, while a significant part of the process still depends on manual checks, exports, reconciliations and supporting spreadsheets.
Such a model may work for some time, particularly at a smaller scale. As the number of orders, warehouses, branches and sales channels increases, however, it starts to generate more and more problems.
Every manual activity becomes a potential source of error. Every supporting spreadsheet becomes an alternative version of reality. Every lack of synchronisation between systems can lead to a situation where the customer sees a product as available, the warehouse sees something different and the accounting team is working with yet another version of the data.
Why is it not enough to “just integrate the systems”?
System integration is often presented as a technical task: connect system A to system B, expose an API, retrieve data, transfer the order and update the status.
In practice, technical integration is only the final stage of the work. First, the process itself needs to be defined.
Before a good integration can be designed, the following questions need to be answered:
- which system is the primary source of product data,
- where prices are maintained,
- where the reliable inventory level is maintained,
- which system creates the order,
- when inventory is reserved,
- where the sales document is created,
- where the warehouse document is created,
- who updates the order status and when,
- how returns are handled,
- how cancellations are handled,
- what happens when stock is unavailable,
- how physical retail sales affect online availability,
- how transfers between warehouses are handled,
- which data should be returned to the online store,
- which information is required by accounting,
- what should be sent to the WMS and what should be sent to the ERP system.
Without answers to these questions, integration may only make the chaos move faster. The systems will start exchanging data, but it will still be unclear which data is authoritative, which event triggers the process and which system is responsible for a particular stage of order fulfilment.
Facing a similar challenge and want to bring it under control?
The role of analysis: from chaos to a process model
As part of the analytical work, I supported the client in structuring the process and preparing the foundations for further implementation. The work was not limited to describing a list of features. The key was to understand how the company actually worked and how it should work once the integrations had been implemented.
The scope of work included:
- analysing the existing sales and order fulfilment processes,
- discussions with business stakeholders and people responsible for individual areas,
- describing data flows between systems,
- identifying points where data was being entered manually,
- defining sources of truth for products, prices, inventory and documents,
- describing integration requirements,
- preparing process diagrams,
- translating business needs into technical requirements,
- supporting communication between the client and the implementation partner,
- supporting the preparation of materials that could be provided to the implementation partner responsible for developing the integrations and API interfaces.
Many decisions that determine the success of an implementation are made before configuration or development even begins.
The target ecosystem model
Once the process had been structured, it was possible to design the target model for cooperation between the systems. The goal was not for every system to do everything. Quite the opposite — the aim was to establish a clear division of responsibilities.
In this model, each system has a defined role. The online store is responsible for presenting the offer and accepting online orders. Physical retail supports transactions carried out in branches. The WMS is responsible for warehouse operations, picking, inventory and stock movements. The ERP system handles sales documents, settlements and accounting. The sales integration platform acts as the data exchange layer that connects the process and allows the systems to work together.
The most important point, however, is that this model needs to be designed before implementation. Drawing connections between applications is not enough. It is also necessary to establish which events trigger data flows, which information is mandatory, what happens when an error occurs and where the user can see the status of a particular process.
Example: the online order flow
One of the key elements of the analysis was describing the order flow. Such a diagram is not merely a technical illustration. It is a tool for discussion with both the business and the implementation partner.
Such a diagram helps establish:
- when an order is considered accepted,
- when inventory is reserved,
- who is responsible for picking,
- when the sales document is created,
- when the courier label is generated,
- when the status is returned to the online store,
- what happens if the WMS reports insufficient stock,
- how an order cancellation or modification is handled,
- how a return at a physical location is handled.
Only once the process has been described at this level does it make sense to discuss technical API requirements, field mapping, statuses, error messages and test scenarios.
Sources of truth: the most important decision in integration
One of the most common problems in integration projects is the lack of a clear answer to one question: which system is the source of truth?
If a product exists in the online store, ERP and WMS, it must be clear where it is maintained as the authoritative record. If a price can be changed in several places, one system must be given priority. If inventory is displayed online, it must be clear whether it comes from the ERP, WMS, integration platform or a separate availability mechanism.
This apparently simple decision has major practical consequences. Without it, a company may end up with several versions of the same product, different inventory levels and inconsistent order statuses.
A well-designed integration is not simply about transferring data. It is about knowing which data is authoritative, when it may be changed and which system is responsible for its correctness.
What should the analysis deliver?
The outcome of the analysis should not be a general statement such as “the systems should be integrated”. That is not enough for an implementation partner to design and deliver the solution safely.
A good analysis should produce, among other things:
- a description of the current process,
- a description of the target process,
- a list of systems and their responsibilities,
- a source-of-truth model,
- a description of the order flow,
- a description of inventory flows,
- a description of sales and warehouse document flows,
- a description of exception handling,
- functional requirements for the integrations,
- API requirements,
- process and data-flow diagrams,
- test scenarios for key cases.
This means the implementation partner does not receive only a loosely defined business expectation. It receives material that can be used to design a concrete technical solution.
Common mistakes when integrating sales and warehouse systems
1. Starting with technology instead of the process
The question “how should we connect the systems?” is important, but it should come after “how should the process work?”. Otherwise, the integration may simply reproduce the existing chaos.
2. No single source of truth
If it is unclear which system is responsible for products, prices, inventory and documents, inconsistencies will eventually appear.
3. Ignoring exceptions
The standard order flow is only one part of the process. Returns, cancellations, stock shortages, corrections, warehouse transfers and physical retail sales also need to be described.
4. Excessive dependence on manual spreadsheets
Excel often helps at the beginning, but at a larger scale it becomes a place where an alternative data flow starts to emerge.
5. No common language between the business and the implementation partner
The business describes its needs in operational terms, while the implementation partner needs technical requirements. The role of analysis is to translate one language into the other.
What did the company gain?
The result of the work was a structured integration model and a description of the order fulfilment process that could be used during the subsequent implementation.
The main outcomes included:
- a clear division of responsibilities between systems,
- a structured data-flow model,
- a better understanding of where data should be created and updated,
- reduced manual work,
- lower risk of errors in order processing and picking,
- documentation prepared for the implementation partner,
- a foundation for further API interface design,
- better control over sales, warehouse operations and documents.
It is worth emphasising that this type of analysis is not merely an addition to the implementation. In practice, it is one of its most important stages because it helps avoid costly changes later in the project.
Lessons for companies planning a similar integration
If a company uses several sales, warehouse and accounting systems, it is worth answering a few questions before implementation begins.
- Do we know which system is the source of truth for products?
- Do we know where prices come from?
- Do we have a clearly defined source for inventory levels?
- Do we know where an order is created and where it is processed afterwards?
- Are online and physical retail sales described as parts of one process?
- Do the WMS, ERP and integration platform have clearly defined roles?
- Have returns, cancellations and stock shortages been described?
- Do we know when the sales document is created?
- Is the order status returned to the sales channel?
- Has the implementation partner received specific requirements rather than only a general description of the need?
If the answers to these questions are unclear, it is worth stopping before implementation and structuring the process first.
Summary
Integrating WMS, ERP, e-commerce and physical retail is not merely a technical task. Above all, it is a process and analysis project.
A good implementation starts by defining how the company should operate: where orders are created, which system is responsible for inventory, where documents are generated, how exceptions are handled and which systems are the sources of truth for particular types of data.
Only then is it safe to design APIs, data mappings, automation and further system configuration.
If analysis is skipped, integration may only make the existing chaos move faster. If it is done well, the systems begin to support the process instead of complicating it.
