Eén fabriek, twee markten: hoe een bakkerijketen recepten en Dynamics 365 synchroon houdt

Elke ochtend steekt een croissant een grens over

Elke ochtend verlaten bestelwagens vol viennoiserie, sandwichbrood en taarten een productiefabriek en steken een landgrens over naar een naburige markt, nog voordat de eerste klant een winkel binnenloopt. De groep achter deze route is niet ongewoon: een regionaal bakkerij-cafémerk met een eigen winkelnetwerk, volgens het bedrijfsmodel dat gebruikelijk is bij ketens die in één land zijn ontstaan en uitgebreid zijn naar een buurland waar grond- en arbeidskosten lokale productie moeilijker schaalbaar maken. Het ene land produceert; het andere verkoopt vooral.

Commercieel werkt dat model. Operationeel ontstaat er een probleem dat zich stilletjes aandient, maanden nadat de eerste vrachtwagen de grens is overgestoken: de fabriek draait op recepten, en de groep draait op Microsoft Dynamics 365. Lange tijd spraken die twee systemen elkaars taal niet.

Wat Dynamics 365 weet — en wat niet

Dynamics 365 doet precies wat een voedingsproducent van een ERP verwacht: inkooporders bij meel- en boterleveranciers, ontvangstbonnen aan de dock van de fabriek, intercompany-facturering tussen de productie-entiteit en de verkoopentiteit aan de andere kant van de grens, voorraadwaardering en financiële consolidatie op groepsniveau. Daar valt niets op af te dingen — het financeteam van de fabriek beheert Dynamics 365 prima.

Wat Dynamics 365 niet weet, is wat er in de kneder gebeurt. Het registreert dat de fabriek 800 kilogram boter kocht tegen een bepaalde prijs. Het weet niet hoeveel boter in één croissant gaat, wat het rendement is na rijzen en bakken, wat de allergenenverklaring moet vermelden zodra die boter tarwebloem en eieren ontmoet, of hoe een receptwijziging voor de naburige markt — een lager suikergehalte om een betere voedingswaardescore op de voorkant van de verpakking te halen, bijvoorbeeld — de kostprijs per stuk verandert. Precies dat gat tussen wat finance ziet en wat de fabriek produceert, is waar twee problemen tegelijk ontstaan: kostendrift die finance pas aan het einde van de maand opmerkt, en allergenen- of voedingswaarde-etiketten die achterlopen op het werkelijke recept.

Een receptlaag tussen de oven en het grootboek

De oplossing is niet om Dynamics 365 te vragen een bakkerijsysteem te worden — het is daar nooit voor gebouwd, en het forceren ervan leidt precies tot het soort omweg dat de gegevensintegriteit van een ERP aantast. De oplossing is de fabriek een recept- en productielaag te geven die de taal van de fabriek spreekt — formuleringen, rendementen, deelrecepten, batchgroottes — en die automatisch aansluit op de taal van Dynamics 365: inkooporders en voorraadmutaties.

In de praktijk betekent dat: de referentieformulering van elk product — het masterrecept met zijn ingrediënten, bakkerspercentages en processtappen — leeft op één plek, gedeeld tussen beide markten. Wanneer een bakker in de fabriek een recept aanpast (een andere vetmix, een geherformuleerde vulling), herberekent het systeem in dezelfde beweging: de allergenenverklaring, de voedingswaarden die nodig zijn voor de etiketteringseisen in de naburige markt, en de werkelijke kostprijs per stuk op basis van ingrediëntprijzen die al binnenkomen vanuit de inkoopgegevens van Dynamics 365. Die berekende uitkomst — de standaardkostprijs van een eindproduct — vloeit vervolgens terug in Dynamics 365 als basis voor voorraadwaardering en intercompany-verrekenprijzen, in plaats van een handmatig bijgehouden schatting die stilletjes verouderd raakt zodra een leverancier zijn prijs wijzigt.

Compliance reist mee met het recept, niet erachter aan

Voor een fabriek die naar een tweede markt verscheept, telt dit dubbel. Twee naburige markten delen zelden identieke etiketterings- en voedselveiligheidseisen, en een receptwijziging voor een van hen — minder suiker om de voedingswaardescore op de voorkant van gebak te verbeteren, bijvoorbeeld — moet overal doorwerken waar het recept wordt gebruikt: het etiket dat in de fabriek wordt gedrukt, het voedingswaardepaneel op het verkooppunt, en het traceerbaarheidsrecord dat een afgewerkte batch koppelt aan specifieke ingrediëntenpartijen voor de regelgevers van beide markten.

Zonder één receptbron van waarheid is dit precies waar dingen uit elkaar drijven: de fabriek werkt de formulering bij, maar het etiketsjabloon, de voedingswaardegegevens op het verkooppunt en het kostenrecord van het ERP worden bijgewerkt volgens drie verschillende schema’s, als ze al worden bijgewerkt. Wanneer productie, etikettering en costing hetzelfde recept lezen, verspreidt één wijziging zich overal waar dat nodig is, op dezelfde dag dat ze wordt doorgevoerd.

Finance ziet de fabriek, niet alleen de factuur

Het commerciële voordeel zit minder in de software zelf en meer in wat ze zichtbaar maakt. Wanneer het financeteam van de groep de werkelijke, actuele kostprijs per stuk ziet — geen ruwe toerekening — voor elk product dat de grens oversteekt, worden vragen die vroeger een maand kostten meteen beantwoordbaar: is een product nog winstgevend na een prijsverhoging van een leverancier? Weerspiegelt de intercompany-verrekenprijs tussen de fabriek en de winkels aan de andere kant van de grens nog de werkelijke productiekosten? Welke productlijn vreet stilletjes aan de marge omdat de formulering maanden geleden is gewijzigd en niemand de standaardkostprijs heeft herberekend?

Dat is hetzelfde principe dat geldt voor elke groep die meerdere locaties vanuit een centrale keuken of fabriek aanstuurt: het ERP behoudt zijn rol als leidend systeem voor geld — inkoop, betalingen, consolidatie — en een toegewijd recept- en productiesysteem wordt het leidende systeem voor wat de fabriek daadwerkelijk maakt. Dynamics 365 en de receptlaag stemmen met elkaar overeen, in plaats van dat het ene stilletjes van het andere afdrijft.

Klaar om uw fabriek aan te sluiten?

Als uw groep in de ene markt produceert en in een andere verkoopt — of meerdere fabrieken beheert die meerdere landen bevoorraden — geldt hetzelfde patroon, ongeacht welk ERP centraal staat. CalcMenu is gebouwd om naast Dynamics 365 of elk ander ERP te staan, nooit in de plaats ervan, zodat uw recepten, uw kosten en uw compliancegegevens synchroon blijven met het systeem dat uw financeteam al vertrouwt.

Boek een gesprek van 15 minuten met Marc op https://calendly.com/marceng/15-min-call-calcmenu-marc om te zien hoe een gekoppelde receptlaag voor uw fabriek zou werken.