A data foundation for food and manufacturing
In food and manufacturing the data landscape rarely revolves around one system. There is an ERP, usually SAP, and around it MES, quality, planning, warehousing and a string of cloud applications. The moment that ERP changes — and it will — the flow of information cannot stop. That only works if the integration layer sits apart from the ERP.
Last updated:
Why an ERP migration hits your data landscape
Because a migration changes not only the ERP but everything hanging off it. Every connection, every report and every derived table is built on the old system's structure. Convert them one by one and the existing landscape stalls exactly when you need it most: throughout the transition the business keeps asking for figures.
The way out is to cut the integration layer loose from the ERP. Sources then land on a layer that manages its own structure and history, and reports read from that layer instead of straight out of the ERP. When the source system changes, the connection changes — not the hundred reports behind it.
What you get out of SAP, without third-party middleware
Yres connects to SAP through SAP's own standards. No separate integration suite or third-party connector licence is required; the connection runs over the interfaces SAP publishes itself.
- The connection reads; nothing is changed in SAP
- Credentials live in the Key Vault of your own tenant, not in a pipeline or a script
- Alongside SAP, MES, quality and planning systems connect through their database, REST or OData, and files through SharePoint, a file server, Blob Storage or Data Lake
| Route | What for |
|---|---|
| OData and XS OData | the regular path to SAP services, including metadata from the service description |
| SAP Business Data Cloud | for landscapes where BDC is the exposure layer |
| SAP Datasphere | when your modelled views already live in Datasphere |
| SAP Analytics Cloud | for data already made available there |
Migration and daily operations side by side
An ERP migration does not stop the need for information. Existing reports stay in use throughout, and new requests arrive at the same time. By managing the data integrations centrally you can push changes into the new ERP landscape while the existing flows stay available.
That calls for change management that goes beyond exporting pipelines. With Yres every edit is booked as a change automatically, within a project. You release it and install it per environment, from development to test to production, including the Data Factory publish. Releasing blocks on dependencies that have not been released yet, and beforehand you see the impact analysis or, if you prefer, the SQL about to run. What someone does directly in the database is recorded too: who, when and the full command.
What that looks like in practice
Aviko, an international producer in the food industry, ran into exactly this question during a large-scale SAP ERP migration. It was not only the ERP that changed; the whole data environment had to stay manageable while the organisation simply kept working. Aviko deployed Yres as the central layer for all data integrations within Azure.
The effect: data sources stayed available, reports kept running, and new systems could be connected without endangering the continuity of existing processes. Instead of loose scripts and bespoke integrations, sources are managed from one environment, connected in a standardised way and kept surveyable, even when the underlying systems change.
"We were not only looking for SAP knowledge, but also for a way to keep our data environment manageable during the migration."
The migration turned out to be not an end point but the start of a new phase: systems keep changing afterwards too, applications get added and new information needs appear. A standardised environment makes those changes cheaper, because you make them in one place.
Volume, history and what it costs
Manufacturing data is bulky and the questions are almost always about change over time: how did scrap develop per line, what was last quarter's lead time, which supplier moved up on quality. So Yres keeps the full history as SCD2 — six of the seven load types do — and merges in pages, keeping tables of a hundred million rows and more workable.
To keep cost in hand the database scales up around a load and straight back down again; concurrent workflows coordinate, so one will not scale down while another is still running. Older years are archived per table to Parquet in the Data Lake, where deletion only happens after the number of copied rows matches exactly. One view combines database and archive, so a multi-year series stays complete.
Frequently asked questions
Do we need a separate SAP connector or middleware?
No. Yres connects through SAP's own standards: OData, XS OData, SAP Analytics Cloud, Datasphere and Business Data Cloud. No third-party integration suite is required. The connection only reads; nothing is changed in SAP.
Can we deploy Yres while the ERP migration is still running?
That is precisely when it helps. Because reports read from the Yres layer instead of straight out of the ERP, you can replace the source system while existing flows stay available. Aviko did exactly that.
How does Yres handle tables of hundreds of millions of rows?
The merge into the history table works in pages, so large tables are processed in manageable parts. On top of that the database scales up around a load and back down again, and older years can be archived to Parquet with a single view across database and archive.
What happens to changes someone makes directly in the database?
They are recorded: who, when and the full command. Every edit through Yres is also booked as a change automatically and travels per change to test and production, including the Data Factory publish.
Does our data stay inside our own environment?
Yes. The Data Factory, the database, the key vault and optionally the Data Lake live in your own Azure tenant, in the region you choose. Data, metadata, credentials and secrets stay there.
