A global manufacturer in nutrition, health and beauty runs production from five factories on four continents - Belgium, Switzerland, China, Turkey, and the United States. All five report into a single SAP ECC core for production execution data.

But the MES landscape on the plant floor isn't single. Some sites run TRAKSYS. Others run PREACTOR. Each plant had grown its own way before the group ever needed them to talk to a common ERP.

The integration question wasn't whether the plants could be connected to SAP. It was whether they could be connected without producing a custom integration project per plant - which would scale into a maintenance burden that grew with every new factory.

Challenge

Five challenges sat on top of each other, and any one of them could have shaped the architecture in a way the next one would later fight against.

One SAP core, multiple continents. A single SAP ECC instance served plants in Belgium, Switzerland, China, Turkey, and the United States. The integration pattern had to be tolerant of network distance, time zones, and the operational rhythms of plants that were not on the same calendar.

A heterogeneous MES landscape. TRAKSYS at some plants. PREACTOR at others. The reasons were historical - local decisions made before group-level integration was on the table and forcing a single MES on every plant was not the goal. The integration had to be agnostic to which MES sat behind it.

Always-on data flows. Production execution can't wait. There was no acceptable nightly-batch fallback for plant-to-ERP transactions - the operational tempo demanded near-real-time integration with the resilience to absorb network and system variability without losing transactions.

Full traceability across every transaction. Every plant-to-ERP message had to be auditable end-to-end. For a regulated industry with traceability obligations stretching from raw material to finished product, this was non-negotiable.

A repeatable rollout model. The architecture had to support the next plant being added in months, not years. Group-level M&A and organic expansion would keep adding sites. Each new plant could not mean a new integration development project.

The five together pointed away from a per-plant integration approach. They pointed toward a single architectural pattern that every plant would conform to.

Solution

The architectural choice was to refuse the per-plant pattern entirely.

Instead of building five point-to-point integrations and then a sixth, and a seventh, and so on as new factories joined the integration was built around a canonical data model. SAP IDOCs flow into the integration layer, where they're transformed into a consistent intermediate XML format that represents production-execution data in a plant-agnostic way. From the canonical layer, the data is routed to TRAKSYS or PREACTOR depending on which MES the receiving plant runs.

The key word in that sentence is routed, not transformed. The routing decision is made by configuration, not by code. Adding a new plant doesn't mean writing new integration logic. It means adding a configuration entry that tells the platform which MES the new plant uses, and the existing canonical layer handles the rest.

webMethods Integration Server sits at the centre of the architecture. It consumes the SAP IDOCs, runs the transformation to canonical XML, and orchestrates the downstream flows to whichever MES the routing rule identifies. ActiveTransfer handles the file-based document exchange where managed file transfer is part of the flow. Monitoring, retry, and replay tooling are built in so that operational support doesn't require developer intervention every time a transaction needs attention.

The whole architecture is built on a single bet: that the cost of designing a canonical model upfront and disciplining every plant integration to flow through it pays back many times over when the sixth plant comes.

Delivery Approach

The rollout was sequenced by factory, not concurrent. Each plant was integrated, validated against live production rhythm, and only then was the next plant initiated. This protected each plant's go-live from being entangled with another plant's issues, and it gave the operational support model time to mature before scale increased.

Inside that sequencing, the shared service contract was defined once. Every plant integration honoured the same contract; plant-specific behaviour was handled through configuration, not through code branches. There are no per-plant forks of the integration logic to maintain - the same core code runs everywhere.

Results

Five factories integrated across Belgium, Switzerland, China, Turkey, and the United States - all connecting into the same SAP ECC core through the same canonical integration layer.

Two MES platforms served through a single integration framework. TRAKSYS plants and PREACTOR plants run on the same underlying integration code. The difference between them lives in configuration, not in code.

41 integration points established between plant operations and SAP. Every one of them flows through the canonical model.

Zero code forks. All plants run from the same core integration logic. There is no per-plant version of the code to maintain, no parallel branches drifting from each other, no integration team responsibility that grows linearly with the number of plants.

The sixth plant in India is planned for 2026. It will join the architecture as a configuration exercise, not a development project. That is the proof the architectural bet paid back.

The integration estate now scales with the business at a rate the business itself controls. Each new plant adds operational scope, not engineering scope.