Een datafundament voor food en productie
In food en productie draait de dataomgeving zelden om één systeem. Er is een ERP, meestal SAP, en daaromheen MES, kwaliteit, planning, magazijn en een reeks cloudapplicaties. Zodra dat ERP verandert — en dat gebeurt — mag de informatievoorziening niet stilvallen. Dat lukt alleen als de integratielaag los staat van het ERP.
Laatst bijgewerkt:
Waarom een ERP-migratie je datalandschap raakt
Omdat bij een migratie niet alleen het ERP verandert, maar ook alles wat eraan hangt. Elke koppeling, elke rapportage en elke afgeleide tabel is gebouwd op de structuur van het oude systeem. Ga je die één voor één omzetten, dan loopt het bestaande landschap vast op het moment dat je het het hardst nodig hebt: tijdens de overgang blijft de business gewoon om cijfers vragen.
De uitweg is de integratielaag losknippen van het ERP. Bronnen landen dan op een laag die zijn eigen structuur en historie beheert, en de rapportages lezen van die laag in plaats van rechtstreeks uit het ERP. Verandert het bronsysteem, dan verandert de koppeling — niet de honderd rapporten erachter.
Wat je uit SAP haalt, zonder middleware van derden
Yres sluit op SAP aan via de standaarden van SAP zelf. Er is geen aparte integratiesuite of connectorlicentie van een derde partij nodig; de verbinding loopt over de interfaces die SAP zelf publiceert.
- De koppeling leest; er wordt niets in SAP gewijzigd
- Inloggegevens staan in de Key Vault van je eigen tenant, niet in een pipeline of een script
- Naast SAP sluiten MES-, kwaliteits- en planningssystemen aan via hun database, REST of OData, en bestanden via SharePoint, een fileserver, Blob Storage of Data Lake
| Route | Waarvoor |
|---|---|
| OData en XS OData | de reguliere weg naar SAP-services, inclusief metadata uit de servicebeschrijving |
| SAP Business Data Cloud | voor landschappen waar BDC de ontsluitingslaag is |
| SAP Datasphere | als je gemodelleerde views al in Datasphere staan |
| SAP Analytics Cloud | voor gegevens die daar al beschikbaar zijn gesteld |
Migratie en dagelijkse operatie naast elkaar
Een ERP-migratie betekent niet dat de informatiebehoefte stopt. Tijdens het traject blijven bestaande rapportages in gebruik en komen er tegelijk nieuwe wensen bij. Door de data-integraties centraal te beheren, kun je wijzigingen in het nieuwe ERP-landschap doorvoeren terwijl de bestaande stromen beschikbaar blijven.
Dat vraagt om wijzigingsbeheer dat verder gaat dan een export van pipelines. Bij Yres wordt elke aanpassing automatisch als wijziging geboekt, binnen een project. Je geeft die vrij en installeert hem per omgeving, van ontwikkel naar test naar productie, inclusief de Data Factory-publicatie. Vrijgeven blokkeert op afhankelijkheden die nog niet vrij zijn, en vooraf zie je de impactanalyse of desnoods de SQL die uitgevoerd gaat worden. Ook wat iemand rechtstreeks in de database doet, wordt vastgelegd: wie, wanneer en het volledige commando.
Hoe dat er in de praktijk uitziet
Aviko, een internationale producent in de voedingsmiddelenindustrie, liep tijdens een grootschalige SAP ERP-migratie tegen precies deze vraag aan. Niet alleen het ERP veranderde; de hele dataomgeving moest beheersbaar blijven terwijl de organisatie gewoon doorwerkte. Aviko zette Yres in als centrale laag voor alle data-integraties binnen Azure.
Het effect: databronnen bleven beschikbaar, rapportages draaiden door en nieuwe systemen konden worden aangesloten zonder de continuïteit van bestaande processen in gevaar te brengen. In plaats van losse scripts en maatwerkintegraties worden bronnen vanuit één omgeving beheerd, gestandaardiseerd aangesloten en overzichtelijk gehouden, ook als de onderliggende systemen veranderen.
"We zochten niet alleen SAP-kennis, maar ook een manier om onze dataomgeving beheersbaar te houden tijdens de migratie."
De migratie bleek geen eindpunt maar het begin van een nieuwe fase: ook daarna veranderen systemen, komen er applicaties bij en ontstaan nieuwe informatiebehoeften. Een gestandaardiseerde omgeving maakt die veranderingen goedkoper, omdat je ze op één plek doorvoert.
Volume, historie en wat dat kost
Productiedata is omvangrijk en de vragen gaan bijna altijd over verloop: hoe ontwikkelde de uitval zich per lijn, wat was de doorlooptijd vorig kwartaal, welke leverancier schoof op in kwaliteit. Yres bewaart daarom de volledige historie volgens SCD2 — zes van de zeven laadtypen doen dat — en voegt gepagineerd samen, zodat tabellen van honderd miljoen rijen en meer verwerkbaar blijven.
Om de kosten in de hand te houden schaalt de database automatisch op rond een load en direct weer terug; gelijktijdige workflows stemmen daarbij onderling af, zodat de ene niet afschaalt terwijl de andere nog draait. Oudere jaargangen archiveer je per tabel naar Parquet in de Data Lake, waarbij pas verwijderd wordt nadat het aantal gekopieerde rijen exact klopt. Eén view voegt database en archief samen, zodat een meerjarige reeks compleet blijft.
Veelgestelde vragen
Hebben we een aparte SAP-connector of middleware nodig?
Nee. Yres sluit aan via de standaarden van SAP zelf: OData, XS OData, SAP Analytics Cloud, Datasphere en Business Data Cloud. Er is geen integratiesuite van een derde partij nodig. De koppeling leest alleen; er wordt niets in SAP gewijzigd.
Kunnen we Yres inzetten terwijl de ERP-migratie nog loopt?
Dat is juist het moment waarop het helpt. Doordat rapportages van de Yres-laag lezen in plaats van rechtstreeks uit het ERP, kun je het bronsysteem vervangen terwijl de bestaande stromen beschikbaar blijven. Aviko deed het precies zo.
Hoe gaat Yres om met tabellen van honderden miljoenen rijen?
De merge naar de historietabel werkt gepagineerd, zodat grote tabellen in behapbare delen verwerkt worden. Daarnaast schaalt de database automatisch op rond een load en weer terug, en kun je oudere jaargangen naar Parquet archiveren met één view over database en archief heen.
Wat gebeurt er met wijzigingen die iemand rechtstreeks in de database doet?
Die worden vastgelegd: wie, wanneer en het volledige commando. Elke aanpassing via Yres wordt bovendien automatisch als wijziging geboekt en gaat per wijziging naar test en productie, inclusief de Data Factory-publicatie.
Blijft onze data binnen onze eigen omgeving?
Ja. De Data Factory, de database, de sleutelkluis en optioneel de Data Lake staan in je eigen Azure-tenant, in de regio die je zelf kiest. Data, metadata, inloggegevens en geheimen blijven daar.
