De data bestaat al. Het probleem is de structuur.
Bijna elke productieomgeving heeft al een historian of SCADA die elke seconde meetwaarden wegschrijft. Het idee dat data 'ontbreekt' klopt zelden. Wat ontbreekt is de vertaling naar ERP-logica. Een historian registreert op milliseconde-niveau; een ERP boekt op orderniveau, soms per dag. Een PLC kent grammen; de inkoopafdeling werkt in kilogrammen. Een machine weet niets van een ordernummer. Al die verschuivingen klinken klein, maar samen zorgen ze ervoor dat de koppeling tussen shopfloor en ERP levert wat niemand wil: cijfers die formeel kloppen maar operationeel nergens op slaan.
Leermoment 1: tijdresoluties aligneren tussen historian en ERP-boeking
Een historian slaat waarden op per seconde of per event. Een ERP-boeking is een momentopname die gekoppeld is aan een order, een shift of een dag. Als je die twee direct op elkaar legt zonder aggregatielaag, gebeurt er iets onverwachts: je krijgt honderden kleine boekingen voor één order, of je verliest data omdat de tijdvensters niet overlappen. De oplossing is niet sneller boeken in ERP, maar expliciet definiëren welk tijdvenster bij welke order hoort. Dat klinkt voor de hand liggend, maar in de praktijk betekent het dat je met productie, planning én finance om tafel moet om te bepalen wat 'gereed' precies is en op welk moment de historian-waarden worden gesloten. Zonder die afspraak blijft de koppeling een technisch succes maar een operationeel mislukking.
Leermoment 2: gedeeltelijke batches die halverwege een shift worden afgesloten
Dit is het meest onderschatte probleem. Een order loopt over twee shifts, maar de eerste ploeg sluit de batch af op een moment dat de machine nog draait. Of een operator splitst handmatig omdat de grondstof net op is. In ERP bestaat dat moment niet: daar is de order open of afgesloten. De historian rapporteert gewoon door. Het gevolg is een gat: productievolume dat bestaat in de sensor-data, maar nergens in ERP terugkomt. Je lost dit op door een bufferlaag te bouwen die weet wanneer een operator een batch-split heeft ingevoerd, en die de historian-data dienovereenkomstig knipt en labelt. Dat vereist een expliciete interface voor de operator, liefst één klik op de HMI of een eenvoudig scherm op de tablet, geen los Excel-bestand achteraf. Zonder die invoer werkt elke koppeling blind op de splitsmomenten die er het meest toe doen.
Leermoment 3: wanneer een directe ERP-koppeling averechts werkt
De redenering is begrijpelijk: zet een directe verbinding tussen historian en ERP, en data stroomt realtime door. In de praktijk heeft die aanpak een zwakte die pas zichtbaar wordt als er iets misgaat. ERP-systemen zijn niet ontworpen voor de schrijffrequentie van een historian. Een directe push leidt tot time-outs, gecorrumpeerde boekingen of een ERP die trager wordt op het moment dat de productie het hardst loopt. Buffering is dan niet een compromis, maar de betere keuze. Een lichte middleware-laag die berichten verzamelt, valideert en in batches naar ERP stuurt, maakt het systeem robuuster en het ERP beheersbaar. Die laag hoeft niet complex te zijn: een eenvoudige wachtrij met validatieregels is voldoende. De directe koppeling is aantrekkelijk in het ontwerp, maar in productie-omgevingen met hoge schrijffrequentie is gebufferde synchronisatie betrouwbaarder.
Wanneer is een volledige heropbouw van het kernsysteem de betere weg?
Koppelingen bouwen op bestaande systemen werkt goed als het ERP-fundament solide is en de problemen alleen aan de integratie-laag liggen. Maar als het ERP zelf het model niet ondersteunt, als ordernummers niet kloppen met de werkelijkheid op de vloer, of als er al drie laagjes middleware omheen zijn gebouwd die niemand meer begrijpt, dan is het moment aangebroken om te overwegen of je het kernsysteem niet beter opnieuw kunt bouwen. Dat klinkt zwaar, maar een AI-native systeem dat vanaf de basis rekening houdt met shopfloor-data, batch-splits en tijdresoluties, levert uiteindelijk minder onderhoud op dan een ERP met zeven koppelingen eromheen. De keuze hangt af van hoe diep het datamodel-probleem zit, niet van hoeveel data er al in het bestaande systeem staat.