ERP voedingsindustrie: waarom ERP niet genoeg is
Een ERP is goed in dingen tellen. Inkooporders, voorraadmutaties, facturen, leveringen. Het is daarvoor gebouwd en het doet het uitstekend. Maar in de voedingsindustrie zit het werkelijke werk ergens anders: in wat er in je producten gaat en wat er op het etiket terechtkomt. En precies daar laat een ERP je in de steek.
Dat is geen aanval op ERP. Het is een observatie over architectuur. Een systeem dat is gebouwd voor transacties kan niet plotseling de logica van een productlevenscyclus dragen. Toch proberen voedingsbedrijven dat al jaren, met voorspelbare gevolgen: een Excel naast het ERP, een Word-document erbij, en een QA-manager die als enige nog weet hoe alles in elkaar past.
Wat je ERP wél goed doet
Even iets rechtzetten: een ERP is onmisbaar. Inkoop, voorraad, productieplanning, facturering, verzending. SAP, Exact, Microsoft Dynamics, Infor, ze zijn er goed in en je wilt er niets aan veranderen. Een ERP regelt je operatie en dat moet zo blijven.
Het wringt pas zodra de leverancier erbij zegt: "We hebben ook een module voor receptuurbeheer hoor." Of: "Wij zijn een food ERP, dat zit erin." Of: "Productspecificaties kun je ook bij ons kwijt." Technisch klopt het allemaal. In de praktijk loop je op drie dingen vast.
Je ERP kent geen ingrediëntenboom
Pak je aardappelsalade. Erin zit een dressing, in die dressing zit gepasteuriseerd eigeel, en in dat eigeel zit citroenzuur. Drie lagen diep. En elke laag telt mee in je ingrediëntendeclaratie, in de juiste volgorde, met de juiste percentages.
Wat je ERP ziet is iets anders: "aardappelsalade, 7 componenten." Punt. Geen boom, geen doorrekening, geen wettelijke volgorde. Je krijgt een platte lijst, terwijl je etiket een geneste structuur vraagt.
Je ERP berekent geen voedingswaarden
De voedingswaardedeclaratie op je etiket rolt uit je receptuur. Energie, vetten, koolhydraten, eiwitten, zout: de Big 7, per 100 gram en per portie, met de afrondingsregels uit EU 1169/2011. Wijzigt er een grondstof, dan schuiven de waarden van elk product waar die grondstof in zit.
In een ERP gaat dat anders. Daar typ je voedingswaarden handmatig in en blijven ze staan. Een leverancier past zijn samenstelling aan en niemand merkt het, omdat niemand die waarden opnieuw uitrekent. Tot de NVWA langskomt en de getallen op het etiket niet meer kloppen met wat er in het pak zit.
Je ERP kent geen allergenen
14 allergenen moeten op het etiket. Niet alleen "bevat", maar ook "kan sporen bevatten van." Dat tweede is precies waar het lastig wordt, want kruisbesmetting moet je doorrekenen vanaf elke grondstof, door elke laag van de boom, met contaminatiewaarden en referentiedosissen per allergeen.
Je ERP weet misschien dat één grondstof gluten bevat. Wat dat betekent voor je eindproduct waarin die grondstof via een sub-receptuur op 2% zit, daar stopt het. En dus komt er weer een Excel naast. Twee systemen, geen verbinding, en jij ertussen.
Vijf jaar implementeren, één jaar relevant
Een ERP-implementatie is geen project. Het is een meerjarentraject. Eerst de selectie, dan de blauwdrukken, dan de bouw, de migratie, de nazorg. Ondertussen zit er wekelijks een projectgroep bijeen om voortgang te bespreken op slides die niemand later terugziet.
En je kwaliteitsafdeling? Die wacht. Op de receptuurmodule die "ergens in fase 4 komt". Op de allergenenfunctionaliteit die de leverancier in de demo heeft beloofd maar in de praktijk niet blijkt te bestaan. Op de specificatie-uitvoer die "in de roadmap staat". En terwijl iedereen wacht, draaien de etiketten gewoon door. Op Excel.
Dit zien we keer op keer: bedrijven die halverwege hun ERP-traject Eclarion erbij halen, omdat het kwaliteitsdeel niet komt of niet werkt zoals beloofd. Of pas in versie 3 verschijnt, over twee jaar.
En zodra dat ERP eindelijk live gaat? Dan is de wetgeving veranderd, zijn er nieuwe afzetmarkten bijgekomen met andere etiketteisen, en is het pakket zelf al een release achter. Met een gespecialiseerde tool ernaast pas je dat binnen een week aan. Met één grote moloch begin je opnieuw.
En dan is er nog de sunk cost. Honderdduizenden, soms miljoenen aan licenties, consultancy en interne uren. Op het moment dat duidelijk wordt dat het kwaliteitsdeel niet werkt, is teruggaan geen optie meer. Dus stapelt het bedrijf workarounds: een Excel hier, een losse tool daar, een handmatige check ertussen. Het systeem dat alles zou oplossen, is precies het systeem waar je niet meer vanaf komt.
De manier om hier omheen te komen is best-of-breed: in plaats van één moloch die alles probeert te doen, pak je per domein de beste tool. Voor productdata is dat een gespecialiseerde Food PLM zoals Eclarion, die je in dagen inricht en in een week aanpast als de wetgeving verschuift of er een nieuwe afzetmarkt bijkomt. Verandert er over twee jaar weer iets, dan doe je het opnieuw. In een week, niet in vijf jaar.
De Excel-schaduw
Elk voedingsbedrijf met een ERP heeft een schaduw-administratie. Het ERP is de officiële waarheid, de productkennis zit ergens anders. In Excel voor de recepturen, met formules die niemand meer durft aan te raken in een tabblad "definitief_v3". In een apart bestand voor de allergenen, bijgewerkt als iemand eraan denkt. In Word voor de productspecificaties, met copy-paste uit de Excel. En in een mailbox voor wat leveranciers ooit hebben opgegeven.
De QA-manager weet het. De directie niet. Tot een auditor vraagt: "Laat me de audit trail van deze specificatiewijziging zien." Die trail loopt van het ERP naar Excel naar een mail naar Word naar een Sharepoint-map. Dat is geen trail, dat is een speurtocht.
Wat je naast je ERP nodig hebt
Een groter ERP gaat dit niet oplossen. Je hebt een systeem nodig dat doet wat je ERP niet kan: productdata beheren, doorrekenen en op het etiket krijgen. Dat is precies wat een Food PLM doet.
Het verschil zit in hoe ze gebouwd zijn:
| ERP | Food PLM | |
|---|---|---|
| Stuklijst | Platte lijst met artikelen en hoeveelheden | Geneste boom met sub-recepturen, percentages, QUID |
| Voedingswaarden | Handmatig invoeren | Automatisch berekenen vanuit de receptuur |
| Allergenen | Registreren per artikel | Doorrekenen door de hele boom, inclusief kruisbesmetting |
| Etikettering | Niet | Ingrediëntendeclaratie en voedingswaardedeclaratie |
| Wijziging doorvoeren | Handmatig per product | Automatisch naar alle recepturen waar de grondstof in zit |
| Audit trail | Beperkt (transacties) | Volledig (wie, wat, wanneer, op productniveau) |
De twee systemen vullen elkaar aan via een API. Je ERP blijft je operationele ruggengraat. Je Food PLM beheert wat erin zit en wat erop staat.
En je ERP en Food PLM, hoe werken die samen?
Niet door één systeem te zijn, en ook niet door elkaar te negeren. Ze praten met elkaar via een API, en ze hebben allebei iets wat de ander nodig heeft. Vanuit je ERP rolt artikelstamdata naar binnen: codes, omschrijvingen, leveranciers, inkoopprijzen, batches. Vanuit je Food PLM gaat er stuklijsten, netto-inhoud, verpakkingsdata en artikelkenmerken terug, zodat je productie en logistiek weten waar ze mee werken.
In Eclarion loopt dat via een REST API. Geen nachtelijke CSV-exports, geen handmatig overtypen. Pas je een receptuur aan, dan ziet je ERP de nieuwe stuklijst meteen. En de traceerbaarheid loopt door allebei: je weet welke batch in welk product zat, en welke specificatie er destijds gold.
Veelgestelde vragen
Kan ons ERP receptuurbeheer niet gewoon zelf?
Een ERP kan een stuklijst beheren. Maar een stuklijst is geen receptuur. Een receptuur heeft percentages, geneste sub-ingrediënten, voedingswaardeberekeningen, allergenendoorberekening en etiketteringslogica. Die functionaliteit zit niet in een ERP, ook niet in de "food module."
Moeten we ons ERP dan vervangen?
Nee. Je ERP blijft staan. Een Food PLM komt ernaast en neemt het deel over waar je ERP niet voor gebouwd is: productdata en compliance. Via een API werken ze samen, allebei in hun eigen domein.
Wat als onze ERP-leverancier zegt dat ze dit ook kunnen?
Vraag een demo. Laat ze live een receptuur van drie niveaus diep aanmaken, de voedingswaarden automatisch doorrekenen, de 14 allergenen door de boom laten lopen en er een productspecificatie als PDF uit halen. Lukt dat niet, dan heb je je antwoord. En als ze zeggen "dat komt in de volgende release", vraag dan welke. En wanneer.
We zitten middenin een ERP-implementatie. Is het te laat voor Eclarion?
Integendeel, dit is juist het moment. Je kwaliteitsteam kan vandaag al starten met Eclarion, terwijl het ERP-traject doorloopt. Geen wachten op fase 4, geen afhankelijkheid van een module die misschien wel of niet komt. En zodra het ERP straks live gaat, koppel je de twee via de API. Dan heb je het beste van twee werelden in plaats van twee halve oplossingen.
Is de overstap niet heel complex?
De overstap valt mee, omdat je ERP gewoon blijft draaien. Wat je vervangt is de schaduw-administratie: de Excels, de Word-bestanden, de losse allergenenlijsten. Met Eclarion ben je binnen dagen operationeel, niet maanden.
Wat kost dat naast ons ERP?
Minder dan de uren die je nu kwijt bent aan handmatig bijwerken, controleren en herstellen. Een QA-manager die twee dagen per week bezig is met Excel-onderhoud, dát is de werkelijke kost. Bekijk de prijzen of start een gratis proefperiode.
Laat je ERP doen waar het goed in is
Je ERP draait je operatie. Daar is het sterk in en daar moet het blijven. Maar receptuurbeheer, allergenen, etikettering en compliance zijn een ander vak. Probeer je dat in je ERP te proppen, dan eindig je met de schaduw-administratie die elke QA-manager kent: drie Excels, twee Word-bestanden en een bak vol e-mails.
Met Eclarion beheer je wat in je producten zit en wat erop het etiket komt, gekoppeld aan je ERP via een API. Eén bron, één berekening, één audit trail. Start een gratis proefperiode en ervaar het verschil.