Ein Rezept, tausende Etiketten: ERP, CalcMenu und Zutatendeklarationen im Gleichlauf

Eine auftragsgesteuerte Produktion, kein fester Speiseplan

Ein Auftragsfertiger — eine Bäckerei, die Gebäck für eine Handelsmarke produziert, eine Sandwich-Fabrik, die Retail- und Gemeinschaftsverpflegungskunden beliefert, ein Fertiggerichte-Hersteller, der für mehrere Eigenmarken arbeitet — arbeitet nicht nach einem festen Wochenspeiseplan wie ein Restaurant. Die Produktion richtet sich danach, was die Kunden an diesem Tag tatsächlich bestellt haben, und diese Bestellungen laufen in der Regel über ein ERP-System — oft etwas wie Oracle —, das Bestellungen, Bestellpositionen und Mengen verwaltet. Was morgen früh von der Linie kommt, ist das, was laut ERP bestellt wurde — nicht das, was letzten Monat geplant war.

Damit entsteht ein spezifisches Integrationsproblem, das die meisten restaurantorientierten Rezeptprogramme nie lösen müssen. Ein Rezeptmanagement-System wie CalcMenu verwaltet das Lebensmittel selbst — das Rezept, seine Kosten, seine Nährwerte, seine Allergene. Ein Etikettiersystem wie BlazeIQ Labels verwaltet das, was tatsächlich gedruckt wird und auf der Verpackung landet. Keines der drei Systeme liegt falsch damit, zu besitzen, was es besitzt. Das Problem ist, dass standardmässig niemand die tägliche Übergabe zwischen ihnen besitzt — und ohne sie tippt am Ende jemand die Mengen der heutigen Bestellung von Hand in das Etikettiersystem ab, genau zu der Tageszeit, zu der ein Fehler am wahrscheinlichsten passiert und am wenigsten wahrscheinlich auffällt.

Was vom ERP bis zum Etikett gelangen muss — und warum QUID der schwierige Teil ist

Der mechanische Ablauf lässt sich einfach beschreiben: Eine Bestellposition kommt vom ERP herein, CalcMenu löst sie zu einem Rezept auf, und dieses Rezept wird auf die tatsächlich in diesem Lauf produzierte Chargenmenge skaliert — nicht auf eine seit Monaten fixe Referenzausbeute. Von da an müssen drei Arten von Deklarationsdaten zuverlässig, jedes Mal, das Etikett erreichen:

Die vollständige Zutatenliste. Nicht nur “was drin ist”, sondern QUID — die mengenmässige Zutatenkennzeichnung, die das europäische und Schweizer Lebensmittelrecht für jede Zutat verlangt, die auf der Verpackung namentlich genannt oder hervorgehoben wird (das “Poulet (30%)” auf einem Chicken-Sandwich-Etikett ist eine QUID-Angabe). QUID ist keine feste Zahl pro Rezept: Sie muss anhand der Mengen neu berechnet werden, die tatsächlich in diese konkrete Charge eingeflossen sind — genau deshalb funktioniert ein statisches, vorgedrucktes Etikett bei auftragsgesteuerten Volumen nicht. Der Prozentsatz kann sich von Charge zu Charge, von Lauf zu Lauf tatsächlich verschieben.

Allergene. Da die Rezeptdatenbank die einzige verlässliche Quelle dafür ist, was tatsächlich in einer Rezeptur steckt, müssen Allergendaten nicht separat pro Artikel, pro Produktionslauf oder pro Markt neu erfasst werden — sie stammen aus demselben Rezepteintrag, der einen Moment zuvor bereits die QUID-Berechnung geliefert hat.

Die Sprache. Ein Auftragsfertiger, der Kunden in mehr als einem Markt beliefert, braucht aus demselben Rezept Etiketten in der jeweils geforderten Sprache — diese Woche Französisch, nächste Woche Deutsch —, ohne einen separaten Übersetzungsdurchgang pro Etikett, pro Artikel, pro Sprache. Das funktioniert nur, wenn Zutatennamen und Allergenbegriffe als strukturierte Daten am Rezept hängen, statt als Freitext, den jemand von Hand in eine Etikettenvorlage einträgt.

Warum das nur funktioniert, wenn es für Erweiterung gebaut ist

Diese Art von Pipeline läuft unbeaufsichtigt, früh morgens, mit dem Volumen, das das ERP an diesem Tag übergeben hat — das heisst, sie muss eine Menge Schwankung verkraften, mit der ein einmaliger Export nie konfrontiert ist. Bestellvolumen schwanken von Tag zu Tag. Neue Rezeptvarianten kommen für neue Kunden hinzu. Ein eingestelltes Produkt muss aufhören, Etiketten zu erzeugen, ohne dass jemand daran denken muss, es von Hand abzuschalten. Drucker- und Etikettenformat-Wechsel folgen ihrem eigenen Zeitplan, unabhängig von der Rezeptseite. Eine als einzelnes starres Skript gebaute Schnittstelle bricht beim ersten dieser Fälle; eine mit einer klaren Zuordnungsschicht zwischen den Bestelldaten des ERP und den Rezeptdaten von CalcMenu gebaute Schnittstelle verkraftet jede Änderung als kleines, abgegrenztes Update statt als neu zu verhandelndes Projekt.

Der Vorteil, konkret

Richtig gemacht, beseitigt das ein konkretes, wiederkehrendes Risiko, statt eine Funktion um ihrer selbst willen hinzuzufügen:

1. Keine erneute Erfassung von Zutaten- oder Allergendaten pro Artikel, pro Produktionslauf oder pro Markt — sie existieren einmal, am Rezept, und erreichen das Etikett automatisch.
2. QUID-Prozentsätze werden anhand der tatsächlich produzierten Charge neu berechnet, nicht anhand eines statischen Referenzrezepts, das stillschweigend veraltet, sobald sich die Spezifikation eines Lieferanten ändert.
3. Mehrsprachige Etiketten entstehen aus einem einzigen Rezepteintrag, ohne separates Übersetzungsprojekt bei jedem neuen Markt.
4. Die Pipeline verkraftet tägliche Volumenschwankungen und neue Rezeptvarianten, weil sie darauf ausgelegt ist, unbeaufsichtigt mit dem zu laufen, was das ERP sendet, statt bei jeder vorgelagerten Änderung von Hand neu gestartet zu werden.

Das ist kein hypothetisches Beispiel — es ist die Form einer Pipeline, die wir täglich für einen auftragsgefertigten Sandwich-Hersteller betreiben, der Retail- und Gemeinschaftsverpflegungskunden beliefert.

Dieses Muster ist nicht auf Sandwiches beschränkt — jeder Auftragsfertiger, der auf Bestellung für Retail- oder Gemeinschaftsverpflegungskunden produziert, stösst auf dasselbe Fragmentierungsrisiko, sobald ein ERP, ein Rezeptsystem und ein Etikettendrucker sich jeden Tag auf dieselben Fakten einigen müssen. Es ist ein naher Verwandter des ERP/POS/CalcMenu-Musters, das wir für Mehrbetriebs-Hotelleriebetriebe beschreiben — dasselbe zugrunde liegende Problem, andere Systeme auf der Gegenseite. Siehe unsere Seite für Lebensmittelhersteller dafür, wie das breiter auf rezeptgesteuerte Herstellung zutrifft, und BlazeIQ Labels für die Etikettenseite der Pipeline selbst.

---

Produzieren Sie gegen einen täglichen Strom von ERP-Bestellungen und sind es leid, dass Zutatenlisten nicht ganz zu dem passen, was heute tatsächlich von der Linie kommt? Buchen Sie ein 15-minütiges Gespräch: Hier planen.

Entdecken Sie CalcMenus Rezeptmanagement-Software für Lebensmittelhersteller, um zu sehen, wie sie sich auf Ihre Küche anwenden lässt.