Eén recept, drie systemen: een ERP, een POS-systeem en CalcMenu synchroon houden

Drie systemen, dezelfde feiten

Een grote foodservice-organisatie met meerdere vestigingen — een resort met verschillende restaurants en bars, een stadion met concessiestands, een cruiselijn met een tiental restaurants aan boord — draait doorgaans op drie afzonderlijke systemen die het onderling eens moeten zijn over dezelfde onderliggende feiten. Een ERP (vaak iets als JD Edwards) beheert de inkoop: artikelcodes, meeteenheden en prijzen voor alles wat bij leveranciers wordt besteld. Een POS-platform (vaak iets als Oracle Simphony) beheert de kassa: wat er wordt verkocht, tegen welke prijs, in welke vestiging. En een receptbeheersysteem zoals CalcMenu beheert het eten zelf: recepten, kostprijsberekening, voedingswaarden en allergenen.

Geen van die drie systemen is er ten onrechte de bron van waarheid voor wat het beheert. Het probleem ontstaat wanneer niemand verantwoordelijk is voor de relatie tussen die systemen, en iemand hetzelfde artikel handmatig in twee of drie systemen moet invoeren — met de afwijkingen die daar onvermijdelijk uit voortvloeien.

Wat de koppeling werkelijk moet doen

Het is verleidelijk om een “ERP-koppeling” te zien als één enkele leiding. In de praktijk moet ze twee afzonderlijke problemen oplossen, in twee verschillende richtingen:

Inkoopgegevens binnenhalen. In het ERP staan de ingekochte artikelen: artikelcodes, eenheden en prijzen. Een koppeling die die export uitleest en matcht met de artikelgegevens in CalcMenu, zorgt ervoor dat een keukenteam inkoopgegevens die al elders bestaan nooit opnieuw hoeft in te typen; de gegevens stromen één keer binnen en sturen vervolgens de kostprijs-, voedingswaarde- en allergeencijfers van elk recept dat het artikel gebruikt. Een veelvoorkomende complicatie: ERP’s houden vaak een basiseenheid (kilogram, liter) apart bij van een inkoopeenheid (stuk, doos, tray) met een eigen prijs — de koppeling moet beide meenemen, plus de omrekenverhouding ertussen, anders is een recept dat op gewicht wordt gekost niet te herleiden tot voorraad die per doos is ingekocht.

Receptkosten naar buiten sturen. Aan de kant van de kassa heeft het POS-systeem niet het recept nodig zoals CalcMenu dat ziet, maar de kostprijs per daadwerkelijk verkochte portie, gekoppeld aan een specifieke vestiging. Zodra bereidingen in bulk (batchrecepten) in het spel zijn, wijkt dat getal af van de kostprijs per receptopbrengst — de exportlogica moet dus zijn gebouwd rond de portiedefinitie van het POS-systeem, niet die van CalcMenu.

Voor organisaties met meerdere onderling verbonden vestigingen die een keuken of magazijn delen, is er vaak nog een derde onderdeel: de lijst met verplaatsbare producten in het ERP synchroon houden met wat in het receptsysteem daadwerkelijk nog actief is, zodat een uitgefaseerd artikel niet als geldige optie blijft opduiken bij het verplaatsen van voorraad tussen locaties.

Waarom de koppeling uitbreidbaar moet worden gebouwd

Dit soort koppeling is nooit echt “af”. Conventies voor meeteenheden worden achteraf gestandaardiseerd. De exportlogica naar het POS-systeem wordt gecorrigeerd zodra iemand merkt dat de verkeerde kostenbasis werd gerapporteerd. Uitgefaseerde producten hebben hun eigen afhandeling nodig, zodat ze niet langer verschijnen waar dat niet hoort. En het receptsysteem zelf migreert op een gegeven moment naar een nieuw platform, wat betekent dat de koppeling moet meemigreren in plaats van vanaf nul opnieuw gebouwd te worden. Een koppeling die is opgezet als één starre leiding, breekt bij de eerste van deze veranderingen; een koppeling met een duidelijke mappinglaag tussen de systemen vangt elke wijziging op als een kleine, afgebakende aanpassing.

Het voordeel, concreet

Goed uitgevoerd elimineert dit soort integratie een specifieke, terugkerende kostenpost, in plaats van simpelweg een functie toe te voegen omwille van de functie zelf:

1. Geen dubbele invoer van artikelgegevens. Artikelcodes, eenheden en prijzen bestaan één keer, in het ERP, en komen automatisch terecht in de receptkostprijsberekening.
2. Het POS-systeem toont de werkelijke food cost, geen verouderde schatting. Menu-engineering en winstgevendheidsanalyses werken met actuele cijfers voor kostprijs per portie, in plaats van met een spreadsheet die iemand vorig kwartaal voor het laatst heeft bijgewerkt.
3. Voorraadverplaatsingen tussen vestigingen zijn niet afhankelijk van iemand die eraan denkt het ERP handmatig bij te werken.
4. De integratie overleeft veranderingen in plaats van eronder te bezwijken — herzieningen van meeteenheden, correcties in de POS-export en platformmigraties aan de kant van het receptbeheer worden allemaal incrementele updates in plaats van projecten die opnieuw moeten worden onderhandeld.

Dit patroon duikt overal op waar een organisatie met meerdere vestigingen foodservice draait bovenop een enterprise-backoffice: resorts, cruiselijnen, cateraars voor luchtvaartmaatschappijen en hotelgroepen met meerdere merken krijgen er allemaal mee te maken zodra ze een handvol vestigingen overschrijden. Bekijk onze POS-integraties voor hoe de integratielaag van CalcMenu datzelfde principe toepast op verschillende ERP- en POS-platforms.

---

Draait u foodservice over meerdere vestigingen bovenop een ERP- en POS-landschap, en bent u het beu om dezelfde artikelgegevens twee keer in te voeren? Boek een gesprek van 15 minuten: Plan hier.