Data Unification: How Three Industrial Giants Solved a Costly Problem

The not-so-hidden data problem

Ask any OT engineer or manufacturing IT manager what they spent last week on, and some version of this comes up: pulling data out of a SCADA system, reformatting it to match what the ERP expects, writing a script to bridge two systems that have never talked to each other, then maintaining that script when one of the upstream systems gets updated.

The data exists. Too much of it. What does not exist is a coherent way to access it.

Production data sits in OT historians that the IT layer cannot easily reach. Process parameters live in SCADA systems that do not share a data model with the MES. Batch records are assembled from three different sources, reconciled manually. Only to not be trusted by anybody.

Meanwhile an AI initiative on the roadmap has been blocked for six months because the data it needs is not clean, not structured, and not in one place.

This is the default state of most industrial manufacturers. The costs are measured in engineering hours, delayed decisions, and digital transformation programmes that never get past the pilot.

The three companies below had this problem at scale. Here is what changed when they solved it.

The costs of fragmentation

Before looking at the solutions, it is worth looking briefly at what data fragmentation actually costs. Of course, it doesn’t show up as a line item. If only it were that easy.

Engineering time that is diverted to integration work. Every data silo creates a connection requirement. Every connection requirement becomes a custom script, a manual export, or an IT ticket. That work is invisible on a P&L, but it is real: OT engineers often find themselves spending hours every week maintaining brittle integrations instead of improving processes. IT managers spend time managing a patchwork vendor landscape instead of building towards a coherent architecture. Process engineers wait days for data extracts that should take seconds.

Delayed decisions. Fragmented data means that by the time an analysis is ready, think cross-site batch yield, energy per production run, a root cause investigation, the production window it was meant to inform has already closed. Decisions eventually get made on gut feel or on yesterday's numbers. Quality issues might get noticed too late. And maintenance interventions only happen after the failure.

Innovation that never starts. Perhaps the most expensive cost of data silos is the projects that never happen. For example, predictive maintenance requires clean, consistent asset data. AI-driven quality control requires structured batch records. Cross-site benchmarking requires a common data model. Without a unified data foundation, every new initiative starts from the same place: a months-long data cleaning exercise before any actual work can begin.

Compliance risk. When a customer complaint arrives or an audit begins, scattered process data across disconnected systems means hours of manual search through paper records and SQL exports. In regulated industries, that can be a liability.

Here’s the TL;DR. The fragmentation tax is paid continuously, by every department, every day. It just rarely has a name.

How Lesaffre solved their data transformation problem

Lesaffre Group is one of the world's largest fermentation companies with €2.2 billion in annual revenue and production sites across every continent. They make yeasts and bacteria for baking, health, and biotechnology.

At one site in the OCEA region, the specific problem was data transformation. Raw time-series data from production systems needed to be converted into aggregated, structured formats for operational and business analysis. The existing method: custom Excel macros and Microsoft SQL integration scripts, built over time, complex, difficult for anyone other than their author to understand, and impossible to replicate across sites at scale.

Regional Project Manager Rastislav Potocny was direct about the situation: "Transformation of raw data was done through custom Excel and Microsoft SQL integration scripts, which were often very complex and quite difficult to understand."

The goal of the pilot was narrow and specific: replace those scripts with a configurable, repeatable approach. Detect production events like batches, CIP cycles, orders automatically and write the resulting structured data into an open PostgreSQL database without custom development.

The result was event detection configured through a visual interface, with data landing in a standard SQL format that any downstream system could consume directly. No developer required to maintain it. No breakage when an upstream system changes. And because the configuration is portable, the same approach can be deployed across other Lesaffre sites with minimal effort, which matters at 11,000 employees across multiple continents.

The data governance implication is significant: the IT layer now has a consistent, queryable record of production events, in an open format, without depending on a person who built a script three years ago and may no longer work there.

How Puratos solved their data integration problem

‍

Puratos is a global producer of ingredients for the bakery, patisserie, and chocolate industries, operating manufacturing sites across Europe, the Americas, and Asia.

Their version of the data problem was one of scale and standardisation. Local data access existed at individual sites, but there was no centralised view across plants. For anyone trying to benchmark performance across a global network, or replicate a process improvement from one site to another, the data landscape was fragmented by design.

Puratos rolled out Factry Historian across more than 20 global sites, replacing isolated local access with a centralised, open platform for automated data collection, integration, and visualisation.

The specific outcomes: real-time access to process data across plants in Europe and North America, a common data model that makes cross-site comparison possible without manual reconciliation, and an open API that connects the historian to existing infrastructure instead of requiring a rip-and-replace of systems already in production.

For the head of digital, this is the architecture that makes everything else possible. Once the data foundation is consistent across sites, cross-site benchmarking is a query away. Replicating a best practice identified in Belgium, for example, to a site in North America is a configuration task, not a six-month integration engagement.

Deployment speed mattered too. A platform requiring months of bespoke implementation at each site is not viable at Puratos's scale. Which is why the ability to roll the same configuration across sites quickly and consistently was a prerequisite for them.

How Algist Bruggeman solved their data accessibility problem

Algist Bruggeman, also part of the Lesaffre Group, supplies yeast to industrial bakeries, breweries, and the pharma industry from a Belgian site employing around 170 people and generating over €120 million in annual revenue.

Their data problem started further back than most. Process data used to be collected on paper. Fermentation parameters were recorded manually by operators, then transferred by hand into different systems. It was time-consuming, error-prone, and made batch comparison effectively impossible.

Automation Manager Ivo Lemmens described the starting point: "Our primary goal was to deliver accurate process data to the top IT layer of production. As our proprietary historian system lacked flexibility, we needed a data management solution that would make process data accessible for any department: from maintenance over to procurement and production."

The existing historian was the other part of the problem. It was proprietary, inflexible, and could not serve data to the systems and teams that needed it without custom work for each connection.

The replacement: Factry Historian collecting high-resolution process data from PLCs, stored in InfluxDB, visualised through Grafana, and integrated with LIMS, ERP, and planning systems. Not point-to-point integrations for each connection, but a single layer that each system connects to once, and that serves data to everyone from there.

The practical outcomes were immediate. Real-time machine monitoring let the maintenance team detect valve degradation before failure, rather than after. The process team could compare any batch against a reference curve without an IT request. Material Requirements Planning visualisations let procurement track batch material consumption with accuracy that paper records could never provide.

Lemmens summed up the shift: "Whereas we used to make a lot of decisions based on gut feeling, we can now compare objective production data from different sources."

The engineering team no longer spends time maintaining a fragile proprietary historian and the custom connections around it. The data is there, it is structured, and any team can access it directly.

The common thread

Three different companies, three different starting points, one shared problem and one shared outcome.

The problem: data produced at the OT layer was not accessible to the people and systems that needed it without significant manual effort, custom integrations, or a long IT queue.

The outcome: a historian layer that sits between OT and IT, collects from any source via standard protocols, structures data consistently against an asset hierarchy, and exposes it through open interfaces. So that process engineers, ERP systems, BI tools, and AI pipelines can all access what they need without a bespoke project for each connection.

For the IT manager, this means one platform to govern and secure, with role-based access control and standard protocols, rather than a fragmented landscape of point solutions and the vendor relationships that come with them.

For the OT engineer, it means integrations that hold when upstream systems change — because the historian connects to systems via OPC-UA, MQTT, and Modbus, not via custom scripts that need rewriting every time something upstream gets updated.

For the head of digital, it means a data foundation that was built once and compounds over time rather than rebuilt at the start of every analytics initiative.

The compounding effect

One pattern across all three cases: the initial use case was not the last one.

Lesaffre started with automated event detection to eliminate integration scripts. The same foundation now makes predictive maintenance and cross-site operational benchmarking viable — because the data is already structured and in one place.

Algist Bruggeman started with replacing paper records. The same system now drives MRP visualisations, cross-department reporting, quality comparison against the golden batch, and continuous improvement workflows that did not exist before.

Puratos started with multi-site visibility. With a common data model now in place across 20+ sites, the groundwork exists for what comes next: cross-site benchmarking, process replication, and analytics that require the same data to mean the same thing everywhere.

Here's what the compounding effect looks like: A unified data foundation solves a category of problems, and the marginal cost of each new use case built on top gets lower as the foundation matures.

The integration scripts, Excel macros, and custom SQL transformations each cost engineering time every time they are written, maintained, or break. A historian that sits in the middle (collecting from any source, serving to any consumer, structured consistently across sites) pays for itself not in one use case but in every use case that follows.

Want to see how Factry Historian can handles data unification in your environment: factry.io/book-a-demo

‍